From markzzzsmith@yahoo.com.au Sat Jun 1 01:21:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4888221F85B4 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 KDEaBBapuD8O for ; Sat, 1 Jun 2013 01:21:12 -0700 (PDT) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id CACD121F85BF for ; Sat, 1 Jun 2013 01:21:08 -0700 (PDT) Received: from [98.139.215.141] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jun 2013 08:21:08 -0000 Received: from [98.139.212.211] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jun 2013 08:21:08 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 01 Jun 2013 08:21:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 172557.67829.bm@omp1020.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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 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:54:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC7621F85BF for ; Sat, 1 Jun 2013 03:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQzjgdvaImQS for ; Sat, 1 Jun 2013 03:54:30 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB6621F86DC for ; Sat, 1 Jun 2013 03:54:30 -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 DSNKUanS5RkYGjEJmOYqgoN2RMy+xPgv0yJY@postini.com; Sat, 01 Jun 2013 03:54: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 88CBB1B81D6 for ; Sat, 1 Jun 2013 03:54: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 740CB190052; Sat, 1 Jun 2013 03:54: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; Sat, 1 Jun 2013 03:54:29 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAdoBgIAABWYAgAAGnwCAAIjQAA== Date: Sat, 1 Jun 2013 10:54:29 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> In-Reply-To: <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D209EFB8F5BCA428650651649F48763@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 10:54:37 -0000 On May 31, 2013, at 10:44 PM, Owen DeLong wrote: > The TTL Exceeded packet shouldn't get forwarded by any router as a result= of the LL Source address. > Thus it should never reach its destination. > Thus it will break traceroutes. > Thus it is harmful. So you're arguing that every router on the internet needs a global IP addre= ss? From Ted.Lemon@nominum.com Sat Jun 1 03:59:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Ted.Lemon@nominum.com Sat Jun 1 04:08:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC9821F8746 for ; Sat, 1 Jun 2013 04:08:31 -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 vaa0GcqEF00M for ; Sat, 1 Jun 2013 04:08:24 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 07B8321F8763 for ; Sat, 1 Jun 2013 04:07:02 -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 DSNKUanV1kU5VlmPulOMQh5gzqB5P2ROXH7l@postini.com; Sat, 01 Jun 2013 04:07:03 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 8EE941B81D4 for ; Sat, 1 Jun 2013 04:07:02 -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 85F91190052; Sat, 1 Jun 2013 04:07:02 -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 04:07:02 -0700 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAAZAgIAARGOAgAGlBACAAIKugA== Date: Sat, 1 Jun 2013 11:07:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C02D0@mbx-01.win.nominum.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <51A7CDA9.4090304@massar.ch> <8D23D4052ABE7A4490E77B1A012B6307751BDDBD@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_8D23D4052ABE7A4490E77B1A012B6307751C02D0mbx01winnominum_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 11:08:31 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C02D0mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On May 31, 2013, at 11:19 PM, Lorenzo Colitti > wrote: Just number your internal network using ULAs and no global addresses, and t= hen run a traceroute across it. Global addresses on the source end, globa= l addresses on the destination end, ULAs in the middle. The only way to "= fix" this is to break traceroute. This does not represent brokenness. RFC 4193 section 4.3 disagrees with you. It says that border routers should= drop those packets and send back ICMP unreachables. To be clear, I'm not saying that a network that uses ULAs for transit route= rs and that returns those ULAs as source addresses in TTL exceeded packets = is following 4193, or even that its behavior is correct. What I am saying= is that if the border routers behave correctly, they break traceroute acro= ss such a network. So there's an incentive not to filter the ULA at the b= order router. But likely the reason people are seeing these is simply tha= t there's no egress filtering for the ULA on the border router due to inact= ion, rather than due to deliberate action. --_000_8D23D4052ABE7A4490E77B1A012B6307751C02D0mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2CC70A02A976754898845594A607A1F2@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 31, 2013, at 11:19 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
Just number your internal network using ULAs and no global addresses, and t= hen run a traceroute across it.   Global addresses on the source end, = global addresses on the destination end, ULAs in the middle.   The onl= y way to "fix" this is to break traceroute.   This does not represent brokenness.

RFC 4193 section 4.3 disagrees with you. It says that border routers should= drop those packets and send back ICMP unreachables.

To be clear, I'm not saying that a network that uses ULAs for transit = routers and that returns those ULAs as source addresses in TTL exceeded pac= kets is following 4193, or even that its behavior is correct.   What I= am saying is that if the border routers behave correctly, they break traceroute across such a network.   So t= here's an incentive not to filter the ULA at the border router.   But = likely the reason people are seeing these is simply that there's no egress = filtering for the ULA on the border router due to inaction, rather than due to deliberate action.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C02D0mbx01winnominum_-- From otroan@employees.org Sat Jun 1 04:15:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D3B21F86F0 for ; Sat, 1 Jun 2013 04:15:36 -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 PZLKqjyC95zs for ; Sat, 1 Jun 2013 04:15:35 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 5B66121F86DC for ; Sat, 1 Jun 2013 04:15:35 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 3A0E45E9C; Sat, 1 Jun 2013 04:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; s=selector1; bh=VEeWt14siOT70dtL2/3/WviiFAg=; b=IOfZIbudCnv/Hdt OtpCqGApW7reuRmQy3C1Ul1icocgh/3tgh7ufSm5Ix0/yRBizY8YF8w4TAWfluQ7 Gpi3Z/agh9HoK9gRkkk82Q8thQnLMphxq0YAU6JEA9uFsPBwDhdMvIYWZs1vVegL Xz/NCL4ndBKn+lK7OpxsQZV+Gc5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to; q=dns; s=selector1; b=nkxqe WOn+RdSoSBm5aSUwF2VzHhpoSmDkBN0M3AQVuRtWxovFyu36jDQlu7unfFBWQPft EsEks9QWsACbiDGYgDxQ4V+FKCB7ZHxfdBRpfa05I6HgyYMLbOtBSg3lMmBvzdO/ ijYXrcDGA0+xRLHsFwAJncDFaMO/oHveoW5PFk= Received: from [192.168.1.117] (unknown [195.159.143.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 5A7A05E5C; Sat, 1 Jun 2013 04:15:25 -0700 (PDT) References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Ole Troan Date: Sat, 1 Jun 2013 13:15:22 +0200 To: Ted Lemon Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 11:15:36 -0000 On 1 Jun 2013, at 12:54, Ted Lemon wrote: > On May 31, 2013, at 10:44 PM, Owen DeLong wrote: >> The TTL Exceeded packet shouldn't get forwarded by any router as a result= of the LL Source address. >> Thus it should never reach its destination. >> Thus it will break traceroutes. >> Thus it is harmful. >=20 > So you're arguing that every router on the internet needs a global IP addr= ess? Every node on the IPv6 internet needs a global IPv6 address.=20 Cheers, Ole From gert@space.net Sat Jun 1 04:59:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403F821F85E8 for ; Sat, 1 Jun 2013 04:59: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 LH4EwsrXJihk for ; Sat, 1 Jun 2013 04:59:55 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 90F5621F8556 for ; Sat, 1 Jun 2013 04:59:54 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id A1CDA60A94 for ; Sat, 1 Jun 2013 13:59:51 +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 7965860A93 for ; Sat, 1 Jun 2013 13:59:51 +0200 (CEST) Received: (qmail 84203 invoked by uid 1007); 1 Jun 2013 13:59:51 +0200 Date: Sat, 1 Jun 2013 13:59:51 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20130601115951.GD2504@Space.Net> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 11:59:56 -0000 Hi, On Sat, Jun 01, 2013 at 10:54:29AM +0000, Ted Lemon wrote: > So you're arguing that every router on the internet needs a global IP address? I would second that argument. 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 sander@steffann.nl Sat Jun 1 05:26:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBEE21F9951 for ; Sat, 1 Jun 2013 05:26:34 -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 jSEAMvLmJiYd for ; Sat, 1 Jun 2013 05:26:31 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id B1D7321F9922 for ; Sat, 1 Jun 2013 05:26:29 -0700 (PDT) Received: from [IPv6:2a00:8640:1::996b:7329:f601:27ca] (unknown [IPv6:2a00:8640:1:0:996b:7329:f601:27ca]) by mail.sintact.nl (Postfix) with ESMTP id 7ECD42015; Sat, 1 Jun 2013 14:26:26 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Sander Steffann In-Reply-To: Date: Sat, 1 Jun 2013 14:26:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2EFF47FB-D3E5-4020-9AB6-57201CA40888@steffann.nl> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> To: Ole Troan X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 12:26:34 -0000 >> So you're arguing that every router on the internet needs a global IP = address? >=20 > Every node on the IPv6 internet needs a global IPv6 address.=20 +1 Sander From owen@delong.com Sat Jun 1 05:43:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 owen@delong.com Sat Jun 1 05:48:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1F321F9B38 for ; Sat, 1 Jun 2013 05:48:07 -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 JeHmD-LtUHv0 for ; Sat, 1 Jun 2013 05:48:07 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4539721F9B26 for ; Sat, 1 Jun 2013 05:47:50 -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 r51Cg8tr020976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Jun 2013 05:42:52 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r51Cg8tr020976 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370090572; bh=x9eOrFrtg9Tm2qMdp3uNbckKfWY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wkAfSLfDrryVtq/JO45v0O4erE7eRpJu2RK5uJv/YudXxk/ZemvQApP28hr5qaxjS 0T7PtHXvf/KYIrxIM4vBkOhwFJjS3WzeRBwNnqn9g6miG/1SdLAJ5rrZkRde5yByst 35GSUxy/zcW3/+oNMAUMtGX5HvHlMGhP9mRt83mw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> Date: Sat, 1 Jun 2013 07:42:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <05B81AD5-1C43-44AD-B721-5AE9C2125017@delong.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@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:52 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 12:48:07 -0000 On Jun 1, 2013, at 5:54 AM, Ted Lemon wrote: > On May 31, 2013, at 10:44 PM, Owen DeLong wrote: >> The TTL Exceeded packet shouldn't get forwarded by any router as a = result of the LL Source address. >> Thus it should never reach its destination. >> Thus it will break traceroutes. >> Thus it is harmful. >=20 > So you're arguing that every router on the internet needs a global IP = address? Yes. Owen From arturo.servin@gmail.com Sat Jun 1 07:24:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD7E21F99FC for ; Sat, 1 Jun 2013 07:24:28 -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 WQuAB6Vd2kgt for ; Sat, 1 Jun 2013 07:24:22 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id A153B21F9996 for ; Sat, 1 Jun 2013 07:24:22 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id id13so1733096vcb.37 for ; Sat, 01 Jun 2013 07:24:22 -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=uRQpT6GLMvEggiz3Yd6h7GmylWn12PDCQ73VuySWKIQ=; b=vPDQDia+LL4eI2XQKm0BJP0XSsbryuLalXS9URwnVc+oTlIjlB+rXIO2jQZtAHg0TJ 1u6z8Vx16xNDsZ6jhFEz4kZJwEziZ8tJAwLKXFha8A0RVKgqFAH9ZpkwFLTEYWor4U7U /kDzpumfu1x8yKS9n+IX0+fyK8vsrRDhhQMQq5J9HHD9DP+O11lXPUZNt/8aqxlfKzW1 Tyw/rRQKieqCgnX0Oqs4jodfHPvitpkYYmDpuL9YNFP+S4f4hJooBQaTe4/+6Mz10+kD KMZbU4NyYRCPdZJnKKg/FWI6xIDdZ11jJ/8a2JFqwH4dmB2UuZHpOgqKZukzvXIYloVr M1zQ== X-Received: by 10.220.200.200 with SMTP id ex8mr14354813vcb.43.1370096662072; Sat, 01 Jun 2013 07:24:22 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2800:af:ba30:ea19:552b:732d:15e4:51e4]) by mx.google.com with ESMTPSA id s9sm39217737vdh.4.2013.06.01.07.24.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Jun 2013 07:24:21 -0700 (PDT) Message-ID: <51AA041E.1010109@gmail.com> Date: Sat, 01 Jun 2013 11:24:30 -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: Owen DeLong References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> <51A97918.9070404@massar.ch> <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> <51A97D9D.5010003@massar.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 14:24:28 -0000 And Jeroen are that if this happen you have a broken router (as you mentioned) and a possible leakage of traffic due to not applying BCP38. Both are bad, I think we all agree on that. .as On 6/1/13 3:05 AM, Owen DeLong wrote: > My point is that link local packets shouldn't even get far enough for BCP38 to matter. Every router is required to not forward then no matter what. If the packet gets far enough into the forwarding process for your BCP38 filters to matter, then you need a software update for the router. > > Owen From fred@cisco.com Sat Jun 1 07:47:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837BF21F9DF9 for ; Sat, 1 Jun 2013 07:47:35 -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 wFXOPId+eGPJ for ; Sat, 1 Jun 2013 07:47:30 -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 3225921F9E02 for ; Sat, 1 Jun 2013 07:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2278; q=dns/txt; s=iport; t=1370098050; x=1371307650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=g0afDmKEVX4gQAQkg1Qd02QFrNKueaNEPC6vUP70Qzw=; b=QgFmiXbcmo67H4MS17RCTJ4vKchvvmrSCVNi4owYy56zGYScGE4f4Yg6 Zrwax9sVb4GjfJcwt7bZsm8u0LasxtkxAD9CPL8rfi2HgHqni9TE4YaDS EmbWEgZdNljrHGPOr/K5g0nnGHiQE3VGMRUlrPV5tlTEDooyYfGT7gPCC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAH4IqlGtJXG8/2dsb2JhbABZgwkwvn18FnSCIwEBAQMBOj8QAgEIGAoUEDIlAgQOBQiHfwYMuROObgIxB4J2YQOYZ5AXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,783,1363132800"; d="scan'208";a="214582673" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 01 Jun 2013 14:47:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r51ElT18031127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Jun 2013 14:47:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 09:47:28 -0500 From: "Fred Baker (fred)" To: "Dan Wing (dwing)" Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOXtbw33rgt+rq2EGCwMw9WjmigQ== Date: Sat, 1 Jun 2013 14:47:28 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 14:47:35 -0000 On May 31, 2013, at 5:48 PM, Dan Wing wrote: >=20 > On May 31, 2013, at 5:45 AM, fred@cisco.com wrote: >=20 >> A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-= v6ops-ipv6-end-to-end-rt-needed. Please take a look at it and comment. >=20 > I read that document and draft-elkins-v6ops-ipv6-packet-sequence-needed. = Both the documents talk about how IPID is useful on IPv4 (if the sender is= monotonically increasing the IPID, which is a necessity for the existing s= ystem to operate) and how routers sometimes send a packet twice (which is n= ormal behavior of Ethernet) and that the monotonically increasing IPID help= s distinguish Ethernet re-transmissions from host stack retransmissions. >=20 > I note that Real Time Protocol (RTP, RFC3550; previously RFC1889 publishe= d in 1996) had similar needs and solved them at the RTP application layer w= ith sequence numbers and timestamps, and with its RTCP feedback channel. T= he two I-Ds that I reviewed did not discuss why this application timing pro= blem cannot be solved at the application layer like RTP solved it. >=20 > I did not see an analysis of forcing an IPv6 fragmentation header (as don= e by 4rd for transparency, http://tools.ietf.org/html/draft-ietf-softwire-4= rd), as that could provide a function nearly identical to the existing (ab)= use of IPv4 IPID. >=20 > -d Well, we can discuss what layer RTP is in; I'm not sure it's application. I= t's usable by a number of applications.=20 I would agree that the requirement to place it in a network layer header ha= s not been established; they could, for example, use the octet sequence num= ber in the TCP header, unless everything above the network layer is encrypt= ed. However, I think it *is* fair to say that putting it lower down the sta= ck makes it readily accessible for more applications or transports more qui= ckly. You have experience with Happy Eyeballs, and the fact that the horren= dous design of the socket API forces us to change every application individ= ually when we could have changed the invisible underpinnings of an OS API o= nce, and in so doing ported all of the applications to IPv6 as well. She ha= s a similar problem, but in a packet. From nalini.elkins@insidethestack.com Sat Jun 1 08:35:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B1321F9E46 for ; Sat, 1 Jun 2013 08:35:52 -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 EL4AcJdLLo39 for ; Sat, 1 Jun 2013 08:35:48 -0700 (PDT) Received: from nm20-vm0.access.bullet.mail.mud.yahoo.com (nm20-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.29]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF921F9E4D for ; Sat, 1 Jun 2013 08:35:47 -0700 (PDT) Received: from [66.94.237.195] by nm20.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:35:44 -0000 Received: from [66.94.237.125] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:35:44 -0000 Received: from [127.0.0.1] by omp1030.access.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:35:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 429951.40827.bm@omp1030.access.mail.mud.yahoo.com Received: (qmail 67380 invoked by uid 60001); 1 Jun 2013 15:35:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370100944; bh=570XWH72KyOM2PXELQmmEA3RMVLz3HnyvGHkzoS8+iM=; 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=aoPpK440gkrcMR65wKzM9nNalJXhFrD1myZ2+zpDbYb/C+jw0Vld4+JSSd7FUfaTYU+2GkpurXTw7fnLZ6SyvC+ui6leGcOz66mHlhuERv8UOdzj+4ndUOstLKjoYsZ0P3wF3bKJ28SRPsWq6plWgokflnucxBBiD2flDH0h7ZM= X-YMail-OSG: Z_dHOkMVM1mLm9DC_xTJOyg65wxRciH71d6Is1rOEXEW0BA SDK6K0E3HAqW11zlp7hGhW7iob3fKt3ZppzYitoPLSGEKGL4qZUZSw1Jkgc5 sgbWiJvIvpbZHw.B87vDaFpqRB4FzRGdY4YyW4Qj7GYhozub3Iwhj0zWAjip GposxZ7lE4vb4kJ.wr_B7SzblnE37j6aAlkQS0I6kAYU_6mKHqiRwzIulLOx JqmhyTCNocYJaNeMFJ0yWWb0Xbm2J5139wHDgihR8pgdaoFStys12R7aoxVL _fiU2_ndk.tGLOxqUWQi_b15e_1RWFVrCuGzxuD.BODKK0mdqbDj0ExKMLDx lwMrwvttwtWdf7HRerz4suLCjRcch.MC75Vd_W7XZLfT8UIsIG.EMzWa9_u9 tgLqE8FuDHsJguGkHCAzXHvHde2Q0QTnJ0N58mfln_vr0YRlur.Ry.YbGleh jjLFiY84px1bkTnuewKBeLCV5pTbd25pPmRbd6ktrYLOLWZ1_xofcG.DQLcl mb3TlQMnLBQPkg1SyH1gC.eeKt6UTPwXjhRbAHaDg9OuNBMQeCBNMCynRnNY YX6pT57Z4IVlcO1Yq02U6DpnOXWQI5JSW2Tj0IiJsNeqJFXnx.0iRHQi3w68 lILISDG7Oefr4BtiqAGg8gw-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Sat, 01 Jun 2013 08:35:43 PDT X-Rocket-MIMEInfo: 002.001, R3V5cywKCjEuIMKgUlRQOiDCoEkgZG8gbm90IHRoaW5rIHRoYXQgaXQgaXMgcGVydGluZW50LiDCoCDCoEkgZG8gbm90IGtub3cgd2hhdCBEYW4gaXMgc3VnZ2VzdGluZyAtIHRoYXQgd2UgY2hhbmdlIEFMTCBhcHBsaWNhdGlvbnMgdG8gcHJvdmlkZSBzZXEuIG5vIGFuZCB0aW1lc3RhbXA_IMKgIExhcmdlIGNvbXBhbmllcyB1c2UgaHVuZHJlZHMgb2YgYXBwbGljYXRpb25zIHJ1bm5pbmcgdW5kZXIgVENQL0lQLiDCoFRoaXMgaXMgY29tcGxldGVseSB1bmRvYWJsZS4KCjIuIMKgRm9yY2luZyBvZiBJUHY2IGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> Message-ID: <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sat, 1 Jun 2013 08:35:43 -0700 (PDT) From: Nalini Elkins To: "Fred Baker \(fred\)" , "Dan Wing \(dwing\)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 15:35:53 -0000 Guys,=0A=0A1. =A0RTP: =A0I do not think that it is pertinent. =A0 =A0I do n= ot know what Dan is suggesting - that we change ALL applications to provide= seq. no and timestamp? =A0 Large companies use hundreds of applications ru= nning under TCP/IP. =A0This is completely undoable.=0A=0A2. =A0Forcing of I= Pv6 fragmentation header. =A0We did discuss this in section 3:=A0http://too= ls.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11= =0A=0AIt is as follows:=0A=0A"The current IPv6 specification does not provi= de a packet sequence=A0number or similar field in the IPv6 main header. =A0= One option might be=A0to force all IPv6 packets to contain a Fragment Heade= r. =A0In packets=A0which are entire in and of themselves, the fragment ID w= ould be zero=A0- that is, an atomic fragment. Why was a new destination opt= ion=A0header defined rather than recommending that Fragment Header be used?= =0A=0A=0AOur reasoning was that the PDM destination option header would=A0p= rovide multiple benefits : the packet sequence number and the=A0timestamp t= o calculate response time. "=0A=0AThe second reason for not having a fragme= nt header is that unfortunately, a number of firewalls, etc, drop packets w= hich contain IPv6 fragment headers. =A0I find this to be unsuitable behavio= r which I hope will change . =A0 But, it is the reality.=0A=0A=0A3. =A0TCP = Sequence Number: =A0this was discussed in:=A0http://tools.ietf.org/html/dra= ft-elkins-v6ops-ipv6-packet-sequence-needed-00#section-1.3=0A=0AIt is as fo= llows:=0A=0A"TCP Sequence number is defined in RFC0793[RFC0793].=A0=A0Some = have=A0 proposed that this field will meet the needs of EDCO networks for a= =A0=A0packet sequence number.=A0=A0Indeed, the TCP Sequence Number along wi= th=A0the=0ATCP Acknowledgment number can be used to calculate dropped=A0pac= kets, duplicate packets, out-of-order packets etc. That is, IF the=A0packet= flow itself reflects accurately what happened on the wire!=0ASee Scenario = 1 (Section 1.5.2) and Scenario 2 (Section 1.5.3) for what happens with pack= et trace capture in real networks. The TCP Sequence Number is, obviously, a= vailable only for TCP and not other transport protocols."=A0=0A=0A=0AThanks= ,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insi= dethestack.com=0A=0A=0A=0A________________________________=0AFrom: Fred Bak= er (fred) =0ATo: Dan Wing (dwing) =0ACc: = "v6ops@ietf.org" ; "draft-elkins-v6ops-ipv6-end-to-end-rt-n= eeded@tools.ietf.org" =0ASent: Saturday, June 1, 2013 7:47 AM=0ASubject: Re: [v6ops] new= draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A=0A=0A=0AOn May 31, = 2013, at 5:48 PM, Dan Wing wrote:=0A=0A> =0A> On May 31, = 2013, at 5:45 AM, fred@cisco.com wrote:=0A> =0A>> A new draft has been post= ed, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-nee= ded. Please take a look at it and comment.=0A> =0A> I read that document an= d draft-elkins-v6ops-ipv6-packet-sequence-needed.=A0 Both the documents tal= k about how IPID is useful on IPv4 (if the sender is monotonically increasi= ng the IPID, which is a necessity for the existing system to operate) and h= ow routers sometimes send a packet twice (which is normal behavior of Ether= net) and that the monotonically increasing IPID helps distinguish Ethernet = re-transmissions from host stack retransmissions.=0A> =0A> I note that Real= Time Protocol (RTP, RFC3550; previously RFC1889 published in 1996) had sim= ilar needs and solved them at the RTP application layer with sequence numbe= rs and timestamps, and with its RTCP feedback channel.=A0 The two I-Ds that= I reviewed did not discuss why this application timing problem cannot be s= olved at the application layer like RTP solved it.=0A> =0A> I did not see a= n analysis of forcing an IPv6 fragmentation header (as done by 4rd for tran= sparency, http://tools.ietf.org/html/draft-ietf-softwire-4rd), as that coul= d provide a function nearly identical to the existing (ab)use of IPv4 IPID.= =0A> =0A> -d=0A=0AWell, we can discuss what layer RTP is in; I'm not sure i= t's application. It's usable by a number of applications. =0A=0AI would agr= ee that the requirement to place it in a network layer header has not been = established; they could, for example, use the octet sequence number in the = TCP header, unless everything above the network layer is encrypted. However= , I think it *is* fair to say that putting it lower down the stack makes it= readily accessible for more applications or transports more quickly. You h= ave experience with Happy Eyeballs, and the fact that the horrendous design= of the socket API forces us to change every application individually when = we could have changed the invisible underpinnings of an OS API once, and in= so doing ported all of the applications to IPv6 as well. She has a similar= problem, but in a packet.=0A=0A___________________________________________= ____=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/v6ops=A0 From nalini.elkins@insidethestack.com Sat Jun 1 08:36:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DAA21F9E60 for ; Sat, 1 Jun 2013 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+96--iGbVB1 for ; Sat, 1 Jun 2013 08:36:14 -0700 (PDT) Received: from nm8.access.bullet.mail.mud.yahoo.com (nm8.access.bullet.mail.mud.yahoo.com [66.94.237.209]) by ietfa.amsl.com (Postfix) with ESMTP id 85C8D21F9E48 for ; Sat, 1 Jun 2013 08:36:13 -0700 (PDT) Received: from [66.94.237.200] by nm8.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:36:13 -0000 Received: from [66.94.237.122] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:36:13 -0000 Received: from [127.0.0.1] by omp1027.access.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:36:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 34393.69924.bm@omp1027.access.mail.mud.yahoo.com Received: (qmail 67603 invoked by uid 60001); 1 Jun 2013 15:36:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370100972; bh=B8UJ3D83IrSJqGo0gn0FMvnSQiO/1FC7YR0jbYaw4Q0=; 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=2Y9SH/vTWfe4UvZb+Tc7fVBzS+eRC2uNUZdZKrgxEodbWUO1uILjQZCQdmvk444v53JPIV0irKjUUoCqtdNpYv5YlwxIv3Dy1Oa/07Oa3IPKh/HzcqqswLtu4u0odsTKHBlCDCGkRTqLtKdceLWFb55JJ7TcjoRD9MryBLDRpgk= X-YMail-OSG: xWu2HS0VM1lf6VVdCk4PG8shP1QqttfZ0eES6kegoRRg11X F0tmFZCJhLtsTiMFlawiIWndb_Zp_whfmEmE0Zl8T6WtH8i_FtR550KFFNSl JdujohYOp1kfZIzChKfhqFEBlhBp6yWck6VZeJ_hUkN4_jn5_s.aXmEtH83I SJdu.FxOGc.pwuxS6wYawRHQn9Egwm8U5kebpOr4q9iXU0ZrFU04SBA__grh C.bx6gfT1_bNhwNA6u_r6tVodhHz4igyvXZ55JNNBfkIxacWmKzHvI3Ovkpp ORQcGrLBNgFMQToUmnR5ssh5mGpMsrE7rJgBXQ4vZaFU6dgXuk3LfY3oikqN C8wtwgafpVdkRtpP33V2I5RxCVQDS9tNOI4_z3ze83VWuaeJ9Mdn8EH8L.ZR PfFFS3qUJBNlrNcY4LHi5DuIW_3JhCbKoqr0Rh3QxMjcHubxGtT6I575Wnhg M_lhTJhonSQJsr4vkA67wv3WMfONSxLpPSzXw91ucTjps4hVrOqjWl1ezvt2 lNWTLkQH4j6mKqx82WR12wipl_26WN8Ikyy5QTIH_XIP2uxV2L5r2USEBKOw l7XJ2PI0lTVQdKtA3oEYV4LCrSRyzYpJMDYgDIIzwMcqKLZvpaT6L7Vr5LcW kLUWn_HFWPSEAy9UTr7EDIQ-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Sat, 01 Jun 2013 08:36:12 PDT X-Rocket-MIMEInfo: 002.001, R3V5cywKCjEuIMKgUlRQOiDCoEkgZG8gbm90IHRoaW5rIHRoYXQgaXQgaXMgcGVydGluZW50LiDCoCDCoEkgZG8gbm90IGtub3cgd2hhdCBEYW4gaXMgc3VnZ2VzdGluZyAtIHRoYXQgd2UgY2hhbmdlIEFMTCBhcHBsaWNhdGlvbnMgdG8gcHJvdmlkZSBzZXEuIG5vIGFuZCB0aW1lc3RhbXA_IMKgIExhcmdlIGNvbXBhbmllcyB1c2UgaHVuZHJlZHMgb2YgYXBwbGljYXRpb25zIHJ1bm5pbmcgdW5kZXIgVENQL0lQLiDCoFRoaXMgaXMgY29tcGxldGVseSB1bmRvYWJsZS4KCjIuIMKgRm9yY2luZyBvZiBJUHY2IGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> Message-ID: <1370100972.57593.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sat, 1 Jun 2013 08:36:12 -0700 (PDT) From: Nalini Elkins To: "Fred Baker \(fred\)" , "Dan Wing \(dwing\)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 15:36:18 -0000 Guys,=0A=0A1. =A0RTP: =A0I do not think that it is pertinent. =A0 =A0I do n= ot know what Dan is suggesting - that we change ALL applications to provide= seq. no and timestamp? =A0 Large companies use hundreds of applications ru= nning under TCP/IP. =A0This is completely undoable.=0A=0A2. =A0Forcing of I= Pv6 fragmentation header. =A0We did discuss this in section 3:=A0http://too= ls.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11= =0A=0AIt is as follows:=0A=0A"The current IPv6 specification does not provi= de a packet sequence=A0number or similar field in the IPv6 main header. =A0= One option might be=A0to force all IPv6 packets to contain a Fragment Heade= r. =A0In packets=A0which are entire in and of themselves, the fragment ID w= ould be zero=A0- that is, an atomic fragment. Why was a new destination opt= ion=A0header defined rather than recommending that Fragment Header be used?= =0A=0A=0AOur reasoning was that the PDM destination option header would=A0p= rovide multiple benefits : the packet sequence number and the=A0timestamp t= o calculate response time. "=0A=0AThe second reason for not having a fragme= nt header is that unfortunately, a number of firewalls, etc, drop packets w= hich contain IPv6 fragment headers. =A0I find this to be unsuitable behavio= r which I hope will change . =A0 But, it is the reality.=0A=0A=0A3. =A0TCP = Sequence Number: =A0this was discussed in:=A0http://tools.ietf.org/html/dra= ft-elkins-v6ops-ipv6-packet-sequence-needed-00#section-1.3=0A=0AIt is as fo= llows:=0A=0A"TCP Sequence number is defined in RFC0793[RFC0793].=A0=A0Some = have=A0 proposed that this field will meet the needs of EDCO networks for a= =A0=A0packet sequence number.=A0=A0Indeed, the TCP Sequence Number along wi= th=A0the=0ATCP Acknowledgment number can be used to calculate dropped=A0pac= kets, duplicate packets, out-of-order packets etc. That is, IF the=A0packet= flow itself reflects accurately what happened on the wire!=0ASee Scenario = 1 (Section 1.5.2) and Scenario 2 (Section 1.5.3) for what happens with pack= et trace capture in real networks. The TCP Sequence Number is, obviously, a= vailable only for TCP and not other transport protocols."=A0=0A=0A=0A=A0=0A= Thanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Aww= w.insidethestack.com=0A=0A=0A=0A----- Original Message -----=0AFrom: Fred B= aker (fred) =0ATo: Dan Wing (dwing) =0ACc:= "v6ops@ietf.org" ; "draft-elkins-v6ops-ipv6-end-to-end-rt-= needed@tools.ietf.org" =0ASent: Saturday, June 1, 2013 7:47 AM=0ASubject: Re: [v6ops] new= draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A=0A=0AOn May 31, 201= 3, at 5:48 PM, Dan Wing wrote:=0A=0A> =0A> On May 31, 201= 3, at 5:45 AM, fred@cisco.com wrote:=0A> =0A>> A new draft has been posted,= at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed= . Please take a look at it and comment.=0A> =0A> I read that document and d= raft-elkins-v6ops-ipv6-packet-sequence-needed.=A0 Both the documents talk a= bout how IPID is useful on IPv4 (if the sender is monotonically increasing = the IPID, which is a necessity for the existing system to operate) and how = routers sometimes send a packet twice (which is normal behavior of Ethernet= ) and that the monotonically increasing IPID helps distinguish Ethernet re-= transmissions from host stack retransmissions.=0A> =0A> I note that Real Ti= me Protocol (RTP, RFC3550; previously RFC1889 published in 1996) had simila= r needs and solved them at the RTP application layer with sequence numbers = and timestamps, and with its RTCP feedback channel.=A0 The two I-Ds that I = reviewed did not discuss why this application timing problem cannot be solv= ed at the application layer like RTP solved it.=0A> =0A> I did not see an a= nalysis of forcing an IPv6 fragmentation header (as done by 4rd for transpa= rency, http://tools.ietf.org/html/draft-ietf-softwire-4rd), as that could p= rovide a function nearly identical to the existing (ab)use of IPv4 IPID.=0A= > =0A> -d=0A=0AWell, we can discuss what layer RTP is in; I'm not sure it's= application. It's usable by a number of applications. =0A=0AI would agree = that the requirement to place it in a network layer header has not been est= ablished; they could, for example, use the octet sequence number in the TCP= header, unless everything above the network layer is encrypted. However, I= think it *is* fair to say that putting it lower down the stack makes it re= adily accessible for more applications or transports more quickly. You have= experience with Happy Eyeballs, and the fact that the horrendous design of= the socket API forces us to change every application individually when we = could have changed the invisible underpinnings of an OS API once, and in so= doing ported all of the applications to IPv6 as well. She has a similar pr= oblem, but in a packet. From bill.jouris@insidethestack.com Sat Jun 1 08:47:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A5021F9E4D for ; Sat, 1 Jun 2013 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfG6zpa3Urr6 for ; Sat, 1 Jun 2013 08:47:45 -0700 (PDT) Received: from nm19.access.bullet.mail.mud.yahoo.com (nm19.access.bullet.mail.mud.yahoo.com [66.94.237.220]) by ietfa.amsl.com (Postfix) with ESMTP id A905121F9E4E for ; Sat, 1 Jun 2013 08:47:45 -0700 (PDT) Received: from [66.94.237.195] by nm19.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:47:45 -0000 Received: from [66.94.237.107] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:47:45 -0000 Received: from [127.0.0.1] by omp1012.access.mail.mud.yahoo.com with NNFMP; 01 Jun 2013 15:47:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 326272.14176.bm@omp1012.access.mail.mud.yahoo.com Received: (qmail 71352 invoked by uid 60001); 1 Jun 2013 15:47:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370101665; bh=6wpWdXYYPbku+HFtVmXsU4F1YRaozkXpUQ+J/VVOR+M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Z6AjCFiRyCgAv5KXUUWREwnwp1O7nDiA4iPIC00n13PRcnchHwQQhWCadum9tGH377DaZMFFcFJI9Y+WrNCRbuonVE/SERcgs5RaLT8diahJ6nmgGdxhW0+vQ0cUKk5XrbBNgsMCTHZl8ZuFSODfHk9ynWMvNmdlRCRjX9JfLZg= X-YMail-OSG: KQ0H8tIVM1mQ_xP7uRgHgL0YQN09Qh3BvevyGGkwgdvdMLB vFcwkihvpeBHkaRvd5nSQF9W.Kki8fMlQC6TiIySli_bx50agDlagBsE3i_4 GZ6HRDoAc9hegdNhvqz3SxNsePWFZaSqPYDDZ1uvyg13Kcty8jQUWFK2Ho7G E2ToOVudEkZYW7IUcwU2qYbhAKqFWAed3AofjaX71p_tEn7dGIp5dp7.hz7M wvfPN7KIkOeID.uVpeuaNeSvwuUrYbaaLOxKcdm8JwdUPj3nUMn8x14Z9PcD feu8sSAkT.k9lzAcNzOn1kuNPW37YJcJJ6dAME7wc0KGGSSHAdIyvaWFF1xS yUoeRycMO2woGKK8DY4BN4JgsC58zmnv06aRCs8b6edtVWnZ51Z__e3s13Au 0mMfpljRejnFyBGu1MLJdF3viZTzo7Lon0ryYCtjyd49b0NogprtXqptDO99 XTsRmiMNQxWKqbB97cqU17xvd2NWe5WWAnGtmgzsCejRxcMpbcAxLdYKBW8q biA.x_nZuEt4u0eJBuxg_H6UQM_1xY_rqPC12Gl3KSZxTMiy4wwmkwFJr6og XvG1UaniM24OqY.9uXkABeRwDB3uE9V3hbf1WNJeQ6FOHupftdjCgzCHUntR YYhCzemDj Received: from [50.148.178.232] by web2802.biz.mail.ne1.yahoo.com via HTTP; Sat, 01 Jun 2013 08:47:44 PDT X-Rocket-MIMEInfo: 002.001, PiBJIHdvdWxkIGFncmVlIHRoYXQgdGhlIHJlcXVpcmVtZW50IHRvIHBsYWNlIGl0IGluIGEgbmV0d29yayBsYXllciBoZWFkZXIKIGhhcyBub3QgYmVlbiANCj4gZXN0YWJsaXNoZWQ7IHRoZXkgY291bGQsIGZvciBleGFtcGxlLCB1c2UgdGhlIG9jdGV0IApzZXF1ZW5jZSBudW1iZXIgaW4gdGhlIFRDUCBoZWFkZXIsIA0KPiB1bmxlc3MgZXZlcnl0aGluZyBhYm92ZSB0aGUgbmV0d29yayAKbGF5ZXIgaXMgZW5jcnlwdGVkLiBIb3dldmVyLCBJIHRoaW5rIGl0ICppcyogZmFpciB0byBzYXkgDQo.IHRoYXQgcHUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.145.547 Message-ID: <1370101664.69233.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> Date: Sat, 1 Jun 2013 08:47:44 -0700 (PDT) From: Bill Jouris To: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" In-Reply-To: <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-260626550-1370101664=:69233" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 15:47:51 -0000 ---153701192-260626550-1370101664=:69233 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > I would agree that the requirement to place it in a network layer header= =0A has not been=20 > established; they could, for example, use the octet =0Asequence number in= the TCP header,=20 > unless everything above the network =0Alayer is encrypted. However, I thi= nk it *is* fair to say=20 > that putting it=0A lower down the stack makes it readily accessible for m= ore applications =0Aor=20 > transports more quickly. You have experience with Happy Eyeballs, and=0A = the fact that the=20 > horrendous design of the socket API forces us to =0Achange every applicat= ion individually=20 > when we could have changed the =0Ainvisible underpinnings of an OS API on= ce, and in so=20 > doing ported all of=0A the applications to IPv6 as well. She has a simila= r problem, but in a =0A > packet. The problem with using the the octet sequence number in the TCP header is = simply this: there is a lot of network traffic which is not TCP.=A0 But the= same need for end-to-end timings exists for packets using other protocols.= =A0 So avoiding using something in the IP header would require adding it in= stead to the headers of ALL of the other protocols.=A0 Which seems like a f= ar more complex approach. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) ---153701192-260626550-1370101664=:69233 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> I would agree that the requirement to pl= ace it in a network layer header=0A has not been
> established; they= could, for example, use the octet =0Asequence number in the TCP header, > unless everything above the network =0Alayer is encrypted. However, = I think it *is* fair to say
> that putting it=0A lower down the stac= k makes it readily accessible for more applications =0Aor
> transpor= ts more quickly. You have experience with Happy Eyeballs, and=0A the fact t= hat the
> horrendous design of the socket API forces us to =0Achange= every application individually
> when we could have changed the =0A= invisible underpinnings of an OS API once, and in so
> doing ported = all of=0A the applications to IPv6 as well. She has a similar problem, but = in a =0A
> packet.

The problem with using the the octet seque= nce number in the TCP header is simply this: there is a lot of network traf= fic which is not TCP.  But the same need for end-to-end timings exists= for packets using other protocols.  So avoiding using something in th= e IP header would require adding it instead to the headers of ALL of the ot= her protocols.  Which seems like a far more complex approach.

<= font size=3D"2">Bill Jouris
Inside Products, Inc= .
www.insidethestack.com
831-659-8360
925-855-9512 (direct)=

---153701192-260626550-1370101664=:69233-- From Ted.Lemon@nominum.com Sat Jun 1 09:14:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Ted.Lemon@nominum.com Sat Jun 1 09:17:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F2C21F9CA4 for ; Sat, 1 Jun 2013 09:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y87RgOy5jtQ0 for ; Sat, 1 Jun 2013 09:17:01 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9D45C21F9CC2 for ; Sat, 1 Jun 2013 09:17:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUaoecIPSU0VkpAs2/LtLdMlZekWmTWp5@postini.com; Sat, 01 Jun 2013 09:17: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 19F9F1B818D for ; Sat, 1 Jun 2013 09:16:48 -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 1341B190052; Sat, 1 Jun 2013 09:16:48 -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:16:48 -0700 From: Ted Lemon To: Sander Steffann Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAdoBgIAABWYAgAAGnwCAAIjQAIAABdcAgAAT14CAAEBfAA== Date: Sat, 1 Jun 2013 16:16:47 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <2EFF47FB-D3E5-4020-9AB6-57201CA40888@steffann.nl> In-Reply-To: <2EFF47FB-D3E5-4020-9AB6-57201CA40888@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" , "" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:17:08 -0000 On Jun 1, 2013, at 8:26 AM, Sander Steffann wrote: >>> So you're arguing that every router on the internet needs a global IP a= ddress? >>=20 >> Every node on the IPv6 internet needs a global IPv6 address.=20 >=20 > +1 So I also +1 this, but if people are seeing traceroutes with ULAs in them, = apparently _someone_ doesn't agree. From alexandru.petrescu@gmail.com Sat Jun 1 09:24:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16221F9ACA for ; Sat, 1 Jun 2013 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUZ0Z9MMFEhU for ; Sat, 1 Jun 2013 09:24:18 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id B743721F9AAC for ; Sat, 1 Jun 2013 09:24:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r51GO7eb028297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 1 Jun 2013 18:24:07 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r51GO6P4011898 for ; Sat, 1 Jun 2013 18:24:07 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.6]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r51GNwPE023851 for ; Sat, 1 Jun 2013 18:24:06 +0200 Message-ID: <51AA201E.1060407@gmail.com> Date: Sat, 01 Jun 2013 18:23:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <2EFF47FB-D3E5-4020-9AB6-57201CA40888@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:24:25 -0000 Le 01/06/2013 18:16, Ted Lemon a écrit : > On Jun 1, 2013, at 8:26 AM, Sander Steffann > wrote: >>>> So you're arguing that every router on the internet needs a >>>> global IP address? >>> >>> Every node on the IPv6 internet needs a global IPv6 address. I am divided on this. The link local address is also mandatory. Do we end up saying that every node in the IPv6 Internet needs at least two addresses? Alex >> >> +1 > > So I also +1 this, but if people are seeing traceroutes with ULAs in > them, apparently _someone_ doesn't agree. > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From Ted.Lemon@nominum.com Sat Jun 1 09:33:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A036A21F9DE4 for ; Sat, 1 Jun 2013 09:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Hw9E2w0FbiC for ; Sat, 1 Jun 2013 09:33:03 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id DD70E21F9DE0 for ; Sat, 1 Jun 2013 09:33:02 -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 DSNKUaoiPjqB+Mb47bHnIqIAGxnATYoE1FZY@postini.com; Sat, 01 Jun 2013 09: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 80DE61B818D for ; Sat, 1 Jun 2013 09:33:02 -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 790AA190052; Sat, 1 Jun 2013 09:33:02 -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:33:02 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAdoBgIAABWYAgAAGnwCAAIjQAIAABdcAgAAT14CAAEBfAIAAAgMAgAACh4A= Date: Sat, 1 Jun 2013 16:33:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C0771@mbx-01.win.nominum.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <2EFF47FB-D3E5-4020-9AB6-57201CA40888@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> <51AA201E.1060407@gmail.com> In-Reply-To: <51AA201E.1060407@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <984C2BAB72BC6B4DA3705E8BBD13DDD9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:33:09 -0000 On Jun 1, 2013, at 12:23 PM, Alexandru Petrescu wrote: > Do we end up saying that every node in the IPv6 Internet needs at least t= wo addresses? If all you have is a link-local address, then by definition you are not on = the global internet. The link-local vs. global address selection problem = is easy, so I don't think you need to lose any sleep over this. From jeroen@massar.ch Sat Jun 1 10:05:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A165E21F9DDA for ; Sat, 1 Jun 2013 10:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.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 g9TiySoui9Em for ; Sat, 1 Jun 2013 10:05: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 4862421F9DD5 for ; Sat, 1 Jun 2013 10:05:34 -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 2F097801C2BA; Sat, 1 Jun 2013 19:05:29 +0200 (CEST) Message-ID: <51AA29D7.8010901@massar.ch> Date: Sat, 01 Jun 2013 10:05:27 -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: Ted Lemon References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <2EFF47FB-D3E5-4020-9AB6-57201CA40888@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 17:05:39 -0000 On 2013-06-01 09:16, Ted Lemon wrote: > On Jun 1, 2013, at 8:26 AM, Sander Steffann > wrote: >>>> So you're arguing that every router on the internet needs a >>>> global IP address? >>> >>> Every node on the IPv6 internet needs a global IPv6 address. >> >> +1 > > So I also +1 this, but if people are seeing traceroutes with ULAs in > them, apparently _someone_ doesn't agree. Nothing to do with disagreement, everything to do with not understanding (nicely put) where ULA should be used and how. Next to not understanding the concepts of BCP38/84. Note that it seems that in this specific case the vendor actually informed them that they could/should use a ULA there as it would never leak to the Internet anyway..... thus can't even completely blame the person who configured it, though I don't understand why one still then would try and select ULA there when you have enough global space. Greets, Jeroen From tjc@ecs.soton.ac.uk Sat Jun 1 12:06:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 brian.e.carpenter@gmail.com Sat Jun 1 13:53:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760DC21F9D91 for ; Sat, 1 Jun 2013 13:53:48 -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 FCljP494B0eh for ; Sat, 1 Jun 2013 13:53:48 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DF23F21F9D49 for ; Sat, 1 Jun 2013 13:53:41 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id u16so4310952iet.8 for ; Sat, 01 Jun 2013 13:53:41 -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=TeENBQheWgry4AmyU+36+d9b3/b8pfEjr9QT9lkSDIA=; b=iEHTqshUE4PO5KMKmisJTCipXHLPv6708yQGthK2XYMLvh954wyZERaw3gQbcMj5/G w8n4CFeNOG/7nYs2OyZTJIGurQbcIr3E4o865LTtrIu6tRiNVeh9vx+6t4+sUZJ4ixlB Us8stqkwu+8IkWZcUERT1Nu/T77Okq21cEZZzKVylyrrjm7/rTIZQNV6zRFHq+BkjHRy 0rB6Tn6oGmxjblQ8QMzp2aexqUTH+amjSKhKn0cMs4h21aClQmvurxpPi/q6yEIHN+pV WXVxMNZoX/OirHXjW3mpK7IOOKN1qKf4AR+Dj84KQR0hwdVDqupSmsSt9CgouYum+0To Opow== X-Received: by 10.50.114.228 with SMTP id jj4mr4645951igb.38.1370120021342; Sat, 01 Jun 2013 13:53:41 -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 n5sm9917528igx.1.2013.06.01.13.53.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Jun 2013 13:53:40 -0700 (PDT) Message-ID: <51AA5F4F.9010509@gmail.com> Date: Sun, 02 Jun 2013 08:53:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <2EFF47FB-D3E5-4020-9AB6-57201CA40888@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> <51AA201E.1060407@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751C0771@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C0771@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 20:53:48 -0000 On 02/06/2013 04:33, Ted Lemon wrote: > On Jun 1, 2013, at 12:23 PM, Alexandru Petrescu wrote: >> Do we end up saying that every node in the IPv6 Internet needs at least two addresses? There is a case for s/node/interface/ in that statement. Brian From owen@delong.com Sat Jun 1 22:08:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9966E21F9E10 for ; Sat, 1 Jun 2013 22:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 iMt-nCWFswgY for ; Sat, 1 Jun 2013 22:08:08 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EDC2421F9E0F for ; Sat, 1 Jun 2013 22:08:07 -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 r5254nAg025047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Jun 2013 22:04:50 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r5254nAg025047 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370149491; bh=0n0uRChGZainFWKLRgymJNWBbOI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=38OcDp5nw1lnkCWtP7xL35AmsIRf1UCTgguTiQ3v4vkCx8K+E9z5uR3W7rODBEEkB ou3tAgObQBUbMGEW/fgyvm7kufOWSWeo/p/Kc9RGWpax/L6RfBLZWUx9/DVGySTxgL NdojcYhrTDISc8h1jCz1UH64J+XYoDhBmVMlniL8= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <51AA201E.1060407@gmail.com> Date: Sun, 2 Jun 2013 00:04:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <2EFF47FB-D3E5-4020-9AB6-57201CA40888@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C0650@mbx-01.win.nominum.com> <51AA201E.1060407@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sat, 01 Jun 2013 22:04:51 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 05:08:08 -0000 On Jun 1, 2013, at 11:23 AM, Alexandru Petrescu = wrote: > Le 01/06/2013 18:16, Ted Lemon a =E9crit : >> On Jun 1, 2013, at 8:26 AM, Sander Steffann >> wrote: >>>>> So you're arguing that every router on the internet needs a >>>>> global IP address? >>>>=20 >>>> Every node on the IPv6 internet needs a global IPv6 address. >=20 > I am divided on this. >=20 > The link local address is also mandatory. >=20 > Do we end up saying that every node in the IPv6 Internet needs at = least two addresses? >=20 Yes Owen > Alex >=20 >>>=20 >>> +1 >>=20 >> So I also +1 this, but if people are seeing traceroutes with ULAs in >> them, apparently _someone_ doesn't agree. >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Sat Jun 1 22:23:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 jeremy.duncan@salientfed.com Wed May 29 19:20:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA25121F91B8; Wed, 29 May 2013 19:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.996 X-Spam-Level: X-Spam-Status: No, score=-3.996 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80ylOn0APKa7; Wed, 29 May 2013 19:20:04 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEEC21F9301; Wed, 29 May 2013 19:20:00 -0700 (PDT) Received: from mail38-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 May 2013 02:19:59 +0000 Received: from mail38-va3 (localhost [127.0.0.1]) by mail38-va3-R.bigfish.com (Postfix) with ESMTP id 418691400AD; Thu, 30 May 2013 02:19:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I936eI542I1432Idf9Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h946hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18deh18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh17ej1155h) Received-SPF: pass (mail38-va3: domain of salientfed.com designates 157.56.234.117 as permitted sender) client-ip=157.56.234.117; envelope-from=jeremy.duncan@salientfed.com; helo=SN2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail38-va3 (localhost.localdomain [127.0.0.1]) by mail38-va3 (MessageSwitch) id 1369880397671238_24797; Thu, 30 May 2013 02:19:57 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.248]) by mail38-va3.bigfish.com (Postfix) with ESMTP id 9B6EF26004D; Thu, 30 May 2013 02:19:57 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 May 2013 02:19:55 +0000 Received: from SN2PRD0510MB370.namprd05.prod.outlook.com ([169.254.12.154]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0311.000; Thu, 30 May 2013 02:19:54 +0000 From: "Duncan, Richard (Jeremy)" To: Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcyJkAgAA3Ses= Date: Thu, 30 May 2013 02:19:54 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com>, <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> In-Reply-To: <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [::] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: salientfed.com X-Mailman-Approved-At: Sat, 01 Jun 2013 23:47:55 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 02:20:10 -0000 I tend to agree with Owen here. In fact, I am curious how an allocation fr= om a provider to a organization would look? Instead of following standard = issuing practices of a /48, are you suggesting the provider would issue mul= tiple /52s that follow functional categories (VoIP, management, etc)? Or m= aybe I missed something? 010100110110010101101101011100000110010101110010001000000100011001101001 Jeremy Duncan Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc. (Now including SGIS & Command Information I= nc.) 4000 Legato Road, Suite 600 Fairfax, VA 22033 Google Voice: 540.440.1193 jeremy.duncan@salientfed.com Owen DeLong wrote: Personally, I think this is an inherently bad idea. IP addresses need less overloading of semantics, not more. We already use IP addresses for two conflicting purposes=85 Topology locato= r and End System Identifier. This overloading is at the heart of our current scaling issues with respect= to the routing table. While these issues are currently less critical than = they have been in the past and will likely get quite a bit less critical in= IPv6, that is only because we have given up a fair amount of functionality= to preserve scalability in this regard. If we did not have this overloading, then an entity could obtain a set of e= nd-system identifiers and keep them throughout their lifetime, regardless o= f topological changes. Today, where the addresses are overloaded with both = semantics, we either have to force most entities to change their numbers wh= en they change topology or we face unsustainable growth in the routing tabl= es. The idea of adding more semantics to addressing rather than seeking to redu= ce this overloading seems a step in the wrong direction, IMHO. Owen On May 29, 2013, at 12:06 AM, Sheng Jiang wrote: > IP addresses are designed as topology locator, so that every packet can b= e routed to its network destination. > > However, even in IPv4 era, some network operators have mapped their IP ad= dress with certain semantic locally. These kind of mechanism explicitly exp= ress the semantic properties of every packet. Consequently, these network o= perators can inspect the properties of packets easily by mapping the addres= ses back to semantic. > > Network operators, who have large IPv6 address space, may also choose to = embedded some semantics into IPv6 addresses by assigning additional signifi= cance to specific bits within the prefix. draft-jiang-v6ops-semantic-prefix= documents a framework method that network operations may use their address= es with embedded semantics. These semantics bits are only meaningful within= a single network, or group of interconnected networks which share a common= addressing policy. Based on these embedded semantic bits in source/destina= tion addresses, the network operators can accordingly treat network packets= differently and efficiently. > > http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 > > Could you please review this draft and comments? It will help the documen= t become more useful information to be shared. > > Best regards, > > Sheng > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, May 28, 2013 10:28 AM >> To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang >> Subject: New Version Notification for >> draft-jiang-v6ops-semantic-prefix-03.txt >> >> >> A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt >> has been successfully submitted by Sheng Jiang and posted to the >> IETF repository. >> >> Filename: draft-jiang-v6ops-semantic-prefix >> Revision: 03 >> Title: A Framework for Semantic IPv6 Prefix >> Creation date: 2013-05-28 >> Group: Individual Submission >> Number of pages: 19 >> URL: >> http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03= .txt >> Status: >> http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix >> Htmlized: >> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-v6ops-semantic-prefix-03 >> >> Abstract: >> This document describes a framework method that network operations >> may use their addresses. Network operators, who have large IPv6 >> address space, may choose to embedded some semantics into IPv6 >> addresses by assigning additional significance to specific bits >> within the prefix. By embedded semantics into IPv6 prefixes, the >> semantics of packets can be inspected easily. Routers and other >> intermediary devices can easily apply relevant policies as required. >> Packet-level differentiation can also enable flow-level and user- >> level differentiation. Consequently, the network operators can >> accordingly treat network packets differently and efficiently. The >> management and maintenance of networks can be much simpler. >> >> >> >> >> The IETF Secretariat > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From jeremy.duncan@salientfed.com Thu May 30 12:30:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922C121F9413; Thu, 30 May 2013 12:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMIaw-SIGfXS; Thu, 30 May 2013 12:30:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3CB21F93FF; Thu, 30 May 2013 12:30:02 -0700 (PDT) Received: from mail56-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 May 2013 19:30:01 +0000 Received: from mail56-va3 (localhost [127.0.0.1]) by mail56-va3-R.bigfish.com (Postfix) with ESMTP id 39E8D2A00C9; Thu, 30 May 2013 19:30:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I936eI542I1432Idf9Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1155h) Received-SPF: pass (mail56-va3: domain of salientfed.com designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=jeremy.duncan@salientfed.com; helo=BY2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail56-va3 (localhost.localdomain [127.0.0.1]) by mail56-va3 (MessageSwitch) id 1369942197699664_27880; Thu, 30 May 2013 19:29:57 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.244]) by mail56-va3.bigfish.com (Postfix) with ESMTP id A65221A0173; Thu, 30 May 2013 19:29:57 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 May 2013 19:29:57 +0000 Received: from BY2PRD0510MB366.namprd05.prod.outlook.com ([169.254.5.143]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0311.000; Thu, 30 May 2013 19:29:51 +0000 From: "Duncan, Richard (Jeremy)" To: Sheng Jiang , Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcyJkAgAA3SeuAAEobgIAA1Jq2 Date: Thu, 30 May 2013 19:29:50 +0000 Message-ID: <923297B868FB664FBFA90FCC255696DF591E69CC@BY2PRD0510MB366.namprd05.prod.outlook.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com>, <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> , <5D36713D8A4E7348A7E10DF7437A4B923AC9927B@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC9927B@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.3.40.3] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: salientfed.com X-Mailman-Approved-At: Sat, 01 Jun 2013 23:47:55 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:30:07 -0000 Sheng-=0A= =0A= Not following.. If the provider puts semantics on bits 30-32, and I had a = need for services covered by other bits I would then need to have a multi-d= isparate allocation of say (3) /48s - or (3) /52s, whatever. Then the prov= ider will have a lot of unused space inside their /30 for services.=0A= =0A= I just don't understanding why using HbH options, TC for DiffServ or the FL= doesn't already answer the mail? If this was my providers plan, I would s= hop for another provider.=0A= =0A= =0A= 010100110110010101101101011100000110010101110010001000000100011001101001=0A= =0A= Jeremy Duncan=0A= Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc.=0A= (Now including SGIS & Command Information Inc.)=0A= 4000 Legato Road, Suite 600 Fairfax, VA 22033=0A= Google Voice: 540.440.1193=0A= jeremy.duncan@salientfed.com=0A= =0A= ________________________________________=0A= From: Sheng Jiang [jiangsheng@huawei.com]=0A= Sent: Thursday, May 30, 2013 2:45 AM=0A= To: Duncan, Richard (Jeremy); Owen DeLong=0A= Cc: ; draft-jiang-v6ops-semantic-prefix@tools.ietf.org; ipv= 6@ietf.org=0A= Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jia= ng-v6ops-semantic-prefix-03=0A= =0A= Hi, Duncan,=0A= =0A= Actually, you question is very detailed scenario in the approach. The answe= r is the provider still assign a /48 to an organization. But within the ass= igned /48, some bit (for example, bit no. 30~32) has some semantic (for exa= mple, need extra security processing) for the assigning provider. Then, whe= n the provider received packets from such organizations (there are multiple= enterprise has the same semantic and the same bit no. 30~32), it can treat= accordingly.=0A= =0A= Best regards,=0A= =0A= Sheng=0A= =0A= >-----Original Message-----=0A= >From: Duncan, Richard (Jeremy) [mailto:jeremy.duncan@salientfed.com]=0A= >Sent: Thursday, May 30, 2013 10:20 AM=0A= >To: Owen DeLong=0A= >Cc: Sheng Jiang; ;=0A= >draft-jiang-v6ops-semantic-prefix@tools.ietf.org; ipv6@ietf.org=0A= >Subject: Re: [v6ops] Could IPv6 address be more than=0A= >locator?//draft-jiang-v6ops-semantic-prefix-03=0A= >=0A= >I tend to agree with Owen here. In fact, I am curious how an allocation= =0A= >from a provider to a organization would look? Instead of following standa= rd=0A= >issuing practices of a /48, are you suggesting the provider would issue=0A= >multiple /52s that follow functional categories (VoIP, management, etc)? = Or=0A= >maybe I missed something?=0A= >=0A= >=0A= >010100110110010101101101011100000110010101110010001000000100011=0A= >001101001=0A= >=0A= >Jeremy Duncan=0A= >Senior Director, IPv6 Network Architect=0A= >Salient Federal Solutions, Inc. (Now including SGIS & Command Information= =0A= >Inc.)=0A= >4000 Legato Road, Suite 600=0A= >Fairfax, VA 22033=0A= >Google Voice: 540.440.1193=0A= >jeremy.duncan@salientfed.com=0A= >=0A= >Owen DeLong wrote:=0A= >=0A= >=0A= >Personally, I think this is an inherently bad idea.=0A= >=0A= >IP addresses need less overloading of semantics, not more.=0A= >=0A= >We already use IP addresses for two conflicting purposes=85 Topology locat= or=0A= >and End System Identifier.=0A= >=0A= >This overloading is at the heart of our current scaling issues with respec= t to=0A= >the routing table. While these issues are currently less critical than the= y have=0A= >been in the past and will likely get quite a bit less critical in IPv6, th= at is only=0A= >because we have given up a fair amount of functionality to preserve=0A= >scalability in this regard.=0A= >=0A= >If we did not have this overloading, then an entity could obtain a set of= =0A= >end-system identifiers and keep them throughout their lifetime, regardless= of=0A= >topological changes. Today, where the addresses are overloaded with both= =0A= >semantics, we either have to force most entities to change their numbers= =0A= >when they change topology or we face unsustainable growth in the routing= =0A= >tables.=0A= >=0A= >The idea of adding more semantics to addressing rather than seeking to=0A= >reduce this overloading seems a step in the wrong direction, IMHO.=0A= >=0A= >Owen=0A= >=0A= >On May 29, 2013, at 12:06 AM, Sheng Jiang =0A= >wrote:=0A= >=0A= >> IP addresses are designed as topology locator, so that every packet can = be=0A= >routed to its network destination.=0A= >>=0A= >> However, even in IPv4 era, some network operators have mapped their IP= =0A= >address with certain semantic locally. These kind of mechanism explicitly= =0A= >express the semantic properties of every packet. Consequently, these netwo= rk=0A= >operators can inspect the properties of packets easily by mapping the=0A= >addresses back to semantic.=0A= >>=0A= >> Network operators, who have large IPv6 address space, may also choose to= =0A= >embedded some semantics into IPv6 addresses by assigning additional=0A= >significance to specific bits within the prefix.=0A= >draft-jiang-v6ops-semantic-prefix documents a framework method that=0A= >network operations may use their addresses with embedded semantics. These= =0A= >semantics bits are only meaningful within a single network, or group of=0A= >interconnected networks which share a common addressing policy. Based on= =0A= >these embedded semantic bits in source/destination addresses, the network= =0A= >operators can accordingly treat network packets differently and efficientl= y.=0A= >>=0A= >> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03=0A= >>=0A= >> Could you please review this draft and comments? It will help the docume= nt=0A= >become more useful information to be shared.=0A= >>=0A= >> Best regards,=0A= >>=0A= >> Sheng=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=0A= >>> Sent: Tuesday, May 28, 2013 10:28 AM=0A= >>> To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang=0A= >>> Subject: New Version Notification for=0A= >>> draft-jiang-v6ops-semantic-prefix-03.txt=0A= >>>=0A= >>>=0A= >>> A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt=0A= >>> has been successfully submitted by Sheng Jiang and posted to the=0A= >>> IETF repository.=0A= >>>=0A= >>> Filename: draft-jiang-v6ops-semantic-prefix=0A= >>> Revision: 03=0A= >>> Title: A Framework for Semantic IPv6 Prefix=0A= >>> Creation date: 2013-05-28=0A= >>> Group: Individual Submission=0A= >>> Number of pages: 19=0A= >>> URL:=0A= >>>=0A= >http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03.t= xt=0A= >>> Status:=0A= >>> http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix=0A= >>> Htmlized:=0A= >>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03=0A= >>> Diff:=0A= >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-v6ops-semantic-prefix-03= =0A= >>>=0A= >>> Abstract:=0A= >>> This document describes a framework method that network operations=0A= >>> may use their addresses. Network operators, who have large IPv6=0A= >>> address space, may choose to embedded some semantics into IPv6=0A= >>> addresses by assigning additional significance to specific bits=0A= >>> within the prefix. By embedded semantics into IPv6 prefixes, the=0A= >>> semantics of packets can be inspected easily. Routers and other=0A= >>> intermediary devices can easily apply relevant policies as required.= =0A= >>> Packet-level differentiation can also enable flow-level and user-=0A= >>> level differentiation. Consequently, the network operators can=0A= >>> accordingly treat network packets differently and efficiently. The=0A= >>> management and maintenance of networks can be much simpler.=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> The IETF Secretariat=0A= >>=0A= >> _______________________________________________=0A= >> v6ops mailing list=0A= >> v6ops@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/v6ops=0A= >=0A= >--------------------------------------------------------------------=0A= >IETF IPv6 working group mailing list=0A= >ipv6@ietf.org=0A= >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A= >--------------------------------------------------------------------=0A= >=0A= =0A= From Ted.Lemon@nominum.com Sat Jun 1 23:52:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 fred@cisco.com Sat Jun 1 23:55:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0E621F9B79 for ; Sat, 1 Jun 2013 23:55:19 -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 qKnC1-dcY2VS for ; Sat, 1 Jun 2013 23:55:13 -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 A6BD421F9B78 for ; Sat, 1 Jun 2013 23:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=465; q=dns/txt; s=iport; t=1370156113; x=1371365713; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=69N7vYzlp8FPRHVgi6X/jaqbUwJczdIZJdBAlH/TqHU=; b=epyopAjnY+yr32GmorWzzyaZ71I0pE89eSqPrxAsOPoNp3Jeqc+ERcbh d1nlmktGXFaWgH6v21a5QLlMxL38htHKpPz4qn3BFtM6HqJGjW3rmVmom ZtRGfNzlzG3STrxDC0kNwQyzw8OGk5jd/HtB8xODWBwykKKTn/hlC2w+g k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwFAATrqlGtJXG+/2dsb2JhbABagwmDJbwNfBZ0giMBAQEDAXkFCwIBCCIkMiUCBA4FCId/BrlRjnQCMQeCd2EDiGigFoMPgic X-IronPort-AV: E=Sophos;i="4.87,788,1363132800"; d="scan'208";a="214725571" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 02 Jun 2013 06:55:13 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r526tDM5018756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Jun 2013 06:55:13 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; Sun, 2 Jun 2013 01:55:12 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOX14g3JR9ETV05UGviTFopg2Tjg== Date: Sun, 2 Jun 2013 06:55:11 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B900C02@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.74.48] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 06:55:19 -0000 On May 29, 2013, at 11:41 PM, Lorenzo Colitti wrote: > Of course, in the case of ULAs, there's not much that can be done about t= he design at this point, but we should make an effort to make it clear that= the potential for misconfiguration exists and provide clear guidance on ho= w not to misconfigure them. And how to avoid leakage, by not including them in announcements and by ref= using them in BGP acceptance policies...= From owen@delong.com Sun Jun 2 09:02:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 Date: Sun, 2 Jun 2013 16:47:16 -0400 To: Tim Chown Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 Date: Sun, 2 Jun 2013 16:51:03 -0400 To: Owen DeLong Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 Date: Sun, 2 Jun 2013 17:25:28 -0400 To: Tim Chown Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 ales.vizdal@t-mobile.cz Sun Jun 2 14:37:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56121F911B for ; Sun, 2 Jun 2013 14:37:35 -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 OdoFP-nUm7ll for ; Sun, 2 Jun 2013 14:37:30 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id DF1EE21F9050 for ; Sun, 2 Jun 2013 14:37:29 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id C17552E081B; Sun, 2 Jun 2013 23:37:25 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([::1]) with mapi; Sun, 2 Jun 2013 23:37:28 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "aservin@lacnic.net" , "v6ops@ietf.org" Date: Sun, 2 Jun 2013 23:37:26 +0200 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: Ac5dJG4rE1gcBVmRSW2BDrPW/bKTmwCsyZ6Q Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895DBCF57@SRVHKE02.rdm.cz> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <5f5db848326ae00c249cff068956b4fc@mail.lacnic.net.uy> In-Reply-To: <5f5db848326ae00c249cff068956b4fc@mail.lacnic.net.uy> 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 21:37:35 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= aservin > Sent: Thursday, May 30, 2013 12:51 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jian= g-v6ops- > semantic-prefix-03 >=20 >=20 > >>> Sheng > >>> > >>I completely understand the desire for operators to have additional > >>semantics available for customized packet processing. Flow label now > >>has very limited properties optimised for load balancers. DSCP only > >>has a few bits (way less than the number of customers' policies). ACLs > >>are heavy to process at each hop.... > >> > >>But wouldn't this information be better off encoded as tags in one or > >>more hop-by-hop header options (that could be re-written on the fly), > >>rather than encoded in the IPv6 address space? > > > > The section 4.1 "Justifcation for Semantics with the IPv6 Prefix" > > describes the reasons. > > > > Users may easily change the setting of extension header in order to > > obtain undeserved priorities/privileges. Semantic prefix approach does > > require the deployment of access control filters. The packets with the > > noncompliance source addresses should be filtered. The prefix is > > delegated by the network. Therefore the network is able to detect any > > undesired modifications and filter the packet accordingly. > > > > Cheers, > > > > Sheng > > > >>regards, > >>RayH >=20 > I think the user can play the system too with IP addresses. It may be= more > complicated but it may be possible with the enough motivation to do so. Yes, a user can make such changes, but if he changes IP addressing his serv= ice is most likely to stop working. Let's leave prefix to application mapping a= side for=20 this moment and let's assume a case where the network is providing a user with a prefix per service (e.g. voice, video, tv and Internet), each= prefix is providing an access to the designated service only (ie. voice prefix will n= ot be able=20 to reach Internet and vice versa for the Internet prefix). Playing with IP = addressing will not provide any benefit as the service will not be available compared = to the DSCP case where setting a different value may change QoS. > /as Cheers, Ales From albert.e.manfredi@boeing.com Sun Jun 2 15:31:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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" 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Ted.Lemon@nominum.com Sun Jun 2 16:14:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 brian.e.carpenter@gmail.com Sun Jun 2 16:39:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: "Manfredi, Albert E" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 bmanning@isi.edu Sun Jun 2 16:06:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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 X-Mailman-Approved-At: Sun, 02 Jun 2013 16:59:18 -0700 Cc: "Manfredi, Albert E" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 albert.e.manfredi@boeing.com Sun Jun 2 17:13:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E249221F89A6 for ; Sun, 2 Jun 2013 17:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRacqLPPm9HJ for ; Sun, 2 Jun 2013 17:40:50 -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 1B7B921F896D for ; Sun, 2 Jun 2013 17:40:49 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id o13so1509085qaj.18 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=jD3ekxuHscQIjJg6L2XYJsp/Cq4NomMQXOazdj7IdXMaB3TJZiaGslcW30Ebr1/QaH +JkaFRGlVsnIp7WSWJGicXw7qTPLmk/2vr1KO7Y05Ca1iu9sxg/qVWpl6yoHGPXKOfz3 F9mPCpliLQKuBWS4MYmsovWhJjDn0ccpBpNJOwUQyIDl8fp0AQW9LaAj9nw+bq5dDCAe r+RB3b0798/DwK4JOB1gMxauprHeUwRi0Iz3u36kCwuPauPiplgTIX1YgWqXJUI10Gbf mSsEg2qbLed56KQP8jUErrbhyigXdV0MWzJ/6mU8ZVYfInFj0xFdoEF3eLhePXOw8crG gKeQ== 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: To: Tim Chown Content-Type: multipart/alternative; boundary=20cf300fb23d0d197004de35371f X-Gm-Message-State: ALoCoQlj5WDzQLWiGdJ0qJwGe5JGwJD21lTldw8KnH0XLh9/cavPBcYmFyo0TXicp4ts78VqCUpqDFLUKB56bgbzc6w5tILXfGFPfHzxOFf4/6hiCcKAES68RjnPq7SY63vv4dLC50Q11DBEfGzFkTNYPdAzIxX/bWHe19z56nvwj27EPCFkYyrkkwkryA7aCWERh+EW+GlI Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3725821F89D5 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.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, 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 TnTM5dZkIdc5 for ; Sun, 2 Jun 2013 17:48:29 -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 9283821F86F0 for ; Sun, 2 Jun 2013 17:48:29 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l11so1817286qcy.23 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=erEzsQELx7t/cUmVp1Q6ATdVdCaWhxeVffdRAaogKPcVBz2oT23Zom/YYP2XpOxqqz Kfca2NG0E7oBTSu0WAAN9K9Uv19ygyhiK6Giqd1B23V5XZW14MzGuNNRAsHG2IZUQjg2 recs4AIz/k3pGBAkGm5m4cJoyGfDl79qtpieoJ5AXC6OiKivu5Cr81HcKw2LZXFFc7FI +hyVMRO5xan5SkWsspdOTpDuG/RdujcLw1lnrMc4vOYbXYs21cGGE9Qy/TbPBmaMvDfU mm6sIcP2AOKBXvpchuLGsSWd2WurImB0ue7nFBFlJAoS5DPLnVcV7GEc8d0Z+DyPB8OK ZJRw== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=00235452fd9cb2fecb04de355264 X-Gm-Message-State: ALoCoQlw4Xkww4p6ldsSK/0JpmRm4NT3DElTKzhHkrwLMtVXs3J6ug2gzul6bVETtigNV5KdSI3+4PGURD3+wMbvWJHQbSoMgeNej+5daQB3x7ibOPW6/6zaNn9aifLWcbyCHXuF/rdA8c9RodP/VA/U5QLrM8/dwh7bQNUEjEZTvab7oKigrxyVyAKf4bXk2uDsFOcGQt2e Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AA521F8EF7 for ; Sun, 2 Jun 2013 17:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=0.250, 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 I7R09oMO6zCW for ; Sun, 2 Jun 2013 17:51:41 -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 4916921F8E9D for ; Sun, 2 Jun 2013 17:51:41 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id q19so2002163qeb.18 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=jzyY7WEKy4m1jLFJyUe4aew2+J0LoVe4eu7K5lAHw2nmhBVjbv8JbWX3z+dPi7EwIg pCPMzwU8gzQ2XJKKFLq7ky7Ikjrw4DY2BlOzhI2sOfrfe4tOeP0zAXPkzYcf7hlkTF91 oXRhipH0qTwJhT0IjdFPomYQRWhI3dWKThGgKW8+416S/sn2fP1DURCG3tVhjWPccNxe IKnqeeWtp+EilFIS3tQj95sJ9l+IUtLXjnOqZmq2P6yihiEpq29jGXdsfZSP84c1xy00 yCVV3vK/hakmGGlw0doheYkR2smM8VinTOWCABAam2tI/hbFuMPMepj48w63ba/WDxIq rjpg== 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: To: Ralph Droms Content-Type: multipart/alternative; boundary=001a11c29f6021dfcf04de355e31 X-Gm-Message-State: ALoCoQlUZPBtV8lvHhWkVc1lKFXgmb0nWs2Y7ngbmLXHcOI/7N6ImdXKJeIhTiBL7zc4gGu3+m6AzZXdR6upkU931EsG1as7vgu7hzSdTXaDJSZ2feE+wjAvXUWz/wSifDP+BHWaP7WvRkg+LBxCiHlwMXdHONNsSS+4YvJ/9XIjvLNnp4sklJRFSvPdAxXBIGCrg1zvwg/l Cc: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 00:51:46 -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 Ted.Lemon@nominum.com Sun Jun 2 19:50:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8520321F8F12 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.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 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 y7JNyvP0tBIA for ; Sun, 2 Jun 2013 20:23:24 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E8AA721F8D2B for ; Sun, 2 Jun 2013 20:23:23 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bv4so1560078qab.19 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=QGiqFZ5FazM+2erFByo3dMLdso+h1DwquXsmpkZw539ZErVf2/UuDDSIfMEek6TlBX wDqzupqYy3wCoqT77QGFxyXulJSDXEGo/0FNWlp1Vz7rtK2Yr+xXdderjW0t6RmESTMF fewSlQSF4k0dxswXEyWVXIpFdlQVwhp1dajapyY5hfx+5W5kHupAaMIKuSM1G8lvB4ZG mstSnif1RJVjlWeQW5qb94yxkBnHkuHzWjTmKWBO08Hb2LroZHoOOqkt9FUyOuiftWQe fFQX7/ScLjDceiUtF1IPv8g4hFnan/3t71AhpUKxp1cDV6FYohtLD3wDc/haErs+pRVz 1Ufg== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf300fb23daf45b404de377cb6 X-Gm-Message-State: ALoCoQnCCRV7zl9ZWtDqCjZG0DsXFFHQ2HGrogVggNQlIVg4MHIbKf9jZMhQYNWh6yeFxlO+vLE7gBBNXlqkACw0cTnMk/z3RJFmDsqC3KozHCPF9Ym5zn1raJRSBfVJotu9zYXx+tZhzgL5KjjoQ+ReNECysurestwiVWINJLoWHOZwtVFrU6QA2QuX1UMZ59JvvlXJd3lj Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 shengjiang@gmail.com Mon Jun 3 00:28:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: Shane Amante Content-Type: multipart/alternative; boundary=001a11c2672a72e5fb04de3ae750 Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=089e0158c2ac209ca504de3b5165 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 simon.perreault@viagenie.ca Mon Jun 3 01:42:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA0521F8267 for ; Mon, 3 Jun 2013 01:41:58 -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 ISKl+66DpYcC for ; Mon, 3 Jun 2013 01:41:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BADAB21F8206 for ; Mon, 3 Jun 2013 01:41:56 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C1E9D4149F for ; Mon, 3 Jun 2013 04:41:55 -0400 (EDT) Message-ID: <51AC56D3.4070501@viagenie.ca> Date: Mon, 03 Jun 2013 10:41:55 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 08:42:04 -0000 Le 2013-06-01 17:35, Nalini Elkins a écrit : > The second reason for not having a fragment header is that > unfortunately, a number of firewalls, etc, drop packets which contain > IPv6 fragment headers. About that: I would guess that the number of firewalls that will drop a new option header will be greater than the number of firewalls that currently drop fragment headers. So the current situation with firewalls would argue in favour of using the fragment header... Simon From bmanning@isi.edu Sun Jun 2 19:47:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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 X-Mailman-Approved-At: Mon, 03 Jun 2013 04:40:33 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 lorenzo@google.com Mon Jun 3 05:17:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0714521F961B for ; Mon, 3 Jun 2013 05:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 1nDnmswW4EBu for ; Mon, 3 Jun 2013 05:17:51 -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 730C321F9630 for ; Mon, 3 Jun 2013 05:17:46 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id e1so2052494qcy.8 for ; Mon, 03 Jun 2013 05:17: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=Q0dkdD0sb7dtv6cBAaylWPEgA6S8WU9PyhpeA7hdDZE=; b=cRch0RNnujqu4x2Pvm+VNziOs3PFiivHeYoVSUyR7m7rK14vIXt2rR4haLhxKEGDf4 YhIwHZEbUHqrCciYWxokuI5i5mfoyxYxfRFR9JxQ3q1ZixkKFSQmZy9d43UiQ0bBMLUK ZjGXi4Yv5xd3XvTXhDwoxT2YTUYJ8WSb9h10TvkR2BtsygAAY4a76HJ1Ezr3WWOtgEZr 6pZ4n64KC5HIn5DfEBb3yhhNfvdBa/mu9AQujGzGJH6xflMB3YfF8oha1ypp71E4oo0l Tgup4+duMLk+6bSaYMDd/HeSKn+m0nYnOzuZXBgueug02MYu4n9gIrIppyLZj8NBFmV8 yW0g== 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=Q0dkdD0sb7dtv6cBAaylWPEgA6S8WU9PyhpeA7hdDZE=; b=Z+imr3RIQO+Y/tAAuTC8QXT8l8/ryuf3Z7Zh0E3SBCeIS3uRVgOFcmo2mr7l7ahlT1 g+9yo8hXlpMcP59yLZG1ITjPIKKvJtcadbgDeK0oTGj7+pGrnOPHJ3gpMdbudvpeHA+H QcFRDrtRvQ9tjubQ1go+C2qnBqHvqvaqjQXytVccvivYZ8ZbLoRf0LIlpjIKutWVSG0E ZWX2YY/w0QEp23E22WvXte9YbFVv6as4rUWCJ3q7hsAujWbbEtpHgPzBw9NDFZhXSVpb HQXT5eWo8qEC+alUf35bx5+XA1XA9BP7rLG4qE4vjAQ5euWAQO7mf6rzrbfw9MceD+3t 6HMg== X-Received: by 10.49.71.203 with SMTP id x11mr21707402qeu.19.1370261865088; Mon, 03 Jun 2013 05:17:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Mon, 3 Jun 2013 05:17:24 -0700 (PDT) In-Reply-To: <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Mon, 3 Jun 2013 21:17:24 +0900 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=047d7b6dc474b80ac904de3ef38a X-Gm-Message-State: ALoCoQnY8G30wqgXqPPW2YHgJjyizqeHVTa09NM94GdWDuOMKzhvIIa2RXPhTLBcG+5GM6S2h/0uNLH8kaF8fIyS4HbtgkERqkhNuL2I54Jv3tVoy028yY1fOQYNwtruG9oNOdCgt6Q9b4/xSU1ZnjxsyUVvU3LjEn6k+L+riMgWJKFJIMoYT8Pp54wDJcwt2fcW/UYzURqK Cc: "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:17:52 -0000 --047d7b6dc474b80ac904de3ef38a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 2, 2013 at 12:35 AM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > The second reason for not having a fragment header is that unfortunately, > a number of firewalls, etc, drop packets which contain IPv6 fragment > headers. I find this to be unsuitable behavior which I hope will change . > But, it is the reality. > Those boxes will drop your proposed header as well. --047d7b6dc474b80ac904de3ef38a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 2, 2013 at 12:35 AM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
The second reason= for not having a fragment header is that unfortunately, a number of firewa= lls, etc, drop packets which contain IPv6 fragment headers. =A0I find this = to be unsuitable behavior which I hope will change . =A0 But, it is the rea= lity.

Those boxes will drop your proposed = header as well.=A0
--047d7b6dc474b80ac904de3ef38a-- From owen@delong.com Mon Jun 3 05:18:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 nalini.elkins@insidethestack.com Mon Jun 3 05:28:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B658421F96DF for ; Mon, 3 Jun 2013 05:28:13 -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.149, 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 bWz1Va5leTUv for ; Mon, 3 Jun 2013 05:28:07 -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 B9B0721F96B1 for ; Mon, 3 Jun 2013 05:28:07 -0700 (PDT) Received: from [66.94.237.126] by nm5.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 12:28:07 -0000 Received: from [66.94.237.118] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 12:28:06 -0000 Received: from [127.0.0.1] by omp1023.access.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 12:28:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 982179.82361.bm@omp1023.access.mail.mud.yahoo.com Received: (qmail 93176 invoked by uid 60001); 3 Jun 2013 12:28:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370262486; bh=jWej0OOS85d9gsEKHPF1tdM2bJR4fOD/39tWqqB91SY=; 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=vELNfmS/ZGgzDS1IRuqGDWFZO17dQkyUFxSf3LRYJ8l4mW+xs1tXMobWw39yyn5bGyoxpxBBXQsedZuaD+Hx4cmaTvp4Vc3qUzV/qObRJ6JFmxaO41gfb9p/2tkhSiyVX5fej7n0CWRUjGm26XvAugLDepA7d6XA0CE1XM7l+ng= X-YMail-OSG: 0vQXbccVM1lHnLqowzy_bM9MCLQCT3GjyTu6LVF7qcRYbrS Gw.OsAi5CG_16c6YU9f2CHfSr47aHvONYW73kS1bgtSB5Flo3VmT7pDRb1oQ OhGSRBnFDB8BBORT85Tq_UlYoVV7wVo1vJ3DiSi1BakEjj1gmPuaX1_aQ1nw lTZgqzu66isaKpQR_i0fdvQkstlhpaoALyiVOpe5AsXzHJ2ZWJhFR_FL.P.U uvMIzXplNXJYH4P3T.W1nw5A144VjifX2Yus7QGgTIzwg8w1__S9r3l5Kk0G sdw1NWDDKbhae9QCmc4uKdT5bN06A1LqBN61tXDf77qKWdF5JzqAm29qd6O0 lWsCy8vifgXOiKq_OOaxNevDYVmVTpuLbFHon_VKfgQRNu8iOvQKPLX0VvrF izqJBdMsu1O5XS9_6GzSiiP7gs9rUnMyJw6OR84gK4ZLqSrssuCDxQ2gkDYR eNNfDOlCK2sPe8ATG1mZ3fotx5a6ZwxU4blTByhhOzE5iHN2XY1Ck037E_HF kPFcpjoCfuf1vrTqPMgvrhbBDG.GV2ck9tiG_xMcwTtDAfw.dhlfkeCeacCa d_wXdF6.GPgrFf7YagFmAjVNstCxEF2kNZshKyAKxSKm_TqJW652PdM7Bq00 3LSjBJ2n3VylhTWLVutAak97X Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 05:28:06 PDT X-Rocket-MIMEInfo: 002.001, QWN0dWFsbHksIEkgc2hvdWxkIG5vdCBoYXZlIHVzZWQgdGhlIHBvaW50IGFib3V0IGhlYWRlciBkcm9wcGluZyBhcyBhIHJlYXNvbi4KCklmIGNvbXBhbmllcyBmaW5kIHRoYXQgdGhlIG5ldyBoZWFkZXIgd2UgcHJvcG9zZSBnaXZlcyB0aGVtIGNhcGFiaWxpdGllcyB0aGF0IHRoZXkgd2FudCwgdGhlbiB0aGV5IHdpbGwgbWFrZSBzdXJlIHRoZWlyIGZpcmV3YWxscyBhcmUgY29uZmlndXJlZCB0byBub3QgZHJvcCB0aGUgaGVhZGVyLgoKSSBmZWVsIHRoYXQgdGhlIGNhcGFiaWxpdGllcyBvZiBwYWNrZXQgc2UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Message-ID: <1370262486.91755.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 05:28:06 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1843410849-1370262486=:91755" Cc: "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:28:13 -0000 ---1551098171-1843410849-1370262486=:91755 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Actually, I should not have used the point about header dropping as a reaso= n.=0A=0AIf companies find that the new header we propose gives them capabil= ities that they want, then they will make sure their firewalls are configur= ed to not drop the header.=0A=0AI feel that the capabilities of packet sequ= ence number AND end-to-end response time without agents will be quite attra= ctive to many. =A0So, they will make sure they get the firewalls under thei= r control get these headers so they do not lose the diagnostic capabilities= .=0A=0AFragment header is not enough.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins= =0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A= =0A________________________________=0A From: Lorenzo Colitti =0ATo: Nalini Elkins =0ACc: Fred B= aker (fred) ; Dan Wing (dwing) ; "v6ops@ie= tf.org" ; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@too= ls.ietf.org" = =0ASent: Monday, June 3, 2013 5:17 AM=0ASubject: Re: [v6ops] new draft: dra= ft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn Sun, Jun 2, 2013 a= t 12:35 AM, Nalini Elkins wrote:=0A=0ATh= e second reason for not having a fragment header is that unfortunately, a n= umber of firewalls, etc, drop packets which contain IPv6 fragment headers. = =A0I find this to be unsuitable behavior which I hope will change . =A0 But= , it is the reality.=0A>=0A=0AThose boxes will drop your proposed header as= well.=A0 ---1551098171-1843410849-1370262486=:91755 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Actually, I should no= t have used the point about header dropping as a reason.

If c= ompanies find that the new header we propose gives them capabilities that t= hey want, then they will make sure their firewalls are configured to not dr= op the header.

<= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: arial, helveti= ca, sans-serif; background-color: transparent; font-style: normal;">I feel that the capabilities of packet sequence number AND end-to-end = response time without agents will be quite attractive to many.  So, th= ey will make sure they get the firewalls under their control get these head= ers so they do not lose the diagnostic capabilities.

Fragment header is not enough.
 
Thanks,

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

=
From: Lorenzo C= olitti <lorenzo@google.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
= Cc: Fred Baker (fred) <= fred@cisco.com>; Dan Wing (dwing) <dwing@cisco.com>; "v6ops@ietf.o= rg" <v6ops@ietf.org>; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" <draft-el= kins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org>
Sent: Monday, June 3, 2013 5:17 AM
<= b>Subject: Re: [v6ops] new dr= aft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0A
= On Sun, Jun 2, 2013 at 12:35 AM, Nalini Elkins <nalini.elkins@ins= idethestack.com> wrote:
=0A=0A
The second reason for not having a fragment header is= that unfortunately, a number of firewalls, etc, drop packets which contain= IPv6 fragment headers.  I find this to be unsuitable behavior which I= hope will change .   But, it is the reality.
=0A=0A

Those boxes will drop your proposed header as = well. 
=0A


<= /div> ---1551098171-1843410849-1370262486=:91755-- From Ted.Lemon@nominum.com Mon Jun 3 05:33:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 brian@innovationslab.net Mon Jun 3 05:33:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B357821F96EC for ; Mon, 3 Jun 2013 05:33:42 -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 TbzE7XMIDaqL for ; Mon, 3 Jun 2013 05:33:37 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7662121F969F for ; Mon, 3 Jun 2013 05:33:37 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 22D3888112 for ; Mon, 3 Jun 2013 05:33:37 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E25B414000C for ; Mon, 3 Jun 2013 05:33:36 -0700 (PDT) Message-ID: <51AC8D23.3070702@innovationslab.net> Date: Mon, 03 Jun 2013 08:33:39 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> <51A97918.9070404@massar.ch> <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> In-Reply-To: <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:33:42 -0000 On 6/1/13 12:33 AM, Owen DeLong wrote: > > On May 31, 2013, at 9:31 PM, Jeroen Massar wrote: > >> On 2013-05-31 21:07, Brian E Carpenter wrote: >> [..] >>> Agreed. But when it does get through, it does no particular >>> harm (you just see a bizarre hop in the traceroute). If it got >>> through in a SYN/ACK exchange, it would probably distress a user. >> >> If such a packet gets through it means BCP38 is not applied as things >> are not properly filtered. >> > > This has nothing to do with BCP38. > > Any router which forwards a packet containing a link local address in the header is broken regardless of any BCP38 configuration. > The IPv6 Scoped Addressing Architecture covers this for less-than-global scoped addresses... https://tools.ietf.org/html/rfc4007#section-9 Regards, Brian From Ted.Lemon@nominum.com Mon Jun 3 05:42:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 gvandeve@cisco.com Mon Jun 3 05:43:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4962821F969F for ; Mon, 3 Jun 2013 05:43:32 -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 YcEA3ZCgY6zO for ; Mon, 3 Jun 2013 05:43:26 -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 B792B21F9643 for ; Mon, 3 Jun 2013 05:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1082; q=dns/txt; s=iport; t=1370263406; x=1371473006; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=F2jCzd2pmNICe7hd7xfsokobPQbq9C183jru7Du3fHk=; b=ZrupFCZdUx44eTS0rhCvbQqI0iGOrKQOcFN0Ifd0E7JjudsX9fJJAGmY eYOaVsH/+u+2FCQIKxSNe99tz5nb1BrIN2HxjSRkaRfU8INBWoy0+BXVu BAGWt5ZxRZglC0qS5TWAxjWNU5JfsM5iP2umEhfLmwI9OQsRvxCdBfeJH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAECOrFGtJV2d/2dsb2JhbABZgwm/NIEAFnSCIwEBAQMBOj8FBwQCAQgRBAEBCxQJBzIUCQgCBAENBQiHfwa7A452MQcGgnFhA6h+gw+CJw X-IronPort-AV: E=Sophos;i="4.87,792,1363132800"; d="scan'208";a="218126694" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jun 2013 12:43:26 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r53ChQ0I015142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 12:43:26 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.172]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 07:43:25 -0500 From: "Gunter Van de Velde (gvandeve)" To: "Fred Baker (fred)" , Lorenzo Colitti Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDEFTYeH7/3pEm2/YK3ImKhPZkiVhCAgAGeLnA= Date: Mon, 3 Jun 2013 12:43:24 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240CEBF9C9@xmb-aln-x12.cisco.com> References: <8C48B86A895913448548E6D15DA7553B900C02@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B900C02@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.201.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:43:32 -0000 Look for GV> -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker (fred) Sent: 02 June 2013 08:55 To: Lorenzo Colitti Cc: v6ops@ietf.org WG; draft-ietf-v6ops-ula-usage-recommendations@tools.iet= f.org Subject: Re: [v6ops] A good example of why we need to careful about ULAs On May 29, 2013, at 11:41 PM, Lorenzo Colitti wrote: > Of course, in the case of ULAs, there's not much that can be done about t= he design at this point, but we should make an effort to make it clear that= the potential for misconfiguration exists and provide clear guidance on ho= w not to misconfigure them. And how to avoid leakage, by not including them in announcements and by ref= using them in BGP acceptance policies... GV> is the recommendation on BGP filters which is done in draft-ietf-opsec-= bgp-security in "section 5.1.1 Prefixes that MUST not be routed by definiti= on" maybe a reference worthy? This section clearly specifies the fact that = ULA should be filtered.=20 G/ From gvandeve@cisco.com Mon Jun 3 05:47:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F02621F96E1 for ; Mon, 3 Jun 2013 05:47: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 z7yIZ1NpuMp4 for ; Mon, 3 Jun 2013 05:46:54 -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 9B04621F85F7 for ; Mon, 3 Jun 2013 05:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=789; q=dns/txt; s=iport; t=1370263614; x=1371473214; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N5tN8SuDs6MVW98OTTAZBIDgrN6IsZKBu9c+TRcQtn4=; b=T+q6y2pVxxGJa9iZgzdlwp2f5xv8ne4qmQZrIORCMhR4jI9jPnNHDIp0 2s7lHeiFIWxQLojY+6HrqR8kJgNjdDaiH76zGNLpVlca29Dly/dP7o/Pa rwTd9z0A/4UDuEgZqTgG1Tlkglkg5uReC8IS45KD0tnUAT3QRkM0xEaId g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAL6PrFGtJXHA/2dsb2JhbABZgwmDJbwOgQAWdIIjAQEBBDo/DAQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIiAW7DI52MQcGgnFhA6h+gw+CJw X-IronPort-AV: E=Sophos;i="4.87,792,1363132800"; d="scan'208";a="218034988" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jun 2013 12:46:54 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53Ckr5p030274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 12:46:53 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.172]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 07:46:53 -0500 From: "Gunter Van de Velde (gvandeve)" To: Gert Doering , Ted Lemon Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDEFTYeH7/3pEm2/YK3ImKhPZkdtEiAgADjeICAAdoBgIAABWYAgAAGnwCAAIjRgIAAEkOAgALdUnA= Date: Mon, 3 Jun 2013 12:46:53 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> In-Reply-To: <20130601115951.GD2504@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.201.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:47:00 -0000 Inline: GV> -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of G= ert Doering Sent: 01 June 2013 14:00 To: Ted Lemon Cc: v6ops@ietf.org WG; draft-ietf-v6ops-ula-usage-recommendations@tools.iet= f.org Subject: Re: [v6ops] A good example of why we need to careful about ULAs Hi, On Sat, Jun 01, 2013 at 10:54:29AM +0000, Ted Lemon wrote: > So you're arguing that every router on the internet needs a global IP add= ress? I would second that argument. GV> I think that the key is that they "SHOULD" have an IP address, not that= they "MUST" or "NEED TO" have an IP address. In some situatiations a networks works perfectly fine without a global IP a= ddress, however it may not be the best thing todo imho. G/ From lorenzo@google.com Mon Jun 3 05:52:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6351A21F96EA for ; Mon, 3 Jun 2013 05:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.067, 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 vU1E5lFGnUs2 for ; Mon, 3 Jun 2013 05:52:38 -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 81F5421F947C for ; Mon, 3 Jun 2013 05:52:25 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bn16so1791044qab.0 for ; Mon, 03 Jun 2013 05:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bEsyFaI/n42AFa7jrcIqzBSJ5Hm836rY694JPoYcUus=; b=DR1qcUTaI+pDs6yiSJuSH0PENRG9Oo9lPsYwSoFav5bCMQne4dx4TawtNxoJ4U7Mub eG0mlc8+T7orF4lbNehHRyIvOFdJ+O2D26mTGAeaNsmOfgs5dKGdwzlhQditLgB+S4Hq 984oFapq3bYOY/+XF666ihg9g9B8GXIHPxSOzuli6F0trebGe+V+1dmCHwFvQsfvWrG+ BVoihxR6CjstI14mUOOvGubk6IR2aCiL/MA69lOeeEmQXXa6kydtLZa5OUzh0rSLAbo0 Zo2v/UzF2jGbb9Sr0zcxAaNdx+lT3JVkBzUCkaEGZNB/bztInJidkOy+e73s0pzvQDGE 7BSg== 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=bEsyFaI/n42AFa7jrcIqzBSJ5Hm836rY694JPoYcUus=; b=X4shjD2439031OfyilR1JIy2Uz/DRWXNyvFvO8cRwq4pzOeG10ApOmZjvZAvFWySRN HS9Ae+oxBRz5XahPU2bZQqhG4ZslTali8IKSCaOYsVEkUtKUXUcp9dhOVEdh0t2m1NvH T5AUBqadJzDYxQMBs2FK+hAPPcWJPDCeQH/BAlxpnzjDq5CasiofH8qO54Hi2jDof1Ra gwLA3iETlu6xzCgsOk50wsKKZTHM8MnOnlt4T1A/OGGr24Yvy7aL7BIil4xTgQXHo9xI k0Qna2w9JHIiGcE2CvsNfCygff3VifcRmoXE8ZQsLuzwqgicEPSNfMBKdNC/u8BwscGc XhAg== X-Received: by 10.229.25.5 with SMTP id x5mr7530155qcb.35.1370263942990; Mon, 03 Jun 2013 05:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Mon, 3 Jun 2013 05:52:01 -0700 (PDT) In-Reply-To: <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> From: Lorenzo Colitti Date: Mon, 3 Jun 2013 21:52:01 +0900 Message-ID: To: "Gunter Van de Velde (gvandeve)" Content-Type: multipart/alternative; boundary=14dae9d711069244e404de3f6f2b X-Gm-Message-State: ALoCoQkbIHNp4KLUUfeeti+NpIdrFNYofyEz4dd5uQx2ENDS1CBtR9xaQRergv3TnmUe8LaaV6GliVFYIhgjwBGXXMnprRtuUwAkzfiUWfbrsPcXhgwR7Jyv8CYePIES+3zzaqP3qK5KpS0pPFiHnA0EK9ovEMqOaxJQcWTgIH1DgTPKgGsJ/bpN9qzmxKKOWgqV5GROuymD Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:52:39 -0000 --14dae9d711069244e404de3f6f2b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 9:46 PM, Gunter Van de Velde (gvandeve) < gvandeve@cisco.com> wrote: > > So you're arguing that every router on the internet needs a global IP > address? > > I would second that argument. > > GV> I think that the key is that they "SHOULD" have an IP address, not > that they "MUST" or "NEED TO" have an IP address. > In some situatiations a networks works perfectly fine without a global IP > address, however it may not be the best thing todo imho. > A router which forwards packets to and from destinations on the global internet MUST have a global IPv6 address, because otherwise it cannot support mandatory parts of the IPv6 specifications like PMTUd and ICMP errors. --14dae9d711069244e404de3f6f2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 9:46 PM, Gunter Van de Velde (gvand= eve) <gvandeve@cisco.com> wrote:
> So you're arguing= that every router on the internet needs a global IP address?

I would second that argument.

GV> I think that the key is that they "SHOULD" have an I= P address, not that they "MUST" or "NEED TO" have an IP= address.
In some situatiations a networks works perfectly fine without a global IP a= ddress, however it may not be the best thing todo imho.

A router which forwards packets to and from destinat= ions on the global internet MUST have a global IPv6 address, because otherw= ise it cannot support mandatory parts of the IPv6 specifications like PMTUd= and ICMP errors.
--14dae9d711069244e404de3f6f2b-- From gvandeve@cisco.com Mon Jun 3 05:58:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026F821F9698 for ; Mon, 3 Jun 2013 05:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqvkIa-Ednoj for ; Mon, 3 Jun 2013 05:58:09 -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 45F3E21F965A for ; Mon, 3 Jun 2013 05:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5123; q=dns/txt; s=iport; t=1370264289; x=1371473889; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5REIygPrWiRwYzAwQzx66tUu0mC7I718JMFjHohPTf8=; b=DG+qwseNksE4+hZBZNNQJvSe+DID9r45JjKa0ZbFDwfUlcNItgx41PUs SJGZVEx+3m2dgvHePUiULaDXU7keSH56TFBLvlzlDHN07UCdRtEDQ3MKM IdkVtsyKhtwXzscTGGh8OvvYJDKhfg06kYdavcBUqh1sECw/vrii4h86u Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAIeRrFGtJV2b/2dsb2JhbABZgkVEML8DgQAWdIIjAQEBAwEtTAULAgEIGAodBzIUEQIEDgUIE4dsBrsxjnYxB4J3YQOofoMPgic X-IronPort-AV: E=Sophos;i="4.87,792,1363132800"; d="scan'208,217";a="218131981" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jun 2013 12:58:08 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r53Cw710009523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 12:58:07 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.172]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 07:58:08 -0500 From: "Gunter Van de Velde (gvandeve)" To: Lorenzo Colitti Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDEFTYeH7/3pEm2/YK3ImKhPZkdtEiAgADjeICAAdoBgIAABWYAgAAGnwCAAIjRgIAAEkOAgALdUnCAAFXrgP//rJAA Date: Mon, 3 Jun 2013 12:58:07 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240CEBFA9C@xmb-aln-x12.cisco.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.201.115] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240CEBFA9Cxmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:58:15 -0000 --_000_67832B1175062E48926BF3CB27C49B240CEBFA9Cxmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, Jun 3, 2013 at 9:46 PM, Gunter Van de Velde (gvandeve) > wrote: > So you're arguing that every router on the internet needs a global IP add= ress? I would second that argument. GV> I think that the key is that they "SHOULD" have an IP address, not that= they "MUST" or "NEED TO" have an IP address. In some situatiations a networks works perfectly fine without a global IP a= ddress, however it may not be the best thing todo imho. A router which forwards packets to and from destinations on the global inte= rnet MUST have a global IPv6 address, because otherwise it cannot support m= andatory parts of the IPv6 specifications like PMTUd and ICMP errors. GV> I was thinking about MPLS clouds? (those may have non-BGP speaking rout= ers in there)... PMTUd and ICMP could be captured at the edge of those clou= ds with cludge solutions. I am sure there are other places also... G/ --_000_67832B1175062E48926BF3CB27C49B240CEBFA9Cxmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On Mon, Jun 3, 2013 at 9:46 PM, Gunter Van de Velde = (gvandeve) <gvan= deve@cisco.com> wrote:

> So you're arguin= g that every router on the internet needs a global IP address?

I would second that argument.

GV> I think that the key is that they "SHOUL= D" have an IP address, not that they "MUST" or "NEED TO= " have an IP address.
In some situatiations a networks works perfectly fine without a global IP a= ddress, however it may not be the best thing todo imho.

 

A router which forwards packets to and from destinat= ions on the global internet MUST have a global IPv6 address, because otherw= ise it cannot support mandatory parts of the IPv6 specifications like PMTUd= and ICMP errors.

 <= /p>

GV> I was thinking abo= ut MPLS clouds? (those may have non-BGP speaking routers in there)… P= MTUd and ICMP could be captured at the edge of those clouds with cludge solutions. I am sure there are other places also…<= /span>

 <= /p>

G/

--_000_67832B1175062E48926BF3CB27C49B240CEBFA9Cxmbalnx12ciscoc_-- From Carl.Wuyts@technicolor.com Mon Jun 3 06:01:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEE121F9698 for ; Mon, 3 Jun 2013 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9Bn0EkrMHP4 for ; Mon, 3 Jun 2013 06:01:03 -0700 (PDT) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id 61FDC21F86DC for ; Mon, 3 Jun 2013 06:00:42 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKUayTeuD4YgX+jcL51uBgS4BJvY+rNiM1@postini.com; Mon, 03 Jun 2013 06:01:03 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 3 Jun 2013 14:57:01 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.119]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 3 Jun 2013 14:57:02 +0200 From: Wuyts Carl To: "Gunter Van de Velde (gvandeve)" , Gert Doering , Ted Lemon Date: Mon, 3 Jun 2013 14:56:59 +0200 Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDEFTYeH7/3pEm2/YK3ImKhPZkdtEiAgADjeICAAdoBgIAABWYAgAAGnwCAAIjRgIAAEkOAgALdUnCAAAKtUA== Message-ID: <3135C2851EB6764BACEF35D8B495596806E79850B0@MOPESMBX01.eu.thmulti.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:01:08 -0000 +1 for GV's comment, i.e., in CPE-land, a PPP-based WAN interface is being = used regularly without GUA, so "SHOULD" seems to be sufficient. However, in this case, it'll use its GUA from his LAN interface to e.g. sou= rce packets, so it depends a little on what you mean that the box MUST have= a GUA. regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of G= unter Van de Velde (gvandeve) Sent: maandag 3 juni 2013 14:47 To: Gert Doering; Ted Lemon Cc: v6ops@ietf.org WG; draft-ietf-v6ops-ula-usage-recommendations@tools.iet= f.org Subject: Re: [v6ops] A good example of why we need to careful about ULAs Inline: GV> -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of G= ert Doering Sent: 01 June 2013 14:00 To: Ted Lemon Cc: v6ops@ietf.org WG; draft-ietf-v6ops-ula-usage-recommendations@tools.iet= f.org Subject: Re: [v6ops] A good example of why we need to careful about ULAs Hi, On Sat, Jun 01, 2013 at 10:54:29AM +0000, Ted Lemon wrote: > So you're arguing that every router on the internet needs a global IP add= ress? I would second that argument. GV> I think that the key is that they "SHOULD" have an IP address, not that= they "MUST" or "NEED TO" have an IP address. In some situatiations a networks works perfectly fine without a global IP a= ddress, however it may not be the best thing todo imho. G/ _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fgont@si6networks.com Mon Jun 3 06:44:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE3D21F9811 for ; Mon, 3 Jun 2013 06:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 m9ZWbVQYQjzs for ; Mon, 3 Jun 2013 06:44: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 D1CC921F9931 for ; Mon, 3 Jun 2013 06:44:23 -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 1UjV3b-0001qk-Sa; Mon, 03 Jun 2013 15:44:19 +0200 Message-ID: <51AC9DB0.70201@si6networks.com> Date: Mon, 03 Jun 2013 15:44:16 +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: Dan Wing References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:44:24 -0000 On 06/01/2013 02:48 AM, Dan Wing wrote: > draft-elkins-v6ops-ipv6-packet-sequence-needed. Both the documents > talk about how IPID is useful on IPv4 (if the sender is monotonically > increasing the IPID, which is a necessity for the existing system to > operate) This is not correct. The IP ID is not required to be monotonically increasing -- it just need to not be reused to quickly. A simple (and poor implementation) could have an array of 65536 integers in the range 0-65535 (without repeating any value), and then the stack would select the IP ID as: array[fragment] -- where "fragment" is the number of fragments that have been sent so far. As a datapoint, look at OpenBSD's IP ID generation. > and how routers sometimes send a packet twice (which is > normal behavior of Ethernet) and that the monotonically increasing > IPID helps distinguish Ethernet re-transmissions from host stack > retransmissions. Given the length of the IPv4 IP ID, badwidths available today, etc., I don't think you can/should use the IP ID for much. 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 Mon Jun 3 06:48:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484AC21F96FB for ; Mon, 3 Jun 2013 06:48:04 -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 CF+XYyJ9K9z3 for ; Mon, 3 Jun 2013 06:48:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B4E2E21F964C for ; Mon, 3 Jun 2013 06:48:03 -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 1UjV78-0001xY-RH; Mon, 03 Jun 2013 15:47:58 +0200 Message-ID: <51AC9E8D.9060609@si6networks.com> Date: Mon, 03 Jun 2013 15:47: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: Nalini Elkins References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:48:04 -0000 On 06/01/2013 05:35 PM, Nalini Elkins wrote: > 2. Forcing of IPv6 fragmentation header. We did discuss this in > section 3: > http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11 > > It is as follows: > > "The current IPv6 specification does not provide a packet sequence > number or similar field in the IPv6 main header. One option might be > to force all IPv6 packets to contain a Fragment Header. In packets > which are entire in and of themselves, the fragment ID would be zero > - that is, an atomic fragment. This is incorrect. Please reference any RFC section which requires a special Identification value (i.e., zero) for atomic fragments (hint: there's no such a recommendation). > The second reason for not having a fragment header is that > unfortunately, a number of firewalls, etc, drop packets which contain > IPv6 fragment headers. I find this to be unsuitable behavior which I > hope will change . But, it is the reality. Firewalls will usually block all extension headers. My advice in this area would be "think twice before specifying an IPv6 extension header. Then don't". :-) Cheers, -- 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 nalini.elkins@insidethestack.com Mon Jun 3 06:50:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0D21F8C1A for ; Mon, 3 Jun 2013 06:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 r3aNvm+kaQaZ for ; Mon, 3 Jun 2013 06:50:23 -0700 (PDT) Received: from nm21.access.bullet.mail.sp2.yahoo.com (nm21.access.bullet.mail.sp2.yahoo.com [98.139.44.148]) by ietfa.amsl.com (Postfix) with ESMTP id 6433921F88FB for ; Mon, 3 Jun 2013 06:50:23 -0700 (PDT) Received: from [98.139.44.101] by nm21.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 13:50:23 -0000 Received: from [98.139.44.83] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 13:50:23 -0000 Received: from [127.0.0.1] by omp1020.access.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 13:50:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 296161.34461.bm@omp1020.access.mail.sp2.yahoo.com Received: (qmail 54317 invoked by uid 60001); 3 Jun 2013 13:50:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370267422; bh=Q31gtlgMuIbvqFrTTiFBDJRGxqRmiX9pP7YxrUe+aGg=; 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=PWWrRcKaPez3HELs26QR8+/q26AB1j9HHYJx80TOb64vuo1dKBqmSa8DoXVrf45hZXAlpgkQs1UtQV84yUAIOiwGlAlRjWP4qoJaE7V4GNkUDTtQPCzvu283rTaLi1Un2e1oOxneJI9UhHhr+iJZXgvyyw9/t4SMI8AwGN+hsTw= X-YMail-OSG: rtSj72EVM1lr4.CDduRcV0Gx2Epq8fOxsSqC94jXPcF7pdf GlDCif0cXYCDtCKS1QAhYr.bxRjPmBSbYO2RzCtDtV2qpxB92iTPzlCO6zgl WF50H2hO08k2CMZfawgiGuArtQQVedXi.ieRJBIwUpYyb1wLSZV3QgRy4pif 9FfsuwiXov7IG8d68QYf7dzmukAUFNn.4oQqecRgihjizx81Kk1fBUqH_NGC Z7tMTCYXaDx0o2nikz3eBZT4yXVu3JNPQ0_gna6xXmuWz1isNEIY29mS4D4w LOhVg7TawTLXG3ctuHKWhD_EBr3_5SZrF64ENDR8Zi12x2n1FLyk.iWNaNvl pRHzL8_DhO.CXFuAXb1G6Sl9uqrtY9UgqPMFAHlICANYAJiSgvWHilMtX5Gn iqRdf_SpKZTChV73P.401YhQ2poN4N7AfzCMZo_AYdHn4b1_EBGDj267MpPb Bdwgd4ZRSfw7fziYHCNomF_EAWxNiqebp4pE48oFuCGChM9N3IMr4.N8vh5N jGzX0st..YEhZtRfGq9Wi4T1xrmB0F9q5ImGcKn7uCYasubDRWEw3kjWEDEG twWnO4D6uevKfPkEbut2OUYl8t7YV6QprWwBxBCh7tF4mtd2EhvMWHyZA416 EvUSVuHPatumecOEmIzHrfzaK98M- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 06:50:22 PDT X-Rocket-MIMEInfo: 002.001, Pj5HaXZlbiB0aGUgbGVuZ3RoIG9mIHRoZSBJUHY0IElQIElELCBiYWR3aWR0aHMgYXZhaWxhYmxlIHRvZGF5LCBldGMuLCBJCj4.wqBkb24ndCB0aGluayB5b3UgY2FuL3Nob3VsZCB1c2UgdGhlIElQIElEIGZvciBtdWNoLgoKV2hlbiBkaWFnbm9zaW5nIHByb2JsZW1zIGF0IGVuZCBsb2NhdGlvbnMsIG9mdGVuLCB5b3UgZmluYWxseSBnZXQgZG93biB0byBhIHNlcmllcyBvZiBwYWNrZXRzIHdoaWNoIGlzIHRoZSBwcm9ibGVtLiDCoCBUaGlzIG1heSBiZSAxMCBvciAyMCBwYWNrZXRzLiDCoAoKSXQgZG9lc24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> Message-ID: <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 06:50:22 -0700 (PDT) From: Nalini Elkins To: Fernando Gont , Dan Wing In-Reply-To: <51AC9DB0.70201@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-138745176-1370267422=:47637" Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:50:29 -0000 ---1551098171-138745176-1370267422=:47637 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>Given the length of the IPv4 IP ID, badwidths available today, etc., I=0A= >>=A0don't think you can/should use the IP ID for much.=0A=0AWhen diagnosin= g problems at end locations, often, you finally get down to a series of pac= kets which is the problem. =A0 This may be 10 or 20 packets. =A0=0A=0AIt do= esn't matter what the bandwidth is, it does matter whether you can say exac= tly what happened in those 10 or 20 packets. =A0=A0=0A=0AThe case studies w= e have are from actual operators who actually use this field. =A0AND find i= t saves a great deal of time because it works.=0A=A0=0AThanks,=0A=0A=0ANali= ni Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com= =0A=0A=0A=0A________________________________=0A From: Fernando Gont =0ATo: Dan Wing =0ACc: v6ops@ietf.org; dr= aft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org =0ASent: Monday, = June 3, 2013 6:44 AM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-i= pv6-end-to-end-rt-needed=0A =0A=0AOn 06/01/2013 02:48 AM, Dan Wing wrote:= =0A> draft-elkins-v6ops-ipv6-packet-sequence-needed.=A0 Both the documents= =0A> talk about how IPID is useful on IPv4 (if the sender is monotonically= =0A> increasing the IPID, which is a necessity for the existing system to= =0A> operate)=0A=0AThis is not correct. The IP ID is not required to be mon= otonically=0Aincreasing -- it just need to not be reused to quickly.=0A=0AA= simple (and poor implementation) could have an array of 65536 integers=0Ai= n the range 0-65535 (without repeating any value), and then the stack=0Awou= ld select the IP ID as:=0A=0Aarray[fragment]=0A=0A--=A0 where "fragment" is= the number of fragments that have been sent so far.=0A=0A=0A=0AAs a datapo= int, look at OpenBSD's IP ID generation.=0A=0A=0A> and how routers sometime= s send a packet twice (which is=0A> normal behavior of Ethernet) and that t= he monotonically increasing=0A> IPID helps distinguish Ethernet re-transmis= sions from host stack=0A> retransmissions.=0A=0AGiven the length of the IPv= 4 IP ID, badwidths available today, etc., I=0Adon't think you can/should us= e the IP ID for much.=0A=0ACheers,=0A-- =0AFernando Gont=0ASI6 Networks=0Ae= -mail: fgont@si6networks.com=0APGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3= C4 AE25 0D55 1D4E 7492=0A=0A=0A=0A=0A______________________________________= _________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/v6ops ---1551098171-138745176-1370267422=:47637 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>>Given the length of the IPv4 IP ID, badwidths= available today, etc., I
>&g= t; 

When diagnosing problems at end locations, often, you finally get down= to a series of packets which is the problem.   This may be 10 or 20 p= ackets.  

It doesn'= t matter what the bandwidth is, it does matter whether you can say exactly = what happened in those 10 or 20 packets.   

The case studies we have are from actua= l operators who actually use this field.  AND find it saves a great de= al of time because it works.
 
Thanks,<= br>
Nalini Elkins
Inside Products, Inc.
(831) 659-8360<= br>www.insidethestack.com

From: Fernando Gont <fgont@si6networks.com>
= To: Dan Wing <dwing@cisco.= com>
Cc: v6ops@ietf.org; d= raft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org
Sent: Monday, June 3, 2013 6:44 AM Subject: Re: [v6ops] new= draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0AOn 06/01/2013 02:48 AM, Dan Wing wrote:<= br>> draft-elkins-v6ops-ipv6-packet-sequence-needed.  Both the docu= ments
> talk about how IPID is useful on IPv4 (if the sender is monot= onically
> increasing the IPID, which is a necessity for the existing= system to
> operate)

This is not correct. The IP ID is not re= quired to be monotonically
increasing -- it just need to not be reused t= o quickly.

A simple (and poor implementation) could have an array of= 65536 integers
in the range 0-65535 (without repeating any value), and = then the stack
would select the IP ID as:

array[fragment]

= --  where "fragment" is the number of fragments that have been sent s= o far.



As a datapoint, look at OpenBSD's IP ID generation.

> and how routers sometimes send a packet twice (which is
&= gt; normal behavior of Ethernet) and that the monotonically increasing
&= gt; IPID helps distinguish Ethernet re-transmissions from host stack
> retransmissions.

= Given the length of the IPv4 IP ID, badwidths available today, etc., I
d= on't think you can/should use the IP ID for much.

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



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

---1551098171-138745176-1370267422=:47637-- From owen@delong.com Mon Jun 3 06:53:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA5D21F8C1A for ; Mon, 3 Jun 2013 06:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkViCmrqq0Sg for ; Mon, 3 Jun 2013 06:53:41 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3121F8B3D for ; Mon, 3 Jun 2013 06:53:41 -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 r53Dqcpk008927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 06:52:39 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53Dqcpk008927 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370267560; bh=GU0Ey8G9tf9TSddxRKktMZ+BEZk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uSdxYK0ejCPJOdN6yTrvLdyQjN5jKGDIYy5Dly9nWapFZCOxE9iE0RxHDseBlkMyj V2k28kqdBOR4bl5F1Gyt+1lcSwVn0v1IWlanCzbMNP3yikuTRDonyaFe6X8LQ99Gg1 Di67wzyDXWvDuF//MfQVv7Wh8UaJd0ZXbdrc+sFc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> Date: Mon, 3 Jun 2013 08:52:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> To: "Gunter Van de Velde (gvandeve)" 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:52:40 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:53:42 -0000 On Jun 3, 2013, at 7:46 AM, "Gunter Van de Velde (gvandeve)" = wrote: > Inline: GV> >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Gert Doering > Sent: 01 June 2013 14:00 > To: Ted Lemon > Cc: v6ops@ietf.org WG; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org > Subject: Re: [v6ops] A good example of why we need to careful about = ULAs >=20 > Hi, >=20 > On Sat, Jun 01, 2013 at 10:54:29AM +0000, Ted Lemon wrote: >> So you're arguing that every router on the internet needs a global IP = address? >=20 > I would second that argument. >=20 > GV> I think that the key is that they "SHOULD" have an IP address, not = that they "MUST" or "NEED TO" have an IP address. > In some situatiations a networks works perfectly fine without a global = IP address, however it may not be the best thing todo imho. Depends on how you define "works perfectly fine". I would argue that a router which emits ULAs or Link Locals in ICMP time = exceeded messages which are forwarded outside of the appropriate scope = (LL) or administrative boundary(yes) (ULA) is not "working perfectly = fine". Thus, any router which may emit a time exceeded packet (any router on = the internet) to an external destination will need the ability to do so = with a GUA. In order to do that, said router does, in fact, need a GUA. = IMHO, this is a must, not a should or a may. Owen From owen@delong.com Mon Jun 3 06:54:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 owen@delong.com Mon Jun 3 06:58:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA71121F96FB for ; Mon, 3 Jun 2013 06:58:40 -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 wEckKDC4ZSIv for ; Mon, 3 Jun 2013 06:58:40 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DFEDE21F96ED for ; Mon, 3 Jun 2013 06:58:39 -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 r53DuC9c009092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 06:56:13 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53DuC9c009092 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370267774; bh=3dbGs+aYAoT8gA7LouzQXq/KFM8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=HoHzSxjbTqsTKBrh0DdZoGHDY3Fz2zT01hx8IQA3yEW1h7Nu5R8vbGLpkEdTnpnt4 o9nYJbZzxWhkw9uDBRTPz4xOpJNQ3thxB9jziwot6j/pijilA3FwvpTm1LmMPoebkx /jVq+F7H1OelUfoInU/zm1sBggkwZjCIPi2kyL6k= Content-Type: multipart/alternative; boundary="Apple-Mail=_00036E7B-EBC5-451A-BB4B-E2577AC096F1" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <67832B1175062E48926BF3CB27C49B240CEBFA9C@xmb-aln-x12.cisco.com> Date: Mon, 3 Jun 2013 08:56:11 -0500 Message-Id: <4743D1E6-EA54-42E7-9AE1-A8FFD94D7ED0@delong.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B240CEBFA9C@xmb-aln-x12.cisco.com> To: "Gunter Van de Velde (gvandeve)" 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:56:14 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:58:41 -0000 --Apple-Mail=_00036E7B-EBC5-451A-BB4B-E2577AC096F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 3, 2013, at 7:58 AM, "Gunter Van de Velde (gvandeve)" = wrote: > On Mon, Jun 3, 2013 at 9:46 PM, Gunter Van de Velde (gvandeve) = wrote: > > So you're arguing that every router on the internet needs a global = IP address? >=20 > I would second that argument. >=20 > GV> I think that the key is that they "SHOULD" have an IP address, not = that they "MUST" or "NEED TO" have an IP address. > In some situatiations a networks works perfectly fine without a global = IP address, however it may not be the best thing todo imho. > =20 > A router which forwards packets to and from destinations on the global = internet MUST have a global IPv6 address, because otherwise it cannot = support mandatory parts of the IPv6 specifications like PMTUd and ICMP = errors. > =20 > GV> I was thinking about MPLS clouds? (those may have non-BGP speaking = routers in there)=85 PMTUd and ICMP could be captured at the edge of = those clouds with cludge solutions. I am sure there are other places = also=85 Routers inside an MPLS cloud are not routers for purposes of the packets = traversing them inside MPLS tunnels. If the router has no interfaces which talk to the internet outside of = MPLS tunnels, then, it is not technically a "router on the internet". Owen --Apple-Mail=_00036E7B-EBC5-451A-BB4B-E2577AC096F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 3, 2013, = at 7:58 AM, "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> = wrote:


Ro= uters inside an MPLS cloud are not routers for purposes of the packets = traversing them inside MPLS tunnels.

If the = router has no interfaces which talk to the internet outside of MPLS = tunnels, then, it is not technically a "router on the = internet".

Owen

= --Apple-Mail=_00036E7B-EBC5-451A-BB4B-E2577AC096F1-- From nalini.elkins@insidethestack.com Mon Jun 3 06:59:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7DD21E804B for ; Mon, 3 Jun 2013 06:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 mAP0G9i1mqaw for ; Mon, 3 Jun 2013 06:59:26 -0700 (PDT) Received: from nm30-vm0.access.bullet.mail.mud.yahoo.com (nm30-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.86]) by ietfa.amsl.com (Postfix) with ESMTP id 4523621F96ED for ; Mon, 3 Jun 2013 06:59:26 -0700 (PDT) Received: from [66.94.237.200] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 13:59:23 -0000 Received: from [66.94.237.108] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 13:59:23 -0000 Received: from [127.0.0.1] by omp1013.access.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 13:59:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 201106.23784.bm@omp1013.access.mail.mud.yahoo.com Received: (qmail 59870 invoked by uid 60001); 3 Jun 2013 13:59:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370267962; bh=UTg2v1G+NxkzdNYTSUw4Dgr7hyb1YTAlbL8TJssTekY=; 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=VCkK2ez+da6H6G/t4jzXnZtPv4O9AVV11o3ksJvVWZJtmMYQv69EmXMrnIDXzadUqsRk8LGkXJOJ92FZC0nhQMIdY07dVxXii9GWxkxN5UWctCHpcuagQ2UnwZtLzJBIHTcipt01K9Em01h57UC89+NP2aZwHku9dFN12CKiCOY= X-YMail-OSG: JPddMkYVM1nK4.lZmYa1ibZOLCz.VVoe7PU8NS06P_86pgU pepBFSHmde8qryjhTgpbRaoOdtwClDCuY7z1_YUbUg6lywUjj1SrvT41WiLy ey5Ca_mvXlitsdxR6XChrhYScYLcBlJ7T_JzCFFInKQfd9KCSYa6.EgwL2YS A8KcrQUj06kD35EhI.HPuX8KkZ315iFXXZwea4kwGZoXojC38aW9WF8YacK9 FYdQ8QUeP9xquzJY6KRkYAl9klWtAfsV5FnuatVq417xMR1ERSMj8baqUfW5 zMTivCjnpUmGGh8n4hEdNCrx9ZJ_EWkVULlbo600Z2XJOgOFY9Fpsc_PBITQ wqlAYmDmYiLUV3EwZbVvQIPRiHz4ykfdSgdqA3hNH6nt.QU41dTMSWHuVqPk dWrFJbWU.5r9Nw8FmwW7kAgyUFIJU6bDS2czHSpAjxi1d6JtAHJldtzcXzro bW3P4lgKaOFSVZd7_sTZnhaxHcSkix6FOZBlLVONj7uvjcKh1la8RrPFhga4 T0iJWk6i1D5LBJoU6bMKt2kl6HTw.QNTnY1YalsuDqbmIQSu.SJNMjvG8QF8 yxjom20P80.fxvLikbklGvfDq3vvMF3eu.MMZskPATYr8W0GamtPvJKJZhLr ZMHyel8dH2TcyCLbeo.1yPRei6YI- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 06:59:22 PDT X-Rocket-MIMEInfo: 002.001, Pj4gRmlyZXdhbGxzIHdpbGwgdXN1YWxseSBibG9jayBhbGwgZXh0ZW5zaW9uIGhlYWRlcnMuIE15IGFkdmljZSBpbiB0aGlzCj4.IGFyZWEgd291bGQgYmUgInRoaW5rIHR3aWNlIGJlZm9yZSBzcGVjaWZ5aW5nIGFuIElQdjYgZXh0ZW5zaW9uIGhlYWRlci4KPj5UaGVuIGRvbid0Ii4gOi0pCgpJZiBmaXJld2FsbHMgYmxvY2sgYWxsIGV4dGVuc2lvbiBoZWFkZXJzLCB3aHkgd291bGQgdGltZSBoYXZlIGJlZW4gd2FzdGVkIGF0IHRoZSBJRVRGIGV2ZW4gc3BlY2lmeWluZyB0aGUgcHJvdG9jb2xzIGZvciBleHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> Message-ID: <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 06:59:22 -0700 (PDT) From: Nalini Elkins To: Fernando Gont In-Reply-To: <51AC9E8D.9060609@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-944853172-1370267962=:59169" Cc: "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:59:31 -0000 ---1551098171-944853172-1370267962=:59169 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> Firewalls will usually block all extension headers. My advice in this=0A= >> area would be "think twice before specifying an IPv6 extension header.= =0A>>Then don't". :-)=0A=0AIf firewalls block all extension headers, why wo= uld time have been wasted at the IETF even specifying the protocols for ext= ension headers? =A0Am I wrong that firewalls are configured by people and c= an be set to PASS extension headers rather than drop them?=0A=0AAlso, if th= e extension header provides value, I can guarantee you that people will set= their firewalls to pass it. =A0 We have thought "twice" and three times ab= out proposing this. =A0 The only reason we do is because it is important.= =0A=0AI have mentioned the possibility of =A0this new extension header to e= xecutives at two different companies and both felt that it provided great v= alue and might even be THE impetus they need to migrate to IPv6. =A0 Better= diagnostics AND end-to-end response time are very practical and real needs= for many companies. =A0 As you know, we were very disturbed that one facil= ity that we used frequently in IPv4, IPID, was not available to us in IPv6.= =A0 =A0=A0=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.= =0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_____________________= ___________=0A From: Fernando Gont =0ATo: Nalini Elk= ins =0ACc: Fred Baker (fred) ; Dan Wing (dwing) ; "v6ops@ietf.org" ; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" =0ASent: Monday, June 3= , 2013 6:47 AM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-en= d-to-end-rt-needed=0A =0A=0AOn 06/01/2013 05:35 PM, Nalini Elkins wrote:=0A= > 2.=A0 Forcing of IPv6 fragmentation header.=A0 We did discuss this in=0A>= section 3:=0A> http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-s= equence-needed-00#page-11=0A>=0A>=A0 It is as follows:=0A> =0A> "The curren= t IPv6 specification does not provide a packet sequence=0A> number or simil= ar field in the IPv6 main header.=A0 One option might be=0A> to force all I= Pv6 packets to contain a Fragment Header.=A0 In packets=0A> which are entir= e in and of themselves, the fragment ID would be zero=0A> - that is, an ato= mic fragment.=0A=0AThis is incorrect. Please reference any RFC section whic= h requires a=0Aspecial Identification value (i.e., zero) for atomic fragmen= ts (hint:=0Athere's no such a recommendation).=0A=0A=0A=0A> The second reas= on for not having a fragment header is that=0A> unfortunately, a number of = firewalls, etc, drop packets which contain=0A> IPv6 fragment headers.=A0 I = find this to be unsuitable behavior which I=0A> hope will change .=A0 But,= it is the reality.=0A=0AFirewalls will usually block all extension headers= . My advice in this=0Aarea would be "think twice before specifying an IPv6 = extension header.=0AThen don't". :-)=0A=0ACheers,=0A-- =0AFernando Gont=0AS= I6 Networks=0Ae-mail: fgont@si6networks.com=0APGP Fingerprint: 6666 31C6 D4= 84 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 ---1551098171-944853172-1370267962=:59169 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>> Firewalls will usually block all extension h= eaders. My advice in this
>> area would be "think twic= e before specifying an IPv6 extension header.
>>Then don't= ". :-)

If firewalls block all extension headers, w= hy would time have been wasted at the IETF even specifying the protocols fo= r extension headers?  Am I wrong that firewalls are configured by peop= le and can be set to PASS extension headers rather than drop them?
=
Also, if the extension header provides value, I can guarant= ee you that people will set their firewalls to pass it.   We have thou= ght "twice" and three times about proposing this.   The only reason we= do is because it is important.

= I have mentioned the possibility of  this new extension header to exec= utives at two different companies and both felt that it provided great valu= e and might even be THE impetus they need to migrate to IPv6.   Better= diagnostics AND end-to-end response time are very practical and real needs= for many companies.   As you know, we were very disturbed that one fa= cility that we used frequently in IPv4, IPID, was not available to us in IP= v6.     
 
Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360www.insidethestack.com

From: Fernando Gont <fgont@si6networks.com>
<= span style=3D"font-weight: bold;">To: Nalini Elkins <nalini.e= lkins@insidethestack.com>
Cc:<= /span> Fred Baker (fred) <fred@cisco.com>; Dan Wing (dwing) <d= wing@cisco.com>; "v6ops@ietf.org" <v6ops@ietf.org>; "draft-elkins-= v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" <draft-elkins-v6ops-ipv6= -end-to-end-rt-needed@tools.ietf.org>
Sent: Monday, June 3, 2013 6:47 AM
Subject: Re: [v6ops] new draft: draft-elkin= s-v6ops-ipv6-end-to-end-rt-needed

=0AOn 06/01/2013 05:35 PM, Nalini Elkins wrote:
> 2.&nbs= p; Forcing of IPv6 fragmentation header.  We did discuss this in
&g= t; section 3:
> http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-pa= cket-sequence-needed-00#page-11
>
>  It is as follows:
= >
> "The current IPv6 specification does not provide a packet seq= uence
> number or similar field in the IPv6 main header.  One op= tion might be
> to force all IPv6 packets to contain a Fragment Heade= r.  In packets
> which are entire in and of themselves, the frag= ment ID would be zero
> - that is, an atomic fragment.

This is= incorrect. Please reference any RFC section which requires a
special Id= entification value (i.e., zero) for atomic fragments (hint:
there's no s= uch a recommendation).



> The second reason for not having= a fragment header is that
> unfortunately, a number of firewalls, et= c, drop packets which contain
> IPv6 fragment headers.  I find this to = be unsuitable behavior which I
> hope will change .  But, it is= the reality.

Firewalls will usually block all extension headers. My= advice in this
area would be "think twice before specifying an IPv6 ext= ension header.
Then don't". :-)

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




<= br>
---1551098171-944853172-1370267962=:59169-- From gert@space.net Mon Jun 3 07:00:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9564121F942B for ; Mon, 3 Jun 2013 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6l8rX3KIeLAs for ; Mon, 3 Jun 2013 07:00: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 4C1E021F962D for ; Mon, 3 Jun 2013 07:00:37 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3BAF560A1B for ; Mon, 3 Jun 2013 16:00:36 +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 EF94860A09 for ; Mon, 3 Jun 2013 16:00:35 +0200 (CEST) Received: (qmail 65025 invoked by uid 1007); 3 Jun 2013 16:00:35 +0200 Date: Mon, 3 Jun 2013 16:00:35 +0200 From: Gert Doering To: Wuyts Carl Message-ID: <20130603140035.GJ2504@Space.Net> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> <3135C2851EB6764BACEF35D8B495596806E79850B0@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8A8vkjq8WxqbGzeT" Content-Disposition: inline In-Reply-To: <3135C2851EB6764BACEF35D8B495596806E79850B0@MOPESMBX01.eu.thmulti.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:00:39 -0000 --8A8vkjq8WxqbGzeT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jun 03, 2013 at 02:56:59PM +0200, Wuyts Carl wrote: > +1 for GV's comment, i.e., in CPE-land, a PPP-based WAN interface is bein= g used regularly without GUA, so "SHOULD" seems to be sufficient. > However, in this case, it'll use its GUA from his LAN interface to e.g. s= ource packets, so it depends a little on what you mean that the box MUST ha= ve a GUA. Nobody said "it must have a GUA on every single interface", so a box that is using unnumbered WAN and uses the LAN GUA for the purpose of sourcing packets is perfectly fine - and it has "*a* GUA address". "SHOULD" is giving people ideas. MUST is the right term. 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 --8A8vkjq8WxqbGzeT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUayhg6kuBuNlUUl1AQLFXgP7B14MQdM4YMEv15tX3Qfgb8Ewj/dBoiZJ gq8XwWQLD9D2N085m0Z06GFQ2qqTPNLO1lY9ZLrvxsM+yapsZbcy1i62xQ7VSmoq GDm6U2DlcERXSNuaQW8TtOzeZEzWtu78oxI99mcIoUmDponNQhnaOArVhpOrX9VE 1TeXHCg34Ck= =AmHq -----END PGP SIGNATURE----- --8A8vkjq8WxqbGzeT-- From Carl.Wuyts@technicolor.com Mon Jun 3 07:03:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77FE21E805F for ; Mon, 3 Jun 2013 07:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIvdRbvVdGL1 for ; Mon, 3 Jun 2013 07:03:23 -0700 (PDT) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id CD0FA21E8054 for ; Mon, 3 Jun 2013 07:03:14 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUayiG0iSKbgLj00uB/Auycr+ieh9+9Ol@postini.com; Mon, 03 Jun 2013 07:03:23 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 3 Jun 2013 16:01:46 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.119]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 3 Jun 2013 16:01:48 +0200 From: Wuyts Carl To: Gert Doering Date: Mon, 3 Jun 2013 16:01:45 +0200 Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: Ac5gYr3rn20FPEJMTjmbLbxslgD1rwAABvHA Message-ID: <3135C2851EB6764BACEF35D8B495596806E7985252@MOPESMBX01.eu.thmulti.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C01BD@mbx-01.win.nominum.com> <20130601115951.GD2504@Space.Net> <67832B1175062E48926BF3CB27C49B240CEBF9EA@xmb-aln-x12.cisco.com> <3135C2851EB6764BACEF35D8B495596806E79850B0@MOPESMBX01.eu.thmulti.com> <20130603140035.GJ2504@Space.Net> In-Reply-To: <20130603140035.GJ2504@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:03:30 -0000 OK, Ack regs Carl -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: maandag 3 juni 2013 16:01 To: Wuyts Carl Cc: Gunter Van de Velde (gvandeve); Gert Doering; Ted Lemon; v6ops@ietf.org= WG; draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A good example of why we need to careful about ULAs Hi, On Mon, Jun 03, 2013 at 02:56:59PM +0200, Wuyts Carl wrote: > +1 for GV's comment, i.e., in CPE-land, a PPP-based WAN interface is bein= g used regularly without GUA, so "SHOULD" seems to be sufficient. > However, in this case, it'll use its GUA from his LAN interface to e.g. s= ource packets, so it depends a little on what you mean that the box MUST ha= ve a GUA. Nobody said "it must have a GUA on every single interface", so a box that i= s using unnumbered WAN and uses the LAN GUA for the purpose of sourcing pac= kets is perfectly fine - and it has "*a* GUA address". "SHOULD" is giving people ideas. MUST is the right term. 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 cb.list6@gmail.com Mon Jun 3 07:05:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF721E8084 for ; Mon, 3 Jun 2013 07:05:09 -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, 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 TXe6zbw5dBJA for ; Mon, 3 Jun 2013 07:05:08 -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 8CFB121E8063 for ; Mon, 3 Jun 2013 07:05:07 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so3214318wgh.23 for ; Mon, 03 Jun 2013 07:04:58 -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=/36THQlU36X1o93q3ZQwL6f760axARowQZXzWPKufv8=; b=ECniQlqCbfsQOfWbunLl0cMq0f7zfQs9arV9PPEK0Lhdkt+chg3v/6OHd6P52uzEUB tvVqS6ACw2jFZhijm8KaVUlzHQmVrpejnj4Jk6L9zLDerlrCFRNcwqcuFVYWod83JidU BgHsQoiDwHb6TLQc6r9qoBc/Y7vqbnefNOFmOoe7XcR8M2jUVzO24VBTtww3CI0P89Of Mp8a2/2ENPNuTM9IfUcXUYGfpgQ4nhoqyAiLWSyXRmjYHAWRHo3I/4YV0xReOjr0nS+o agi4wqt62JoTuc5Bq+W+4/NxaFr44oN6+sscDDiyKJdkylGFhYpqkD5AJ8zXlzSXSQTw xm5g== MIME-Version: 1.0 X-Received: by 10.180.185.179 with SMTP id fd19mr12698823wic.1.1370268298004; Mon, 03 Jun 2013 07:04:58 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 3 Jun 2013 07:04:57 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 3 Jun 2013 07:04:57 -0700 (PDT) In-Reply-To: <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 07:04:57 -0700 Message-ID: From: "cb.list6" To: Nalini Elkins Content-Type: multipart/alternative; boundary=001a11c25e4c264e3304de4073ba Cc: Fernando Gont , IPv6 Ops WG , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:05:09 -0000 --001a11c25e4c264e3304de4073ba Content-Type: text/plain; charset=ISO-8859-1 On Jun 3, 2013 6:59 AM, "Nalini Elkins" wrote: > > >> Firewalls will usually block all extension headers. My advice in this > >> area would be "think twice before specifying an IPv6 extension header. > >>Then don't". :-) > > If firewalls block all extension headers, why would time have been wasted at the IETF even specifying the protocols for extension headers? Am I wrong that firewalls are configured by people and can be set to PASS extension headers rather than drop them? > Ipv6 came before ubiquitous firewalls The extension header fw knob may or may not exist for your firewall You will likey have better luck advancing your draft if you include a statement that your extention header may not work on the internet but can be engineerred to work within a single administrative domain CB > Also, if the extension header provides value, I can guarantee you that people will set their firewalls to pass it. We have thought "twice" and three times about proposing this. The only reason we do is because it is important. > > I have mentioned the possibility of this new extension header to executives at two different companies and both felt that it provided great value and might even be THE impetus they need to migrate to IPv6. Better diagnostics AND end-to-end response time are very practical and real needs for many companies. As you know, we were very disturbed that one facility that we used frequently in IPv4, IPID, was not available to us in IPv6. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ________________________________ > From: Fernando Gont > To: Nalini Elkins > Cc: Fred Baker (fred) ; Dan Wing (dwing) ; "v6ops@ietf.org" ; " draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" < draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org> > Sent: Monday, June 3, 2013 6:47 AM > > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed > > On 06/01/2013 05:35 PM, Nalini Elkins wrote: > > 2. Forcing of IPv6 fragmentation header. We did discuss this in > > section 3: > > http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11 > > > > It is as follows: > > > > "The current IPv6 specification does not provide a packet sequence > > number or similar field in the IPv6 main header. One option might be > > to force all IPv6 packets to contain a Fragment Header. In packets > > which are entire in and of themselves, the fragment ID would be zero > > - that is, an atomic fragment. > > This is incorrect. Please reference any RFC section which requires a > special Identification value (i.e., zero) for atomic fragments (hint: > there's no such a recommendation). > > > > > The second reason for not having a fragment header is that > > unfortunately, a number of firewalls, etc, drop packets which contain > > IPv6 fragment headers. I find this to be unsuitable behavior which I > > hope will change . But, it is the reality. > > Firewalls will usually block all extension headers. My advice in this > area would be "think twice before specifying an IPv6 extension header. > Then don't". :-) > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c25e4c264e3304de4073ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 3, 2013 6:59 AM, "Nalini Elkins" <nalini.elkins@insidethestack.com> wro= te:
>
> >> Firewalls will usually block all extension headers. My advice= in this
> >> area would be "think twice before specifying an IPv6 ext= ension header.
> >>Then don't". :-)
>
> If firewalls block all extension headers, why would time have been was= ted at the IETF even specifying the protocols for extension headers? =A0Am = I wrong that firewalls are configured by people and can be set to PASS exte= nsion headers rather than drop them?
>

Ipv6 came before ubiquitous firewalls

The extension header fw knob may or may not exist for your f= irewall

You will likey have better luck advancing your draft if you = include a statement that your extention header may not work on the internet= but can be engineerred to work within a single administrative domain

CB

> Also, if the extension header provides value, I can gua= rantee you that people will set their firewalls to pass it. =A0 We have tho= ught "twice" and three times about proposing this. =A0 The only r= eason we do is because it is important.
>
> I have mentioned the possibility of =A0this new extension header to ex= ecutives at two different companies and both felt that it provided great va= lue and might even be THE impetus they need to migrate to IPv6. =A0 Better = diagnostics AND end-to-end response time are very practical and real needs = for many companies. =A0 As you know, we were very disturbed that one facili= ty that we used frequently in IPv4, IPID, was not available to us in IPv6. = =A0 =A0=A0
> =A0
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com >
> ________________________________
> From: Fernando Gont <fgont= @si6networks.com>
> To: Nalini Elkins <nalini.elkins@insidethestack.com>
> Cc: Fred Baker (fred) <fred@cisco= .com>; Dan Wing (dwing) <dwing= @cisco.com>; "v6ops@ietf.org<= /a>" <v6ops@ietf.org>; &qu= ot;draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org"= ; <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org&g= t;
> Sent: Monday, June 3, 2013 6:47 AM
>
> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-= needed
>
> On 06/01/2013 05:35 PM, Nalini Elkins wrote:
> > 2.=A0 Forcing of IPv6 fragmentation header.=A0 We did discuss thi= s in
> > section 3:
> > http://tools.ietf.org/html/draft-elkins-v6o= ps-ipv6-packet-sequence-needed-00#page-11
> >
> >=A0 It is as follows:
> >
> > "The current IPv6 specification does not provide a packet se= quence
> > number or similar field in the IPv6 main header.=A0 One option mi= ght be
> > to force all IPv6 packets to contain a Fragment Header.=A0 In pac= kets
> > which are entire in and of themselves, the fragment ID would be z= ero
> > - that is, an atomic fragment.
>
> This is incorrect. Please reference any RFC section which requires a > special Identification value (i.e., zero) for atomic fragments (hint:<= br> > there's no such a recommendation).
>
>
>
> > The second reason for not having a fragment header is that
> > unfortunately, a number of firewalls, etc, drop packets which con= tain
> > IPv6 fragment headers.=A0 I find this to be unsuitable behavior w= hich I
> > hope will change .=A0 But, it is the reality.
>
> Firewalls will usually block all extension headers. My advice in this<= br> > area would be "think twice before specifying an IPv6 extension he= ader.
> Then don't". :-)
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com=
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a11c25e4c264e3304de4073ba-- From jmh@joelhalpern.com Mon Jun 3 07:07:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 nalini.elkins@insidethestack.com Mon Jun 3 07:11:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D921F9811 for ; Mon, 3 Jun 2013 07:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 EnpHOae4GzlN for ; Mon, 3 Jun 2013 07:11:42 -0700 (PDT) Received: from nm4-vm0.access.bullet.mail.sp2.yahoo.com (nm4-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3024721F9989 for ; Mon, 3 Jun 2013 07:11:42 -0700 (PDT) Received: from [98.139.44.107] by nm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 14:11:41 -0000 Received: from [98.139.44.64] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 14:11:41 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 14:11:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 754654.14297.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 3157 invoked by uid 60001); 3 Jun 2013 14:11:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370268701; bh=R0gFF82aHvGmYLzVkp1JnTD/PtRLleUUyufE5cHc0l8=; 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=PTOnDwakSdgEI18/vPjF/wjniasYrN77riqFffk03B4CNt2oE3bPc7S0MXnzqe9FkEMh+GO3zh6beoWxWqu8YwbtsjVOOJLqXG6Ii8iOHw/7iw48OQhDs+XGD3WtZKUdtojPHM4kueXThbaMlWRCQHIiYCDQBYh0MKRe5ruPD/c= X-YMail-OSG: k8AoPowVM1nOaE_5zUkMgQEVxTA_gDN5YgmZT807Xqe0sKM 5d6TNcBkLwiPYctWnxz6DkfaZCl4KDNG8opxQwU0tUW2dAvYt6oOvVn.jJOK aW0ngHGWLLJxAXSmqI3gEIDB58pZP_IXyWL88LdBLbV7agJ_sbT259ZJyPV0 h0asMrenbmVGbwcatIueF0U4cZmeO1H5oyC_EwDoqNw2ecG2MnF.Is4cpQBi VDDsN9_mSqnrRk4iGicETcbpbSTgpWGFE4BxcZ6jSZIxbSUig5YZNDsrc2yd RbKkyeI1_hV1HZ.yK0nS1dJVZ5v96ie9vwVxK0Sxx48q__b_M2ZA1knpPBSn Dh8VZawi8TCkimfeNrsS2TVvaoVrEEQ2ydsyvpeoycRvvmEc4XfmwF0ampU5 1llwyzsDaya15oDItAzE49mbarVaGzRx74SbiF.CIq30s7G4XXGY2p4PEpTg zqfYcvtjx8XO7FehhiB81GYACHS3NWotM.l7uTmQq.Qo6IpARqE81_aEjCqm rDfDyUVKTb9WuWeqroQ2iGGPjrP8YiWdkHf2G_loVjupa8FuA0oBKQm1J3vW 8GGO76YwR4jQhmwqG7jVIp2UpHRJz9OXU3NaiV6puqBtnACKz.VeeX.Xirdn S7.YlRN_KP0oNj1QmcQQ0DeBz5nhz Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 07:11:41 PDT X-Rocket-MIMEInfo: 002.001, Pj4gWW91IHdpbGwgbGlrZXkgaGF2ZSBiZXR0ZXIgbHVjayBhZHZhbmNpbmcgeW91ciBkcmFmdCBpZiB5b3UgaW5jbHVkZSBhIHN0YXRlbWVudCB0aGF0IHlvdXIgZXh0ZW50aW9uIGhlYWRlciBtYXkgbm90IHdvcmsgb24gdGhlIGludGVybmV0IGJ1dCBjYW4gYmUgZW5naW5lZXJyZWQgdG8gd29yayB3aXRoaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluCgoKR29vZCBzdWdnZXN0aW9uLgrCoApUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjABMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Message-ID: <1370268701.3081.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 07:11:41 -0700 (PDT) From: Nalini Elkins To: "cb.list6" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-418500733-1370268701=:3081" Cc: Fernando Gont , IPv6 Ops WG , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:11:47 -0000 --36908767-418500733-1370268701=:3081 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> You will likey have better luck advancing your draft if you include a st= atement that your extention header may not work on the internet but can be = engineerred to work within a single administrative domain=0A=0A=0AGood sugg= estion.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(83= 1) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A___________________________= _____=0A From: cb.list6 =0ATo: Nalini Elkins =0ACc: IPv6 Ops WG ; Fernando Gont= ; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@too= ls.ietf.org" = =0ASent: Monday, June 3, 2013 7:04 AM=0ASubject: Re: [v6ops] new draft: dra= ft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0A=0AOn Jun 3, 2013 6:5= 9 AM, "Nalini Elkins" wrote:=0A>=0A> >> = Firewalls will usually block all extension headers. My advice in this=0A> >= > area would be "think twice before specifying an IPv6 extension header.=0A= > >>Then don't". :-)=0A>=0A> If firewalls block all extension headers, why = would time have been wasted at the IETF even specifying the protocols for e= xtension headers? =A0Am I wrong that firewalls are configured by people and= can be set to PASS extension headers rather than drop them?=0A>=0AIpv6 cam= e before ubiquitous firewalls=0AThe extension header fw knob may or may not= exist for your firewall=0AYou will likey have better luck advancing your d= raft if you include a statement that your extention header may not work on = the internet but can be engineerred to work within a single administrative = domain=0ACB=0A> Also, if the extension header provides value, I can guarant= ee you that people will set their firewalls to pass it. =A0 We have thought= "twice" and three times about proposing this. =A0 The only reason we do is= because it is important.=0A>=0A> I have mentioned the possibility of =A0th= is new extension header to executives at two different companies and both f= elt that it provided great value and might even be THE impetus they need to= migrate to IPv6. =A0 Better diagnostics AND end-to-end response time are v= ery practical and real needs for many companies. =A0 As you know, we were v= ery disturbed that one facility that we used frequently in IPv4, IPID, was = not available to us in IPv6. =A0 =A0=A0=0A> =A0=0A> Thanks,=0A>=0A> Nalini = Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> www.insidethestack.= com=0A>=0A> ________________________________=0A> From: Fernando Gont =0A> To: Nalini Elkins = =0A> Cc: Fred Baker (fred) ; Dan Wing (dwing) ; "v6ops@ietf.org" ; "draft-elkins-v6ops-ipv6-end-to-en= d-rt-needed@tools.ietf.org" =0A> Sent: Monday, June 3, 2013 6:47 AM=0A>=0A> Subject: Re:= [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A>=0A> On= 06/01/2013 05:35 PM, Nalini Elkins wrote:=0A> > 2.=A0 Forcing of IPv6 frag= mentation header.=A0 We did discuss this in=0A> > section 3:=0A> > http://t= ools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-1= 1=0A> >=0A> >=A0 It is as follows:=0A> > =0A> > "The current IPv6 specifica= tion does not provide a packet sequence=0A> > number or similar field in th= e IPv6 main header.=A0 One option might be=0A> > to force all IPv6 packets = to contain a Fragment Header.=A0 In packets=0A> > which are entire in and o= f themselves, the fragment ID would be zero=0A> > - that is, an atomic frag= ment.=0A>=0A> This is incorrect. Please reference any RFC section which req= uires a=0A> special Identification value (i.e., zero) for atomic fragments = (hint:=0A> there's no such a recommendation).=0A>=0A>=0A>=0A> > The second = reason for not having a fragment header is that=0A> > unfortunately, a numb= er of firewalls, etc, drop packets which contain=0A> > IPv6 fragment header= s.=A0 I find this to be unsuitable behavior which I=0A> > hope will change = .=A0 But, it is the reality.=0A>=0A> Firewalls will usually block all exten= sion headers. My advice in this=0A> area would be "think twice before speci= fying an IPv6 extension header.=0A> Then don't". :-)=0A>=0A> Cheers,=0A> --= =0A> Fernando Gont=0A> SI6 Networks=0A> e-mail: fgont@si6networks.com=0A> = PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492=0A>=0A>= =0A>=0A>=0A>=0A>=0A>=0A> _______________________________________________=0A= > v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/li= stinfo/v6ops=0A> --36908767-418500733-1370268701=:3081 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>> You will likey have better luck advancing yo= ur draft if you include a statement that your extention header may not work= on the internet but can be engineerred to work within a single administrat= ive domain

Good suggestion.
 
Thanks,

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

From: cb.list6 <cb.list6@gmail.com>=
To: Nalini Elkins <= ;nalini.elkins@insidethestack.com>
Cc: IPv6 Ops WG <v6ops@ietf.org>; Fernando Gont <f= gont@si6networks.com>; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@too= ls.ietf.org" <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.or= g>
Sent: Monday, June 3, 201= 3 7:04 AM
Subject: Re:= [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0A

=0AOn Jun 3, 2013 6:59 AM, "Nalini Elkins" <nalini.elkins@insidet= hestack.com> wrote:
=0A>
=0A> >> Firewalls will us= ually block all extension headers. My advice in this
=0A> >> ar= ea would be "think twice before specifying an IPv6 extension header.
=0A= > >>Then don't". :-)
=0A>
=0A> If firewalls block all = extension headers, why would time have been wasted at the IETF even specify= ing the protocols for extension headers?  Am I wrong that firewalls ar= e configured by people and can be set to PASS extension headers rather than= drop them?
=0A=0A>
=0A
Ipv6 came before ubiquit= ous firewalls
=0A
The extension header fw knob may or = may not exist for your firewall
=0A
You will likey hav= e better luck advancing your draft if you include a statement that your ext= ention header may not work on the internet but can be engineerred to work w= ithin a single administrative domain
=0A=0A
CB
= =0A
> Also, if the extension header provides value, I ca= n guarantee you that people will set their firewalls to pass it.   We = have thought "twice" and three times about proposing this.   The only = reason we do is because it is important.
=0A=0A>
=0A> I have me= ntioned the possibility of  this new extension header to executives at= two different companies and both felt that it provided great value and mig= ht even be THE impetus they need to migrate to IPv6.   Better diagnost= ics AND end-to-end response time are very practical and real needs for many= companies.   As you know, we were very disturbed that one facility th= at we used frequently in IPv4, IPID, was not available to us in IPv6.  = ;   
=0A=0A>  
=0A> Thanks,
=0A>
=0A>= ; Nalini Elkins
=0A> Inside Products, Inc.
=0A> (831) 659-8360<= br>=0A> www.insidethestack.com
=0A>
=0A> ____________= ____________________
=0A> From: Fernando Gont <fgont@si6networks.com>
=0A> To: Nalini = Elkins <= nalini.elkins@insidethestack.com>
=0A> Cc: Fred Baker (fred) = <fred@cisco.com>; Dan Wing (dwing) &l= t;dwing@cisco.com>; "v6ops@ietf.org" <v6ops@ietf.o= rg>; "draft-elkins-v6ops-= ipv6-end-to-end-rt-needed@tools.ietf.org" <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org>
= =0A=0A> Sent: Monday, June 3, 2013 6:47 AM
=0A>
=0A> Subject= : Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed
= =0A>
=0A> On 06/01/2013 05:35 PM, Nalini Elkins wrote:
=0A> = > 2.  Forcing of IPv6 fragmentation header.  We did discuss th= is in
=0A> > section 3:
=0A> > http://tools.ietf.org/html= /draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11
=0A> ><= br>=0A> >  It is as follows:
=0A> >
=0A> > "T= he current IPv6 specification does not provide a packet sequence
=0A>= > number or similar field in the IPv6 main header.  One option mig= ht be
=0A> > to force all IPv6 packets to contain a Fragment Heade= r.  In packets
=0A> > which are entire in and of themselves, = the fragment ID would be zero
=0A> > - that is, an atomic fragment= .
=0A>
=0A> This is incorrect. Please reference any RFC section= which requires a
=0A> special Identification value (i.e., zero) for = atomic fragments (hint:
=0A> there's no such a recommendation).
= =0A>
=0A>
=0A>
=0A> > The second reason for not hav= ing a fragment header is that
=0A> > unfortunately, a number of fi= rewalls, etc, drop packets which contain
=0A> > IPv6 fragment head= ers.  I find this to be unsuitable behavior which I
=0A> > ho= pe will change .  But, it is the reality.
=0A>
=0A> Firewa= lls will usually block all extension headers. My advice in this
=0A> = area would be "think twice before specifying an IPv6 extension header.
= =0A> Then don't". :-)
=0A>
=0A> Cheers,
=0A> --
= =0A> Fernando Gont
=0A> SI6 Networks
=0A> e-mail: fgont@si6networks.com
=0A> PGP = Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
=0A>=0A>
=0A>
=0A>
=0A>
=0A>
=0A>
=0A>= _______________________________________________
=0A> v6ops mailing l= ist
=0A> v6ops@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/v6ops
=0A>=0A
=0A


--36908767-418500733-1370268701=:3081-- From lorenzo@google.com Mon Jun 3 07:19:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E39F21F9998 for ; Mon, 3 Jun 2013 07:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, 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 e0VHpTa7bJzK for ; Mon, 3 Jun 2013 07:19:06 -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 C50AB21F9997 for ; Mon, 3 Jun 2013 07:19:05 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id o13so1842109qaj.18 for ; Mon, 03 Jun 2013 07:19: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=sKFnSdNP/xT+JGVr8MVggD/1P8kfOM+eeLh0+T9/1vU=; b=NN4QU66D8GeKIvQ9UE3ZLgowxPK6dKlEkfYYwkVxipHtuvRNhLJO0tEQgf430haCtl xKjycsNcgO9vCe3MAbH+XV05wcPu4WoOQ/AirJoZoiJqzqFvczx6fZm1T42VceSu9IXV pVgFEze/bwSBsTjDjiF6fhTE+kHRGIJU9xtV1+38+gTS9T6lBiawfqSwd8cyyrkUOIVT o0qP6zeWyXLoe0Ia7HTj+CO0NphjBjdcL0UlRlaWoniCFIM8nNsDG3wSYi6UsG+v3mlV HyK3pQxcdjB5m8KfP7cmlh3a92japisFmEIdw/PhX123Opz9gpV4EAb8OI18RgCu7p8i sXUw== 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=sKFnSdNP/xT+JGVr8MVggD/1P8kfOM+eeLh0+T9/1vU=; b=YfRJr5fyZc/2ivmlrs8TNiVytCIekcKZyFn7PYW130NAW6wI87xL9j38WIUjdfaE32 98Nza1sRvdrmVC7GnvQVvBlzV9ovAuG+b4S2NUe5dUcti48InSDsC6y9JRw/SVkiLXlp jRclfJPKQiWtF0dj3nEc2Wk42bqDByRw+czepwEFq0fEO10d2Ev8OhbVY1/8tMXr8fut WlVVkK90x95Wb0tUPHeXwU+xeLh7KoA1XHggvMcfhqYO2tYS7ZOmnPIU3bfUoz6grCKE ePoAT0fvxkSu7UKzT/XWvzDo4UZhryPaFUd+OX1qwYStnSrdPCZAd0wtoZ46YgfdXLL4 yAQQ== X-Received: by 10.224.214.134 with SMTP id ha6mr19202587qab.77.1370269145132; Mon, 03 Jun 2013 07:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Mon, 3 Jun 2013 07:18:44 -0700 (PDT) In-Reply-To: <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Mon, 3 Jun 2013 23:18:44 +0900 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=20cf300fb23da49e0f04de40a571 X-Gm-Message-State: ALoCoQn9k8STRx8n1eb3X0oGD3wRRRkOxWA1pkb8mRERONRc/HdnTYHPPxHgiuC7L2UBWwSSvA9sW/AK6vlCS7A7O6erd+LS87pxy4gDopRyx8Sr6o5CLvxazhZNysRFOWr3U2i17HSQqxirQR1QtYIQjI74O7v5+6COJee9/XvhE3OJgAkWi51IUJAA39XtUP2ltVmlna3v Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:19:06 -0000 --20cf300fb23da49e0f04de40a571 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 10:59 PM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > I have mentioned the possibility of this new extension header to > executives at two different companies and both felt that it provided great > value and might even be THE impetus they need to migrate to IPv6. > Nalini, I'm afraid that that is known as the "killer app" fallacy. I say "fallacy" instead of "argument" because such arguments have been tried many times but have not been very successful to date. I don't think it will be very convincing - especially since these companies already have what they need from IPv4, right? Also - supposing you do implement an extension header - how will the host know whether to use it or not? If it uses it to talk to the Internet, then the packet will get dropped. Does the host know which destinations understand it and which do not? Or will you be forced to specify and implement stripping this header in intermediate nodes? Cheers, Lorenzo --20cf300fb23da49e0f04de40a571 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 10:59 PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
I have menti= oned the possibility of =A0this new extension header to executives at two d= ifferent companies and both felt that it provided great value and might eve= n be THE impetus they need to migrate to IPv6.

Nalini,

I'm afraid that that is known as the "killer app" fa= llacy. I say "fallacy" instead of "argument" because su= ch arguments have been tried many times but have not been very successful t= o date. I don't think it will be very convincing - especially since the= se companies already have what they need from IPv4, right?

Also - supposing you do implement an extension header -= how will the host know whether to use it or not? If it uses it to talk to = the Internet, then the packet will get dropped. Does the host know which de= stinations understand it and which do not? Or will you be forced to specify= and implement stripping this header in intermediate nodes?

Cheers,
Lorenzo
--20cf300fb23da49e0f04de40a571-- From Ted.Lemon@nominum.com Mon Jun 3 07:22:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 fgont@si6networks.com Mon Jun 3 07:25:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AD711E80E6 for ; Mon, 3 Jun 2013 07:25:03 -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 sz2svyUrqpUT for ; Mon, 3 Jun 2013 07:25: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 65D5811E80E4 for ; Mon, 3 Jun 2013 07:25:02 -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 1UjVgv-0002qq-8Z; Mon, 03 Jun 2013 16:24:57 +0200 Message-ID: <51ACA737.6060406@si6networks.com> Date: Mon, 03 Jun 2013 16:24:55 +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 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:25:03 -0000 On 06/03/2013 03:50 PM, Nalini Elkins wrote: > When diagnosing problems at end locations, often, you finally get down > to a series of packets which is the problem. This may be 10 or 20 > packets. > > It doesn't matter what the bandwidth is, it does matter whether you can > say exactly what happened in those 10 or 20 packets. The bandwidth matters in the sense that the IP ID gets reused. If you want to uniqeuly identify a packet, why don't you employ a hash over, say, some IP header fields and upper layer header fields? -- that's something that you could do without bothering the network about it. Thanks, -- 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 3 07:30:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B3D21F9997 for ; Mon, 3 Jun 2013 07:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 60bIYy-SmleO for ; Mon, 3 Jun 2013 07:30:52 -0700 (PDT) Received: from nm26-vm0.access.bullet.mail.mud.yahoo.com (nm26-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7B221F9992 for ; Mon, 3 Jun 2013 07:30:45 -0700 (PDT) Received: from [66.94.237.199] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:30:45 -0000 Received: from [66.94.237.106] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:30:45 -0000 Received: from [127.0.0.1] by omp1011.access.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:30:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 339263.92707.bm@omp1011.access.mail.mud.yahoo.com Received: (qmail 31811 invoked by uid 60001); 3 Jun 2013 14:30:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370269844; bh=rhqEYZvcG5BqNsfzUt97NQrNLim5Zm9gq+a67rN3TO0=; 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=BM+mmh3mspWt2UoMc/YTUfP3nVvHbYfPvTTIMENH34bGfF5fLf0gtd3stqiZ/38OGHEBPHDN/eYkEqUuv8XU7QWYg0MG1kZw58LsChwCi/rW/pkUo9Zz5FxFLRfwwUt4Pg5vVyXb2+Tni/d4suQmHP4g9dNJBU8/9kq/N/94fTA= X-YMail-OSG: LHpNb1wVM1lBfbUcWpQS5jmQXPheQXdGNY1ficursZVmH5Z 6pzC42Nav73dddCRPZWt76M0gXJHPz1ogk0U_j_lcK5sjGJfR3qIuTFiHg4o fctjH3vagHdcriq26AE1oFj5tSOMckKaYE8f4Q4czbrv5jlVT.bPWeXwYexk xvaDDAYWr9jD9lSnB9nPHL9pV0aJQ8Ik.cdviTnKvBiRB5ZIkPeEoCW10P4u 680fqdmmVsAEtT_ubTxKr1CKG3jz12jOnvex7HcPrwj2QaY9DzeFD8eC1SND kp6Rt.dFxhD8pMFIMqvB.dr8EOLSohi8W0hGDDR115pRC.Otm3RXxKSmjPLI UktlFYWaOs_ff14XO7AQ7k0g6AybpMW.4n3kPgAN9VLX8xFharBdbxHBNdC8 GE6.1a_y6K3iTeWS2k_ZbWH2h6I54z64vaWtgRScYHmcLfrbVz.YRFqqwNLH yIzsSVZiKOc0zLnv8.HXRWQ_2pViDklntH9jbfmJFjUevglGRtig7wi3s50l 0jmj08gQU1R27PyiA7tcZO6y3Yhx.ssiEPiBw5ScxfchvPfgvp5K3oX4WX4c 2DV1W81wMNmIm7YvgwWga5Hri2K5pyB3hub1wDR1ooKwpuS0_xcLaSLWqd59 xPy.DYOphKL.4XvZDTyRiLxSu Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 07:30:44 PDT X-Rocket-MIMEInfo: 002.001, Pj5JJ20gYWZyYWlkIHRoYXQgdGhhdCBpcyBrbm93biBhcyB0aGUgImtpbGxlciBhcHAiIGZhbGxhY3kuIEkgc2F5ICJmYWxsYWN5IiBpbnN0ZWFkIG9mICJhcmd1bWVudCIgYmVjYXVzZSBzdWNoIGFyZ3VtZW50cyBoYXZlIGJlZW4gdHJpZWQgbWFueSB0aW1lcyBidXQgaGF2ZSBub3QgYmVlbiB2ZXJ5IHN1Y2Nlc3NmdWwgdG8gZGF0ZS4gSSBkb24ndCB0aGluayBpdCB3aWxsIGJlIHZlcnkgY29udmluY2luZyAtIGVzcGVjaWFsbHkgc2luY2UgdGhlc2UKPj5jb21wYW5pZXMgYWxyZWFkeSBoYXZlIHdoYXQgdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Message-ID: <1370269844.30551.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 07:30:44 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-588243940-1370269844=:30551" Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:30:58 -0000 ---1051860855-588243940-1370269844=:30551 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>I'm afraid that that is known as the "killer app" fallacy. I say "fallacy= " instead of "argument" because such arguments have been tried many times b= ut have not been very successful to date. I don't think it will be very con= vincing - especially since these=0A>>companies already have what they need = from IPv4, right?=0A=0APossibly you are right but given that the execs in q= uestion asked me about budget for IPv6, I would suspect that you are wrong.= =A0You underestimate how much companies spend on agents for gathering resp= onse time data which is required for Service Level Agreements. =A0AND how a= ttractive it is to NOT have to do that. =A0This extension header provides t= hem capabilities they do NOT have with IPv4.=0A=0A>> Also - supposing you d= o implement an extension header - how will the host know whether to use it = or not? If it uses it to talk to the Internet, then the packet will get dro= pped. Does the host know which destinations understand it and which do not?= Or will=0A>>you be forced to specify and implement stripping this header i= n intermediate nodes?=0A=0ANow this is a better point. =A0But, there is a b= igger issue here. =A0The companies and agencies that I work with on impleme= nting IPv6, already need to plan for how to differentiate between internal = traffic or traffic to business partners vs. traffic to the Internet. =A0 So= me alternatives used are Internet proxies, a separate prefix for Internet t= raffic vs. trusted traffic etc. =A0This is just one more issue that needs t= o be dealt with. =A0That is, on such routes or to such destinations, we do = not use this header.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Product= s, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______________= __________________=0A From: Lorenzo Colitti =0ATo: Nali= ni Elkins =0ACc: Fernando Gont ; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.or= g" ; "v6ops@ie= tf.org" =0ASent: Monday, June 3, 2013 7:18 AM=0ASubject: R= e: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A= =0A=0AOn Mon, Jun 3, 2013 at 10:59 PM, Nalini Elkins wrote:=0A=0AI have mentioned the possibility of =A0this new ex= tension header to executives at two different companies and both felt that = it provided great value and might even be THE impetus they need to migrate = to IPv6.=0A=0ANalini,=0A=0AI'm afraid that that is known as the "killer app= " fallacy. I say "fallacy" instead of "argument" because such arguments hav= e been tried many times but have not been very successful to date. I don't = think it will be very convincing - especially since these companies already= have what they need from IPv4, right?=0A=0AAlso - supposing you do impleme= nt an extension header - how will the host know whether to use it or not? I= f it uses it to talk to the Internet, then the packet will get dropped. Doe= s the host know which destinations understand it and which do not? Or will = you be forced to specify and implement stripping this header in intermediat= e nodes?=0A=0ACheers,=0ALorenzo ---1051860855-588243940-1370269844=:30551 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>>I'm afraid that that is known as the "killer app" fallacy= . I say "fallacy" instead of "argument" because such arguments have been tr= ied many times but have not been very successful to date. I don't think it = will be very convincing - especially since these
>>companies already have what they need from IPv= 4, right?

Possibly you are right but given that the execs in question asked me about budget for IPv6, I would suspect that you= are wrong.  You underestimate how much companies spend on agents for = gathering response time data which is required for Service Level Agreements= .  AND how attractive it is to NOT have to do that.  This extensi= on header provides them capabilities they do NOT have with IPv4.

>> Also - supposing you do implement an extension heade= r - how will the host know whether to use it or not? If it uses it to talk = to the Internet, then the packet will get dropped. Does the host know which= destinations understand it and which do not? Or will
>>you be forced to specify and impleme= nt stripping this header in intermediate nodes?

Now= this is a better point.  But, there is a bigger issue here.  The= companies and agencies that I work with on implementing IPv6, already need= to plan for how to differentiate between internal traffic or traffic to bu= siness partners vs. traffic to the Internet.   Some alternatives used = are Internet proxies, a separate prefix for Internet traffic vs. trusted tr= affic etc.  This is just one more issue that needs to be dealt with. &= nbsp;That is, on such routes or to such destinations, we do not use this header.
 
Thanks,

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

From:<= /b> Lorenzo Colitti <lorenzo@google.com>
To: Nalini Elkins <nalini.elkins@insidethestack= .com>
Cc: Fernando = Gont <fgont@si6networks.com>; "draft-elkins-v6ops-ipv6-end-to-end-rt-= needed@tools.ietf.org" <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@too= ls.ietf.org>; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Monday, June 3, 2013 7:18 AM
= Subject: Re: [v6ops] new draft: dr= aft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0A
On Mon, = Jun 3, 2013 at 10:59 PM, Nalini Elkins <nalini.elkins@insidethest= ack.com> wrote:
=0A= =0A=0A
I have mentioned the possibility of &nbs= p;this new extension header to executives at two different companies and bo= th felt that it provided great value and might even be THE impetus they nee= d to migrate to IPv6.
=0A=0A=0A
<= div>
Nalini,

I'm afraid that that is= known as the "killer app" fallacy. I say "fallacy" instead of "argument" b= ecause such arguments have been tried many times but have not been very suc= cessful to date. I don't think it will be very convincing - especially sinc= e these companies already have what they need from IPv4, right?
=0A=0A= =0A

Also - supposing you do implement an extension heade= r - how will the host know whether to use it or not? If it uses it to talk = to the Internet, then the packet will get dropped. Does the host know which= destinations understand it and which do not? Or will you be forced to spec= ify and implement stripping this header in intermediate nodes?
=0A=0A= =0A

Cheers,
Lorenzo
=0A=


---1051860855-588243940-1370269844=:30551-- From nalini.elkins@insidethestack.com Mon Jun 3 07:34:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0021F99D2 for ; Mon, 3 Jun 2013 07:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.128, 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 sfv2y6Tp2PnI for ; Mon, 3 Jun 2013 07:34:21 -0700 (PDT) Received: from nm7.access.bullet.mail.mud.yahoo.com (nm7.access.bullet.mail.mud.yahoo.com [66.94.237.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8816F21F99D0 for ; Mon, 3 Jun 2013 07:34:21 -0700 (PDT) Received: from [66.94.237.197] by nm7.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:34:21 -0000 Received: from [66.94.237.104] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:34:21 -0000 Received: from [127.0.0.1] by omp1009.access.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:34:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 224892.19534.bm@omp1009.access.mail.mud.yahoo.com Received: (qmail 78584 invoked by uid 60001); 3 Jun 2013 14:34:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370270060; bh=nRkBdEsizJWV90+3IZP/efTNx6u16jzcXM0OaNPaHPM=; 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=nL/NmLsr8LBfnpuELFJ/bbteoT3Z5nLxi3eI4NOiW/1AUw2VHSh9tH6XrlTDHILjIoRxZuMoPZ8FannEYWC/cQddrXm3RTmBtO29vRJ3h5F6w75UnUhJU2qM9GNx/H1Zn8vKDuJa+snokwCeWxt/DDWD6jAPBtnvagMY/cAu4H8= X-YMail-OSG: 3Hil4ugVM1l4btKuSOFHCd._V9BkXeLKMVANNvTzNqNNMQB JHeEq.JYJeJJ_PXBS9JUsBgdzU_gwKWnP4SfKdQU12VGdbTUL93v_5Pw1GRT dMBrQ3YFnAyAq5MO0Ld5.Ul7T26MMO1_LjPfSxqEPrUp.Vc7Qu_0sWH5Fk2y arO5BBiIUr8Q2MyUwnmHzV097M5Uo8rrBKX9OPO_MXBURQfPVRXGCe5h6q9d h26Iv4H7suVY7d1LwGW2QJzvQIqXkIXaBRFgQlD4MVfZ2vAHE7C4uRYwejRW ZkcDmTZiG7QmLCZQ6_.MX_OpIoQzNQCo7es8pPgzuxGN_EGyFVwqDJwi6hLW i_xCetiQDVou.NSlu_jnUCosADSrcnsYY6kN8_y.dHoiJY8VdySgo.vKXhDP Ev0WCvuZTRNrd2gzNJL8J._zumw.kdMGUR.3HQEndCBaZLPfWiCSmWmZ_HVz hB83ONGwSgIpHQ1bjNwT6eksfaz3qDB3zPgjT.z.XHqdMb8dkORvPsHF.03Z f4HEvVm4NjwM6CuPSGt9friDEJkHk5ptrhqMKnlC0Q8eDa._VEyOVxRunswu C1Be5HNUb4VfQXGeAbQhPgB_vK5.rcABrz7updM16mAhYjFbRqPBycLKhMcE L55cdBHeD.oTEgtLczjxW.A-- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 07:34:20 PDT X-Rocket-MIMEInfo: 002.001, Pj5UaGUgYmFuZHdpZHRoIG1hdHRlcnMgaW4gdGhlIHNlbnNlIHRoYXQgdGhlIElQIElEIGdldHMgcmV1c2VkLgoKSXQgbWF5IGdldCByZXVzZWQgYnV0IGl0IGlzIHZlcnkgZWFzeSB0byBzZWUgdGhhdCBpZiB5b3UgYXJlIGxvb2tpbmcgYXQgMTAgLSAyMCBwYWNrZXRzIGF0IGEgdGltZS4KCj4.wqBJZiB5b3Ugd2FudCB0byB1bmlxZXVseSBpZGVudGlmeSBhIHBhY2tldCwgd2h5IGRvbid0IHlvdSBlbXBsb3kgYSBoYXNoCj4.b3Zlciwgc2F5LCBzb21lIElQIGhlYWRlciBmaWVsZHMgYW5kIHVwcGVyIGxheWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> Message-ID: <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 07:34:20 -0700 (PDT) From: Nalini Elkins To: Fernando Gont In-Reply-To: <51ACA737.6060406@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-460116419-1370270060=:78252" Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:34:26 -0000 ---153701192-460116419-1370270060=:78252 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>The bandwidth matters in the sense that the IP ID gets reused.=0A=0AIt ma= y get reused but it is very easy to see that if you are looking at 10 - 20 = packets at a time.=0A=0A>>=A0If you want to uniqeuly identify a packet, why= don't you employ a hash=0A>>over, say, some IP header fields and upper lay= er header fields?=0A=0A=0AThis will not work. =A0 We have thought about thi= s and I actually did a prototype implementation. =A0What happens is that on= REAL networks there is false duplication of packets caused by packet trace= facilities. =A0 The hash will end up being the same. =A0 Please see:=0A=0A= http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-0= 0#page-9=0A=0A=0A2.1.1 Limitations of Packet Capture=0A=A0=0AThanks,=0A=0A= =0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethest= ack.com=0A=0A=0A=0A________________________________=0A From: Fernando Gont = =0ATo: Nalini Elkins =0ACc: Dan Wing ; "v6ops@ietf.org" ; "= draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" =0ASent: Monday, June 3, 20= 13 7:24 AM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to= -end-rt-needed=0A =0A=0A=0AOn 06/03/2013 03:50 PM, Nalini Elkins wrote:=0A>= When diagnosing problems at end locations, often, you finally get down=0A>= to a series of packets which is the problem.=A0 This may be 10 or 20=0A> = packets.=A0 =0A> =0A> It doesn't matter what the bandwidth is, it does matt= er whether you can=0A> say exactly what happened in those 10 or 20 packets.= =A0 =0A=0AThe bandwidth matters in the sense that the IP ID gets reused.=0A= =0AIf you want to uniqeuly identify a packet, why don't you employ a hash= =0Aover, say, some IP header fields and upper layer header fields?=0A=0A-- = that's something that you could do without bothering the network=0Aabout it= .=0A=0AThanks,=0A-- =0AFernando Gont=0ASI6 Networks=0Ae-mail: fgont@si6netw= orks.com=0APGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 74= 92 ---153701192-460116419-1370270060=:78252 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>>The bandwidth = matters in the sense that the IP ID gets reused.

It may get reused but it is v= ery easy to see that if you are looking at 10 - 20 packets at a time.

>> If = you want to uniqeuly identify a packet, why don't you employ a hash<= /span>
>>over, say, some IP header fields and u= pper layer header fields?

This will not work.  = ; We have thought about this and I actually did a prototype implementation.=  What happens is that on REAL networks there is false duplication of = packets caused by packet trace facilities.   The hash will end up bein= g the same.   Please see:


<= /span>
2.1.1 Limitations of Packet Capture
 
Thanks,

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

From: Fernando Gont <fgont@si6networks.com>
To: Nalini Elkins <nalini.elkins@insidethestack.= com>
Cc: Dan Wing <dwing@cisco.com>; "v6ops@ietf.org" <v6ops@ietf.org>; "draft-e= lkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" <draft-elkins-v6op= s-ipv6-end-to-end-rt-needed@tools.ietf.org>
Sent: Monday, June 3, 2013 7:24 AM
Subject: Re: [v6ops] new draft: draf= t-elkins-v6ops-ipv6-end-to-end-rt-needed

=0A
On 06/03/2013 03:50 PM, Nalini Elkins wrote:
= > When diagnosing problems at end locations, often, you finally get down=
> to a series of packets which is the problem.  This may be 10= or 20
> packets. 
>
> It doesn't matter what the = bandwidth is, it does matter whether you can
> say exactly what happe= ned in those 10 or 20 packets. 

The bandwidth matters in the = sense that the IP ID gets reused.

If you want to uniqeuly identify a= packet, why don't you employ a hash
over, say, some IP header fields an= d upper layer header fields?

-- that's something that you could do w= ithout bothering the network
about it.

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





---153701192-460116419-1370270060=:78252-- From owen@delong.com Mon Jun 3 07:39:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 owen@delong.com Mon Jun 3 07:43:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84B021F99D5 for ; Mon, 3 Jun 2013 07:43:32 -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.048, 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 5mwRgV5+WWmu for ; Mon, 3 Jun 2013 07:43:31 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C8B3F21F9691 for ; Mon, 3 Jun 2013 07:43:31 -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 r53Ee1QZ010885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 07:40:03 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53Ee1QZ010885 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370270404; bh=93FqV2w5a4YbNtYeQdKy8Lv0isk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=hfr0kDU5B50+A0evYFS4nOsHiHrg5pRQD0d+RVTrKLwVmOG5wiMqkNRZ4Xax5BzJY OpgG3X7IMkWV0LnrIWDaV9HE4M6zeJJY1t8R07jz+h1dA9U6jN5Uh65T6v+wvZ2Kjd x2SiXtrrxqNZ4cCuNqTMbmSvZXasax4vDw837Ixo= Content-Type: multipart/alternative; boundary="Apple-Mail=_E665C44A-B074-4FFB-BD7C-A822B6FAA4C0" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 09:40:00 -0500 Message-Id: <027F849D-4C37-456D-A0CA-02999902974C@delong.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> To: Nalini Elkins 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:40:04 -0700 (PDT) Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:43:33 -0000 --Apple-Mail=_E665C44A-B074-4FFB-BD7C-A822B6FAA4C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 3, 2013, at 9:34 AM, Nalini Elkins = wrote: > >>The bandwidth matters in the sense that the IP ID gets reused. >=20 > It may get reused but it is very easy to see that if you are looking = at 10 - 20 packets at a time. >=20 > >> If you want to uniqeuly identify a packet, why don't you employ a = hash > >>over, say, some IP header fields and upper layer header fields? >=20 > This will not work. We have thought about this and I actually did a = prototype implementation. What happens is that on REAL networks there = is false duplication of packets caused by packet trace facilities. The = hash will end up being the same. Please see: >=20 If it's a false duplication, wouldn't your sequence number also get = duplicated and thus be the same, just like the hash? Perhaps I am confused. Owen > = http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-= 00#page-9 >=20 > 2.1.1 Limitations of Packet Capture > =20 > Thanks, >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com >=20 > From: Fernando Gont > To: Nalini Elkins =20 > Cc: Dan Wing ; "v6ops@ietf.org" ; = "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" = =20 > Sent: Monday, June 3, 2013 7:24 AM > Subject: Re: [v6ops] new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed >=20 >=20 > On 06/03/2013 03:50 PM, Nalini Elkins wrote: > > When diagnosing problems at end locations, often, you finally get = down > > to a series of packets which is the problem. This may be 10 or 20 > > packets. =20 > >=20 > > It doesn't matter what the bandwidth is, it does matter whether you = can > > say exactly what happened in those 10 or 20 packets. =20 >=20 > The bandwidth matters in the sense that the IP ID gets reused. >=20 > If you want to uniqeuly identify a packet, why don't you employ a hash > over, say, some IP header fields and upper layer header fields? >=20 > -- that's something that you could do without bothering the network > about it. >=20 > Thanks, > --=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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_E665C44A-B074-4FFB-BD7C-A822B6FAA4C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 nalini.elkins@insidethest= ack.com> wrote:
>>The bandwidth matters in the sense that the IP ID = gets reused.
It may get reused but it is = very easy to see that if you are looking at 10 - 20 packets at a = time.

If you want to uniqeuly identify a packet, = why don't you employ a hash
>>over, say, some IP header fields and upper layer header = fields?

2.1.1 =
Limitations of Packet =
Capture
 
Thanks,

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

=
From: Fernando Gont = <fgont@si6networks.com>
To: Nalini Elkins = <nalini.elkins@insidethestack.com>
Cc: Dan Wing <dwing@cisco.com>; "v6ops@ietf.org" <v6ops@ietf.org>; = "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" = <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org>
= Sent: Monday, June 3, = 2013 7:24 AM
Subject: Re: [v6ops] new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed


On 06/03/2013 03:50 PM, Nalini Elkins wrote:
> When diagnosing = problems at end locations, often, you finally get down
> to a = series of packets which is the problem.  This may be 10 or = 20
> packets. 
>
> It doesn't matter what the = bandwidth is, it does matter whether you can
> say exactly what = happened in those 10 or 20 packets. 

The bandwidth matters = in the sense that the IP ID gets reused.

If you want to uniqeuly = identify a packet, why don't you employ a hash
over, say, some IP = header fields and upper layer header fields?

-- that's something = that you could do without bothering the network
about = it.

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






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

= --Apple-Mail=_E665C44A-B074-4FFB-BD7C-A822B6FAA4C0-- From nalini.elkins@insidethestack.com Mon Jun 3 07:47:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BB021E809E for ; Mon, 3 Jun 2013 07:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 NZ55rW2g5tsz for ; Mon, 3 Jun 2013 07:47:09 -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 70BAC21E809A for ; Mon, 3 Jun 2013 07:47:06 -0700 (PDT) Received: from [66.94.237.193] by nm23.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:47:06 -0000 Received: from [66.94.237.117] by tm4.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:47:06 -0000 Received: from [127.0.0.1] by omp1022.access.mail.mud.yahoo.com with NNFMP; 03 Jun 2013 14:47:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 144601.53078.bm@omp1022.access.mail.mud.yahoo.com Received: (qmail 47248 invoked by uid 60001); 3 Jun 2013 14:47:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370270825; bh=Xeuj+KEr3XT+NmMWv4sG6Cvw7NixX0bb94LD/Gzs3Zw=; 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=hjSuiSf+Jl8gZtcfK7RkhJelKaYqu9nTLlrj6X2pnxj6SH9oGyDCDl5FAhMv21OHAFfxgg3Qq4G0z9UPyo3Sbja9PXh4D4ZhHeNdHv2PQMXsXzavfVleMyLrjxUrCwsZWJfeN0X26UIq9JlBTQjZXnCuQV4SZWDxhvOYPZRL698= X-YMail-OSG: AiaI7CEVM1l.IYP8DQek_oBefxTt2wjg55wQsnFRXAldIL_ ZbtzbonOKn_llQc2y6ddeiFEvfUFrmL97cnFdbHXi2PrqT25zOfYHZZvoLCh ZNHK8WlmEKhIrn1K.ek0pt3uZ9MFW11BoajLQ.xbuDxGJwJ8EsV76Erpvpx6 hkJkb6v0IoiiyB5LWUSzLO69L_52mBT4dbQsgEuxw0qS8gJ3OTyBsPLBisvg R.4JQ6XC1xS8ER7hdT24TaUfNU3E3oMzLTp0X5PTHQfnWg5wJHMyqIJIr87O rDC7SeCQwwMkfaKeWuMtbiA6Upao94DWgZptnE3uQswOuVLW0MXpBbYP0iFB C2DQgl.SYm7KZqKxEvCUWQl35nIuhzTlFeXzYhmR2VJfb86g96iQoEj1rmj0 NoyXHqPr16lGF1.cOB3KrKhFuvjDRMkfg.uHgTDP9zw0IA8IaymyX84cHhnl BrT4GNMvfnxKQnhNz2PbfVw_lxflVdEFWUtNp2iTOYukmJIzqTbXPAlSByho 0O2cjHlT_gGCWCKHttaZuZ17j_PY5A7OVSYYcjqll6wuyvpk4NJEcKKNEnFT AAZVG5sHBJ4V9V0R2AZMq.UAXZYA.GzGJZsj5t5WMCDpA_wNbO6eDn0SUG4o 2l7DmreP9TUxIHyc- Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 07:47:05 PDT X-Rocket-MIMEInfo: 002.001, Pj4gSWYgaXQncyBhIGZhbHNlIGR1cGxpY2F0aW9uLCB3b3VsZG4ndCB5b3VyIHNlcXVlbmNlIG51bWJlciBhbHNvIGdldCBkdXBsaWNhdGVkIGFuZCB0aHVzIGJlIHRoZSBzYW1lLCBqdXN0IGxpa2UgdGhlIGhhc2g_CgoKSW5kZWVkIGl0IHdvdWxkLiDCoFNpbmNlIHdlIGtub3cgdGhhdCB0aGUgY29tYmluYXRpb24gb2YgUGFja2V0IFNlcXVlbmNlIE51bWJlciBhbmQgVGltZXN0YW1wIHRvZ2V0aGVyIHNob3VsZCBuZXZlciBiZSBkdXBsaWNhdGVkLCB0aGVuIHdlIGFyZSBzYWZlIHRvIGFzc3VtZSB0aGF0IHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <027F849D-4C37-456D-A0CA-02999902974C@delong.com> Message-ID: <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 07:47:05 -0700 (PDT) From: Nalini Elkins To: Owen DeLong In-Reply-To: <027F849D-4C37-456D-A0CA-02999902974C@delong.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-1208994163-1370270825=:46784" Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:47:15 -0000 ---1051860855-1208994163-1370270825=:46784 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> If it's a false duplication, wouldn't your sequence number also get dupl= icated and thus be the same, just like the hash?=0A=0A=0AIndeed it would. = =A0Since we know that the combination of Packet Sequence Number and Timesta= mp together should never be duplicated, then we are safe to assume that suc= h a packet is a false duplicate.=A0=0A=0AIf the packet seq number wraps, th= en the timestamp will be different.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins= =0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A= =0A________________________________=0A From: Owen DeLong = =0ATo: Nalini Elkins =0ACc: Fernando Gon= t ; "v6ops@ietf.org" ; "draft-elkins= -v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" =0ASent: Monday, June 3, 2013 7:40 AM= =0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-ne= eded=0A =0A=0A=0A=0A=0AOn Jun 3, 2013, at 9:34 AM, Nalini Elkins wrote:=0A=0A>>The bandwidth matters in the sense t= hat the IP ID gets reused.=0A>=0A>=0A>It may get reused but it is very easy= to see that if you are looking at 10 - 20 packets at a time.=0A>=0A>=0A>>>= =A0If you want to uniqeuly identify a packet, why don't you employ a hash= =0A>>>over, say, some IP header fields and upper layer header fields?=0A>= =0A>=0A>=0A>This will not work. =A0 We have thought about this and I actual= ly did a prototype implementation. =A0What happens is that on REAL networks= there is false duplication of packets caused by packet trace facilities. = =A0 The hash will end up being the same. =A0 Please see:=0A>=0A>=0AIf it's = a false duplication, wouldn't your sequence number also get duplicated and = thus be the same, just like the hash?=0A=0APerhaps I am confused.=0A=0AOwen= =0A=0A=0Ahttp://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence= -needed-00#page-9=0A>=0A>=0A>=0A>2.1.1 Limitations of Packet Capture=0A>=A0= =0A>Thanks,=0A>=0A>=0A>Nalini Elkins=0A>Inside Products, Inc.=0A>(831) 659-= 8360=0A>www.insidethestack.com=0A>=0A>=0A>=0A>_____________________________= ___=0A> From: Fernando Gont =0A>To: Nalini Elkins =0A>Cc: Dan Wing ; "v6ops= @ietf.org" ; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@= tools.ietf.org" =0A>Sent: Monday, June 3, 2013 7:24 AM=0A>Subject: Re: [v6ops] new draft= : draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A> =0A>=0A>=0A>On 06/03/201= 3 03:50 PM, Nalini Elkins wrote:=0A>> When diagnosing problems at end locat= ions, often, you finally get down=0A>> to a series of packets which is the = problem.=A0 This may be 10 or 20=0A>> packets.=A0 =0A>> =0A>> It doesn't m= atter what the bandwidth is, it does matter whether you can=0A>> say exactl= y what happened in those 10 or 20 packets.=A0 =0A>=0A>The bandwidth matters= in the sense that the IP ID gets reused.=0A>=0A>If you want to uniqeuly id= entify a packet, why don't you employ a hash=0A>over, say, some IP header f= ields and upper layer header fields?=0A>=0A>-- that's something that you co= uld do without bothering the network=0A>about it.=0A>=0A>Thanks,=0A>-- =0A>= Fernando Gont=0A>SI6 Networks=0A>e-mail: fgont@si6networks.com=0A>PGP Finge= rprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492=0A>=0A>=0A>=0A>= =0A>=0A>=0A>_______________________________________________=0A>v6ops mailin= g list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listinfo/v6ops=0A> ---1051860855-1208994163-1370270825=:46784 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>> If it's a false duplication, wouldn't your s= equence number also get duplicated and thus be the same, just like the hash= ?

=
Indeed it would.  Since we know that the combination of Packet= Sequence Number and Timestamp together should never be duplicated, then we= are safe to assume that such a packet is a false duplicate. 

If the packet seq number wraps, then the timestamp will = be different.
 
Thanks,
=
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
= www.insidethestack.com

From: Owen DeLong <owen@delong.com>
To: Nalini Elkins <nalini.elkins@insi= dethestack.com>
Cc:= Fernando Gont <fgont@si6networks.com>; "v6ops@ietf.org" <v6ops@ie= tf.org>; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" &= lt;draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org>
= Sent: Monday, June 3, 2013 7:= 40 AM
Subject: Re: [v6ops] new = draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0A

On Jun 3, 2013, at 9:34 AM, Nalini Elkins <nalini.elkins@insidethestack.com&= gt; wrote:

>= ;>The bandwidth matters in the sense that the IP ID gets reused.<= /span>

It may get reused but it is very easy to see that if you are looking at 10 - 20 packets at a time.<= /span>

>> If you want to uniqeuly identify a pack= et, why don't you employ a hash
>>over, say, some IP h= eader fields and upper layer header fields?

This will not work.   We have thought about this and I actually= did a prototype implementation.  What happens is that on REAL network= s there is false duplication of packets caused by packet trace facilities. =   The hash will end up being the same.   Please see:
=

If it's a false dupli= cation, wouldn't your sequence number also get duplicated and thus be the s= ame, just like the hash?

Perhaps I am confused.

Owen

http://tools.ietf.org/html/dr= aft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-9

<=
h4 style=3D"line-height:0pt;display:inline;font-size:1em;">2.1.1 Limitat=
ions of Packet Capture
 
Th= anks,

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

From: Fernando Gont <fgont@si6networks= .com>
To: Nalini Elkins <nalini.elkins= @insidethestack.com>
Cc:= Dan Wing=0A <dwing@cisco.com>; "v6ops@ietf.org" <v6ops@ietf.o= rg>; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" <d= raft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org>
Sent: Monday, June 3, 2013 7:24 AM=
Subject: Re: [v6ops] n= ew draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed
<= div class=3D"yiv430869796y_msg_container">
=0A
On 06/03/2013 03:50 PM= , Nalini Elkins wrote:
> When diagnosing problems at end locations, o= ften, you finally get down
> to a series of packets which is the prob= lem.  This may be 10 or 20
> packets. 
>
> I= t doesn't matter what the bandwidth is, it does matter whether you can
&= gt; say exactly what happened in those 10 or 20 packets. 

The= bandwidth matters in the sense that the IP ID gets reused.

If you w= ant to uniqeuly identify a packet, why don't you employ a hash
over, say= , some IP header fields and upper layer header fields?

-- that's som= ething that you could do without bothering the network
about it.

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






=0A
_______________________________________________
v6ops mailing list
<= a rel=3D"nofollow" ymailto=3D"mailto:v6ops@ietf.org" target=3D"_blank" href= =3D"mailto:v6ops@ietf.org">v6ops@ietf.org
https://www.ietf.org/mailm= an/listinfo/v6ops



---1051860855-1208994163-1370270825=:46784-- From trejrco@gmail.com Mon Jun 3 07:54:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A185521F9985 for ; Mon, 3 Jun 2013 07:54: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, 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 vfnR530b3h8D for ; Mon, 3 Jun 2013 07:54:08 -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 B9F0621F896D for ; Mon, 3 Jun 2013 07:54:07 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w8so2629178vbf.7 for ; Mon, 03 Jun 2013 07:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=71hpQp4DnND3xW7xaRYeRnifuLuZTI9UbGuBwvt4DSU=; b=Z7oroUzuaDessxtqGJPMaHZYUh4tbJb/yx7fOQK1nj7PX6w9C/1RrWuwoeuCG16TTW 9GufV90ajb/zHpodLycBN+wtPvzoMFK9plAeSnJJA3NhCQCfKLPdJMUs6XBmO1sQ5HeI LnCPqLP3PkhLfz6kuJu+JQIDXcTrmFD+TpUVc0v1HSh3s2/EFvQa4jL898UxQSgN+7sz S6QZqScJCaNl2gz7d/5029QIlm6PfLaQGqR/oq5jRMWR3/XM3HQ0kQOTzYzY/w/XLKC6 KGRuqWy4ad10PMuyN6imGU84SNrYFWZiQiuEzGJQQVNIQBJglAk55aRx2fJk4RG4zjBU /VGQ== X-Received: by 10.52.65.238 with SMTP id a14mr14274565vdt.24.1370271247044; Mon, 03 Jun 2013 07:54:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.164.65 with HTTP; Mon, 3 Jun 2013 07:53:46 -0700 (PDT) In-Reply-To: <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> <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> From: TJ Date: Mon, 3 Jun 2013 10:53:46 -0400 Message-ID: To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=20cf307f3372ed18d304de412247 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trejrco@gmail.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:54:08 -0000 --20cf307f3372ed18d304de412247 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 10: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 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. > Perhaps the biggest difference is one point of view is proposing taking those bits now and making them special, while the other keeps them available for future uses. That is, looking more to future flexibility vs. using them in the here and now. Not saying either PoV is right or wrong, just making an observation. Well, that and voicing a vote against standardizing the overload-semantics at the ISP level in this way. Other ways/reasons may sway me, but these do not ... /TJ *<-- willing to settle for a /56 if it gets us one mental hurdle closer to more widespread deployment ...* --20cf307f3372ed18d304de412247 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 10:22 AM, Ted Lemon <= span dir=3D"ltr"><Ted.Lemon@nominum.com> wrote:
On Jun 3, 2013, at 9:46 AM, Owen DeLong <owen@delong.com>=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.= =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. =A0 Being an end-user, I have a lot o= f sympathy for your position, but I don't think this is something on wh= ich the IETF is likely to achieve a strong consensus, and that's okay. = =A0 Whether you like semantic prefixes or not, they are something that ISPs are experimenting with, for reasons they thin= k are valid. =A0 What we should be talking about is not whether they can do= these experiments, but why they are doing them.


Perhaps the biggest difference is one po= int of view is proposing taking those bits now and making them special, whi= le the other keeps them available for future uses. =A0That is, looking more= to future flexibility vs. using them in the here and now. =A0Not saying ei= ther PoV is right or wrong, just making an observation. =A0

Well, that and voicing a vote against standardizing the overload-semant= ics at the ISP level in this way. =A0
Other ways/reasons may sway= me, but these do not ...=A0


/TJ <-- willing to settle for a /56 if it gets us one mental hurdle closer = to more widespread deployment ...
=A0
--20cf307f3372ed18d304de412247-- From fgont@si6networks.com Mon Jun 3 07:55:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC17021F99B9 for ; Mon, 3 Jun 2013 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gubRueNqLmWs for ; Mon, 3 Jun 2013 07:55:05 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 33C2821F9985 for ; Mon, 3 Jun 2013 07:55:05 -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 1UjW9t-0003Yv-5d; Mon, 03 Jun 2013 16:54:53 +0200 Message-ID: <51ACAE3B.2050907@si6networks.com> Date: Mon, 03 Jun 2013 16:54: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: Nalini Elkins References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <027F849D-4C37-456D-A0CA-02999902974C@delong.com> <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> In-Reply-To: <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:55:06 -0000 On 06/03/2013 04:47 PM, Nalini Elkins wrote: >>> If it's a false duplication, wouldn't your sequence number also get duplicated and thus be the same, just like the hash? > > Indeed it would. Since we know that the combination of Packet Sequence > Number and Timestamp together should never be duplicated, then we are > safe to assume that such a packet is a false duplicate. > > If the packet seq number wraps, then the timestamp will be different. I guess this all depends on the granularity of the timestamps. That said, I personally think that this looks like too much stress on the network and implementations for something that is not meant for the general Internet, and that can be performed, to a large extent, with techniques such as a hash function on the headers. P.S.: Before any attempt on this path, one should probably ask: are we suppoed to have this ind of functionality at the Internet layer? Is this worth the pain for most implementations? Is this going to work in the general case, or is this going to be the subject of lots fo breakage? (e.g., packet drops) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ales.vizdal@t-mobile.cz Mon Jun 3 07:59:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 nalini.elkins@insidethestack.com Mon Jun 3 08:03:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5048021F99C5 for ; Mon, 3 Jun 2013 08:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, 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 JK5c0rOfbGmZ for ; Mon, 3 Jun 2013 08:03:30 -0700 (PDT) Received: from nm5-vm0.access.bullet.mail.sp2.yahoo.com (nm5-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7872A21F99D4 for ; Mon, 3 Jun 2013 08:03:30 -0700 (PDT) Received: from [98.139.44.100] by nm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 15:03:30 -0000 Received: from [98.139.44.90] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 15:03:30 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 15:03:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 292377.74226.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 46275 invoked by uid 60001); 3 Jun 2013 15:03:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370271809; bh=Gj/EI1KNhOaXgmr2CJxxU0JRyvGYscQhNYjUQTbyqps=; 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=KVT3+OBpUMXsB9q8uiRwzHvmunV3zP2mQsqaw7jeQfhrdZhoDC9BnhJXyxz9r5svQNxpQ0P6GBdNjOWdpERh5fO9o7xoWgfX+HX/Fl0wYVq/A4z2Va0zedU1D0bx7iEBnYoaOPHLNMBqhnyc4gAJcv8RvPFwdB8wAUQCxA7OlF0= X-YMail-OSG: a6N4RcsVM1mrDVMZBOGCf8A0_MnS.8oN9IW93VzJRpOqG8V wc2gxkWkVANiKLQ4oddC__zuDrVv8WaLB6d_sqh0vdoMBxuuZiCMkIhw4BTD LD.5ZRTatRY7CLWfB_29RVArrIvn9_wfk6Iir1Oj4d.l456WHcfCOJFBkGwE YBS.5Za.gHwkr6B.TEWhApdCjZKBo5jEzX_LZZ3NcX5f4AlPHF99zs4iFDXi r977q6Futf.U8BwCv1hVtHzCdDJaQff5HkOwaN7oQm2FrTJoPvUJJ1f.G1xr cKf8pFe2d7SFXF_5w5nGxJQGPDdkXFCJfZNtqSK5z5IQVMZRaM9nk.vUUlGo hB.1GO7UKa4IDthf_UWRoXUVoueGPQvk063TtDO0RQeDfWWOAhqU7Mcg62Uy uDF897TSOLoc18V618JmkUm4m6hDeCvaf76l1TM.FtxjNnU1vOzCp3XnZrUC MVexV22J6uXxFd_QTMiG5ZCPlJnpNkVERW.jvbJ5viou7kgycIOk8dG76Ekh 6jVDhl3lTJcKmGMiz8PR_N43mzC6y164tjpWmPu4yVA4dV2zQKkWZHTdZ9Ex PsJWLi5g0oSbph97FjNO2A2qdNB8QWFkejJQNM_31.ON6fYS8q.BeZSyYQT7 yHrctO4zGdPzDyMIow.3w Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 08:03:29 PDT X-Rocket-MIMEInfo: 002.001, Pj4gSSBndWVzcyB0aGlzIGFsbCBkZXBlbmRzIG9uIHRoZSBncmFudWxhcml0eSBvZiB0aGUgdGltZXN0YW1wcy4KCgpQaWNvc2Vjb25kcyBpcyB0aGUgZ3JhbnVsYXJpdHkgb2YgdGhlIHRpbWVzdGFtcHMuIMKgIFRoZSB0aW1lc3RhbXAgaXMgTlRQIHN0YW5kYXJkLiDCoAoKPj7CoGhhc2ggZnVuY3Rpb24gb24gdGhlIGhlYWRlcnMuCgpBZ2FpbiwgSSB0ZWxsIHlvdSwgdGhpcyB3aWxsIG5vdCB3b3JrLiDCoE5vdCB0byBtZW50aW9uLCBob3cgZG8geW91IGludGVuZCB0byBkbyBhIHRpbWVzdGFtcCB3aXRoIGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <027F849D-4C37-456D-A0CA-02999902974C@delong.com> <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51ACAE3B.2050907@si6networks.com> Message-ID: <1370271809.43147.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 08:03:29 -0700 (PDT) From: Nalini Elkins To: Fernando Gont In-Reply-To: <51ACAE3B.2050907@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-1411161319-1370271809=:43147" Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:03:37 -0000 --36908767-1411161319-1370271809=:43147 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> I guess this all depends on the granularity of the timestamps.=0A=0A=0AP= icoseconds is the granularity of the timestamps. =A0 The timestamp is NTP s= tandard. =A0=0A=0A>>=A0hash function on the headers.=0A=0AAgain, I tell you= , this will not work. =A0Not to mention, how do you intend to do a timestam= p with hashes?=0A=0A>> are we=A0suppoed to have this ind of functionality a= t the Internet layer=0A=0A=0AI would say that real time performance metrix = and managability are critical for networks. =A0 As the speed of networks gr= ows, and there are more and more critical applications, as well as numerous= devices, without good performance metrix, IMHO growth will be slowed. =A0T= he Internet layer is the perfect place for this.=0A=A0=0AThanks,=0A=0A=0ANa= lini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.c= om=0A=0A=0A=0A________________________________=0A From: Fernando Gont =0ATo: Nalini Elkins = =0ACc: Owen DeLong ; "v6ops@ietf.org" ; "d= raft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" =0ASent: Monday, June 3, 201= 3 7:54 AM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-= end-rt-needed=0A =0A=0AOn 06/03/2013 04:47 PM, Nalini Elkins wrote:=0A>>> I= f it's a false duplication, wouldn't your sequence number also get duplicat= ed and thus be the same, just like the hash?=0A> =0A> Indeed it would.=A0 S= ince we know that the combination of Packet Sequence=0A> Number and Timesta= mp together should never be duplicated, then we are=0A> safe to assume that= such a packet is a false duplicate. =0A> =0A> If the packet seq number wra= ps, then the timestamp will be different.=0A=0AI guess this all depends on = the granularity of the timestamps. That=0Asaid, I personally think that thi= s looks like too much stress on the=0Anetwork and implementations for somet= hing that is not meant for the=0Ageneral Internet, and that can be performe= d, to a large extent, with=0Atechniques such as a hash function on the head= ers.=0A=0AP.S.: Before any attempt on this path, one should probably ask: a= re we=0Asuppoed to have this ind of functionality at the Internet layer? Is= this=0Aworth the pain for most implementations? Is this going to work in t= he=0Ageneral case, or is this going to be the subject of lots fo breakage?= =0A(e.g., packet drops)=0A=0ACheers,=0A-- =0AFernando Gont=0ASI6 Networks= =0Ae-mail: fgont@si6networks.com=0APGP Fingerprint: 6666 31C6 D484 63B2 8FB= 1 E3C4 AE25 0D55 1D4E 7492 --36908767-1411161319-1370271809=:43147 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>> I guess this all depends on the granularity = of the timestamps.

Picoseconds is the g= ranularity of the timestamps.   The timestamp is NTP standard.  <= /div>

>> hash functio= n on the headers.

Again, I tel= l you, this will not work.  Not to mention, how do you intend to do a = timestamp with hashes?

>> are = we suppoed to have this ind of functionality at the Internet layer

I would say that real tim= e performance metrix and managability are critical for networks.   As = the speed of networks grows, and there are more and more critical applicati= ons, as well as numerous devices, without good performance metrix, IMHO gro= wth will be slowed.  The Internet layer is the perfect place for this.
 
Thanks,

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

From: Fernando Gont <fgont@si6networks.com>
To: Nalini Elkins <nalini.elkins@insideth= estack.com>
Cc: Owe= n DeLong <owen@delong.com>; "v6ops@ietf.org" <v6ops@ietf.org>; = "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" <draft-elk= ins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org>
Sent: Monday, June 3, 2013 7:54 AM
<= b>Subject: Re: [v6ops] new draft: dr= aft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0AOn 06/03/2013 04:47 PM, Nalini Elkins wrote:
&g= t;>> If it's a false duplication, wouldn't your sequence number also = get duplicated and thus be the same, just like the hash?
>
> I= ndeed it would.  Since we know that the combination of Packet Sequence=
> Number and Timestamp together should never be duplicated, then we = are
> safe to assume that such a packet is a false duplicate.
>= ;
> If the packet seq number wraps, then the timestamp will be diffe= rent.

I guess this all depends on the granularity of the timestamps.= That
said, I personally think that this looks like too much stress on t= he
network and implementations for something that is not meant for thegeneral Internet, and that can be performed, to a large extent, with
t= echniques such as a hash function on the headers.

P.S.: Before any a= ttempt on this path, one should probably ask: are we
suppoed to have thi= s ind of functionality at the Internet layer? Is this
worth the pain for most im= plementations? Is this going to work in the
general case, or is this goi= ng to be the subject of lots fo breakage?
(e.g., packet drops)

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






--36908767-1411161319-1370271809=:43147-- From bill.jouris@insidethestack.com Mon Jun 3 08:21:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A7821E80A9 for ; Mon, 3 Jun 2013 08:21:36 -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 bhXLjdidReD8 for ; Mon, 3 Jun 2013 08:21:30 -0700 (PDT) Received: from nm7-vm0.access.bullet.mail.sp2.yahoo.com (nm7-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.116]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1C211E80A4 for ; Mon, 3 Jun 2013 08:21:30 -0700 (PDT) Received: from [98.139.44.106] by nm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 15:21:29 -0000 Received: from [98.139.44.89] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 15:21:29 -0000 Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 15:21:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 922742.37510.bm@omp1026.access.mail.sp2.yahoo.com Received: (qmail 80651 invoked by uid 60001); 3 Jun 2013 15:21:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370272889; bh=aPQ1/fr6a56Z3iVVH0HYs4Y9pLSsYGiURcw5+BmEqW8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ZGnAHgTnMRoV4JXfbm29jJrJZ0dXmFK7lYi8yIpSwoBV9oijhYowLiuh+MKhSuarypXljUx5ekyPT3wOcgyMloDZa5EQHczv0FWBwO++3h4dl678Ue2UWoiJr92757qZsvJ8s9XfWPPpCh9WQ1m/1Xa/XIsxWPgutCmRhl4buRM= X-YMail-OSG: gNJ7oLcVM1nkzAdfAnpUDA34UZ2MoGTytQfztOg82e1XoRi yMl2xBvdNizUDH4rlOuyvk6iGXru.6f1XOlom88S9SQoOQTXTbbC4Ul3xcFv cnLaLF8uwvEayYotCOeUU1Br2c9pDHUV9D.ld_B3T06HoDJqOYntpYQh2Ouz J38cBfDrfJwbXVmLK.yyFF8C7oVHlR.QoIcnA7aUVynJsC163n2r1uxWfAw5 CMOE9busRhK2os95qLE78LV1obgslNWtWZplKHcFPeHdHi8rnym7Qwgfl.ET w22_PzW1Mw.1JjgOK88VH1pJAMeQx5.aG9EzRNLgnaNKfQLzAlPkb3OgetFo K6goXM6TP733J2MyIoakAXd1Zji7mM1qSBItP_LqjiO5Yxlwdwzrovfnx5Ov 3Krfo201NczVA75VRFYOxInysgBJhRlrtUy0Nk3py1qQrwuVY7taUB83lbp7 BxyHReMLEQzzIZMLTcTDpunkiXb9LqS9sc1gIvHCCFmNLY2hPHPaGyU2jsz7 XJwtsnyDmcVmdTr4t2RUtpSrtJzYvjWMIe_fDQqlwHJarGKRB7_fdZ6kIjeY oxnx2rtCNxHlaRxbyo2LUfdNn9Q7LRTLuek6p2l8c2qkqx9hWp0oLTCTcA8I zMA8Dt4RpqAUP7g-- Received: from [50.148.178.232] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 08:21:28 PDT X-Rocket-MIMEInfo: 002.001, PiBQLlMuOiBCZWZvcmUgYW55IGF0dGVtcHQgb24gdGhpcyBwYXRoLCBvbmUgc2hvdWxkIHByb2JhYmx5IGFzazogYXJlIHdlIA0KPiBzdXBwb2VkIHRvIGhhdmUgdGhpcyBpbmQgb2YgZnVuY3Rpb25hbGl0eSBhdCB0aGUgSW50ZXJuZXQgbGF5ZXI_IElzIHRoaXMgDQo.IHdvcnRoIHRoZSBwYWluIGZvciBtb3N0IGltcGxlbWVudGF0aW9ucz8gSXMgdGhpcyBnb2luZyB0byB3b3JrIGluIHRoZSANCj4gZ2VuZXJhbCBjYXNlLCBvciBpcyB0aGlzIGdvaW5nIHRvIGJlIHRoZSBzdWJqZWN0IG9mIGxvdHMgZm8gYnIBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.145.547 Message-ID: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 08:21:28 -0700 (PDT) From: Bill Jouris To: "v6ops@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-169621511-1370272888=:80189" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:21:37 -0000 --1619178251-169621511-1370272888=:80189 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > P.S.: Before any attempt on this path, one should probably ask: are we=20 > suppoed to have this ind of functionality at the Internet layer? Is this= =20 > worth the pain for most implementations? Is this going to work in the=20 > general case, or is this going to be the subject of lots fo breakage?=20 > (e.g., packet drops) Fernando, the problem with using any other layer is that it would require i= mplementation across ALL of the various protocols.=A0 Which is far more dis= ruptive than this implementation in the IP layer would be.=20 Also, I'm not sure what kind of breakage you anticipate.=A0 Is it that you = think that there would be a problem processing the IP layer due to the addi= tional option?=A0 (And if so, why this option more than any of the existing= ones?)=A0 Or are you thinking that the option header itself would break wh= en being processed? Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --1619178251-169621511-1370272888=:80189 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> P.S.: Before any attempt on this path, o= ne should probably ask: are we
> suppoed to have this ind of functio= nality at the Internet layer? Is this
> worth the pain for most impl= ementations? Is this going to work in the
> general case, or is this= going to be the subject of lots fo breakage?
> (e.g., packet drops)=

Fernando, the problem with using any other layer is that it would r= equire implementation across ALL of the various protocols.  Which is f= ar more disruptive than this implementation in the IP layer would be.
<= br>Also, I'm not sure what kind of breakage you anticipate.  Is it tha= t you think that there would be a problem processing the IP layer due to th= e additional option?  (And if so, why this option more than any of the= existing ones?)  Or are you thinking that the option header itself wo= uld break when being processed?

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

--1619178251-169621511-1370272888=:80189-- From sander@steffann.nl Mon Jun 3 08:51:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 randy@psg.com Mon Jun 3 09:19:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F4D21F8F6E for ; Mon, 3 Jun 2013 09:19: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 pY0kzMpZ1Ykc for ; Mon, 3 Jun 2013 09:19:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 29D9721F8EF2 for ; Mon, 3 Jun 2013 09:19: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 1UjXU2-000JPP-0t; Mon, 03 Jun 2013 16:19:46 +0000 Date: Mon, 03 Jun 2013 11:19:45 -0500 Message-ID: From: Randy Bush To: Nalini Elkins In-Reply-To: <1370271809.43147.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <027F849D-4C37-456D-A0CA-02999902974C@delong.com> <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51ACAE3B.2050907@si6networks.com> <1370271809.43147.YahooMailNeo@web2801.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 Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:19:48 -0000 > Picoseconds is the granularity of the timestamps. i would be amazed if you had time measurements with a precision within a factor of O(10^6) of that A gentleman accosts a guard in the museum and asks, "How old is that mummy?" The guard responds, "I believe it is 2005 years old." The gentleman asks "Why that particular age, 2005?" The guard responds "Well, I was told it was 2000 years old when I started work here five years ago." randy From nalini.elkins@insidethestack.com Mon Jun 3 09:23:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5813821F9412 for ; Mon, 3 Jun 2013 09:23:10 -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.120, 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 DezCnaI4Hsce for ; Mon, 3 Jun 2013 09:23:04 -0700 (PDT) Received: from nm3.access.bullet.mail.sp2.yahoo.com (nm3.access.bullet.mail.sp2.yahoo.com [98.139.44.130]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8A21F8FBE for ; Mon, 3 Jun 2013 09:23:03 -0700 (PDT) Received: from [98.139.44.99] by nm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 16:23:02 -0000 Received: from [98.139.44.92] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 16:23:02 -0000 Received: from [127.0.0.1] by omp1029.access.mail.sp2.yahoo.com with NNFMP; 03 Jun 2013 16:23:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 53435.51748.bm@omp1029.access.mail.sp2.yahoo.com Received: (qmail 61760 invoked by uid 60001); 3 Jun 2013 16:23:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370276581; bh=8W6FG/wWqGlaN09AItSgR5SqCSU4zJPOeDKfajY7vpM=; 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=EIbr2oIcbegILFAFgWXJr0zDQ7KMa7u/37GLNAsTsGDUlFyVbmFdfu3TQiFTOocx9ykybZj4fI1fZz/79xAFH8wt92K71Gq8lTzr4Ri1Mb3BlVL1dCX/+Io1h8N9GO7KGki3PWSWEX6CbPm5/uSFpiWCvqzg70o7hprWefCoKUM= X-YMail-OSG: JTYNjXQVM1lqaAyuU4fdhz4XGFMeMbr16rTHQj_vJk3j0y4 hERrl8aKZzGEP431y9VbUdoy1fQKqecsw295jS2v35NbLfFtuI1NO7Iji1Ih Bk3e9OqRowBR0O493h42AYGUNPFetKzQ4rLzad5908Rlm2fekOdCcW8lSV4u Dvfg7pYqT5gFVDwzJQvdCvnkq44alH8K.TRcYgD4jaqzXn2zU54qSPM8cg_q 7D2.0vfNVTcza_LzHUjzHeifre7ceEvrqCZAFvM0iOmOdXTQSlgYL33dEgv8 TsFVQUdixtVFrUK97v3uWPJnVgddFhAwqrgEJIptcNYbIkdZUhUtO3bed8XH IzAmF6JNHe0gSV6TjwqFuku3osS9nkroREaZjadkEU99HNjgYNUffl31sHFp cAQBAirmTKcoKpm3JbCKcbC.UuZfiXqTBL8K5VTISjn552cyUd40PyDTRGdX OtLGpRyN._Ys4CQl81PWyoiuXZBOJWlCOdFxUNxiCfMN3FTmhdI.rhUKYnNI y4FGAMUoDOjZXSpNHOh9GDaRe3NvUmq.DLUK_a7LHn2kOapN54yEc6X08ICN J20WTBG36Wy2ZT50vIF1BSs1dRv4.ZHZ2pYZrvyK7Pik6cMgWWQ829obp8ha 0y.KWh_JHpoRCsdwW9VnBtShxjCE- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 09:23:01 PDT X-Rocket-MIMEInfo: 002.001, SEFIQUhBCgpGcm9tIFJGQzU5MDU6IE5ldHdvcmsgVGltZSBQcm90b2NvbCBWZXJzaW9uIDQ6IFByb3RvY29sIGFuZCBBbGdvcml0aG1zIFNwZWNpZmljYXRpb24KClRoZSA2NC1iaXQgdGltZXN0YW1wIGZvcm1hdCBpcyB1c2VkIGluIHBhY2tldCBoZWFkZXJzIGFuZCBvdGhlcgpwbGFjZXMgd2l0aCBsaW1pdGVkIHdvcmQgc2l6ZS4gIEl0IGluY2x1ZGVzIGEgMzItYml0IHVuc2lnbmVkIHNlY29uZHMKZmllbGQgc3Bhbm5pbmcgMTM2IHllYXJzIGFuZCBhIDMyLWJpdCBmcmFjdGlvbiBmaWVsZCByZXNvbHZpbmcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <027F849D-4C37-456D-A0CA-02999902974C@delong.com> <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51ACAE3B.2050907@si6networks.com> <1370271809.43147.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Message-ID: <1370276581.60631.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 09:23:01 -0700 (PDT) From: Nalini Elkins To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-1661978418-1370276581=:60631" Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:23:10 -0000 ---153701192-1661978418-1370276581=:60631 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable HAHAHA=0A=0AFrom RFC5905: Network Time Protocol Version 4: Protocol and Alg= orithms Specification=0A=0AThe 64-bit timestamp format is used in packet he= aders and other=0Aplaces with limited word size. It includes a 32-bit unsi= gned seconds=0Afield spanning 136 years and a 32-bit fraction field resolvi= ng 232=0Apicoseconds. The 32-bit short format is used in delay and dispers= ion=0Aheader fields where the full resolution and range of the other=0Aform= ats are not justified. It includes a 16-bit unsigned seconds=0Afield and a= 16-bit fraction field.=0A=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside P= roducts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A________= ________________________=0A From: Randy Bush =0ATo: Nalini E= lkins =0ACc: IPv6 Ops WG =0ASent: Monday, June 3, 2013 9:19 AM=0ASubject: Re: [v6ops] new draft: d= raft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A> Picoseconds is the g= ranularity of the timestamps.=0A=0Ai would be amazed if you had time measur= ements with a precision within=0Aa factor of O(10^6) of that=0A=0AA gentlem= an accosts a guard in the museum and asks, "How old is that mummy?"=0AThe g= uard responds, "I believe it is 2005 years old."=0AThe gentleman asks "Why = that particular age, 2005?"=0AThe guard responds "Well, I was told it was 2= 000 years old when I=0Astarted work here five years ago."=0A=0Arandy ---153701192-1661978418-1370276581=:60631 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 
HAHAHA

From RFC5905: Network Time Protocol Version 4: Protocol and =
Algorithms Specification
=

The 64-bit timestamp format=
 is used in
 packet headers and other=0Aplaces with limited word size.  It includes a 3=
2-bit unsigned seconds=0Afield spanning 136 years and a 32-bit fraction fie=
ld resolving 232=0Apicoseconds.  The 32-bit short format is used in delay a=
nd dispersion=0Aheader fields where the full resolution and range of the ot=
her=0Aformats are not justified.  It includes a 16-bit unsigned seconds=0Af=
ield and a 16-bit fraction field.
 
 
 
   From: Randy Bush <randy@psg.com>
 Cc: IPv6 Ops WG <v6ops=
@ietf.org> 
 Sent: M=
onday, June 3, 2013 9:19 AM
 Subje=
ct: Re:
 [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed
  
 

=0A> Picoseconds is the gran=
ularity of the timestamps.

i would be amazed if you had time measure=
ments with a precision within
a factor of O(10^6) of that

A gentl=
eman accosts a guard in the museum and asks, "How old is that mummy?"
Th=
e guard responds, "I believe it is 2005 years old."
The gentleman asks "=
Why that particular age, 2005?"
The guard responds "Well, I was told it =
was 2000 years old when I
started work here five years ago."

rand=
y
---153701192-1661978418-1370276581=:60631-- From bmanning@isi.edu Mon Jun 3 08:45:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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 X-Mailman-Approved-At: Mon, 03 Jun 2013 09:42:21 -0700 Cc: "v6ops@ietf.org WG" , ipv6@ietf.org Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 bmanning@isi.edu Mon Jun 3 09:12:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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 X-Mailman-Approved-At: Mon, 03 Jun 2013 09:42:21 -0700 Cc: "v6ops@ietf.org WG" , ipv6@ietf.org Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 owen@delong.com Mon Jun 3 10:59:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F62521F8F6E for ; Mon, 3 Jun 2013 10:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9p56VE80XbG for ; Mon, 3 Jun 2013 10:59: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 B4A4E21F86CE for ; Mon, 3 Jun 2013 10:58:32 -0700 (PDT) Received: from [192.168.1.31] (rrcs-67-79-199-246.sw.biz.rr.com [67.79.199.246]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r53HuiJA016802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 10:56:46 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53HuiJA016802 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370282208; bh=UxUYRm/t42afS+7htBdAjeqt3wU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=p87/9a+VkMHNOY5Qltv9CHqqDehtzevDEVWioz0kyQcH121sphnO2oO/9BKCs+i4k YROZVf3b37EDnfKjMcRf91FXBiBjnMQf5ZBq4pFANTTdExlbhs5PFRP7txM6hZ/aCq 0/ISXevdCgsEptyNewFOYVD16JsxIaO8LcfkQmEk= Content-Type: multipart/alternative; boundary="Apple-Mail=_3EBC879A-BDAB-45E6-A38E-FAFCACB92007" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <1370276581.60631.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 12:56:46 -0500 Message-Id: <1D019454-683B-4715-A2D3-298BE917D3C1@delong.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <027F849D-4C37-456D-A0CA-02999902974C@delong.com> <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51ACAE3B.2050907@si6networks.com> <1370271809.43147.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <1370276581.60631.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> To: Nalini Elkins 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 10:56:48 -0700 (PDT) Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:59:46 -0000 --Apple-Mail=_3EBC879A-BDAB-45E6-A38E-FAFCACB92007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 You are mistaking precision for accuracy. Let me attempt to explain the difference. It is not uncommon for digital temperature sensors to provide 0.001 = degrees C of precision. Most of them are not accurate to less than 0.1=BAC. Just because you get three decimal places in the number doesn't mean = that the contents of those decimal places are inherently correct. Owen On Jun 3, 2013, at 11:23 AM, Nalini Elkins = wrote: > HAHAHA >=20 > =46rom RFC5905: Network Time Protocol Version 4: Protocol and = Algorithms Specification >=20 > The 64-bit timestamp format is used in > packet headers and other > places with limited word size. It includes a 32-bit unsigned seconds > field spanning 136 years and a 32-bit fraction field resolving 232 > picoseconds. The 32-bit short format is used in delay and dispersion > header fields where the full resolution and range of the other > formats are not justified. It includes a 16-bit unsigned seconds > field and a 16-bit fraction field. >=20 > =20 > Thanks, >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com >=20 > From: Randy Bush > To: Nalini Elkins =20 > Cc: IPv6 Ops WG =20 > Sent: Monday, June 3, 2013 9:19 AM > Subject: Re: [v6ops] new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed >=20 > > Picoseconds is the granularity of the timestamps. >=20 > i would be amazed if you had time measurements with a precision within > a factor of O(10^6) of that >=20 > A gentleman accosts a guard in the museum and asks, "How old is that = mummy?" > The guard responds, "I believe it is 2005 years old." > The gentleman asks "Why that particular age, 2005?" > The guard responds "Well, I was told it was 2000 years old when I > started work here five years ago." >=20 > randy >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_3EBC879A-BDAB-45E6-A38E-FAFCACB92007 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 You = are mistaking precision for accuracy.

Let me attempt = to explain the difference.

It is not uncommon = for digital temperature sensors to provide 0.001 degrees C of = precision.

Most of them are not accurate to = less than 0.1=BAC.

Just because you get three = decimal places in the number doesn't mean that the contents of those = decimal places are inherently = correct.

Owen

On Jun 3, = 2013, at 11:23 AM, Nalini Elkins <nalini.elkins@insidethest= ack.com> wrote:

HAHAHA

=46rom RFC5905: Network Time Protocol =
Version 4: Protocol and Algorithms Specification

The 64-bit timestamp =
format is used in
 packet headers and other
places with limited word size.  It includes a 32-bit unsigned seconds
field spanning 136 years and a 32-bit fraction field resolving 232
picoseconds.  The 32-bit short format is used in delay and dispersion
header fields where the full resolution and range of the other
formats are not justified.  It includes a 16-bit unsigned seconds
field and a 16-bit fraction field.

 
Thanks,

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

=
From: Randy Bush = <randy@psg.com>
To: Nalini Elkins = <nalini.elkins@insidethestack.com>
Cc: IPv6 Ops WG = <v6ops@ietf.org>
Sent: Monday, June 3, 2013 9:19 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed
=

> Picoseconds is the granularity of the timestamps.

i would be = amazed if you had time measurements with a precision within
a factor = of O(10^6) of that

A gentleman accosts a guard in the museum and = asks, "How old is that mummy?"
The guard responds, "I believe it is = 2005 years old."
The gentleman asks "Why that particular age, = 2005?"
The guard responds "Well, I was told it was 2000 years old = when I
started work here five years = ago."

randy


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

= --Apple-Mail=_3EBC879A-BDAB-45E6-A38E-FAFCACB92007-- From touch@isi.edu Mon Jun 3 11:22:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0DE21F8900 for ; Mon, 3 Jun 2013 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.800, 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 v5ECJXw08xwY for ; Mon, 3 Jun 2013 11:22:10 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7C54E21F8A74 for ; Mon, 3 Jun 2013 11:20:42 -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 r53IKAiN028359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 11:20:10 -0700 (PDT) Message-ID: <51ACDE55.1070609@isi.edu> Date: Mon, 03 Jun 2013 11:20:05 -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: Owen DeLong References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51ACA737.6060406@si6networks.com> <1370270060.78252.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <027F849D-4C37-456D-A0CA-02999902974C@delong.com> <1370270825.46784.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51ACAE3B.2050907@si6networks.com> <1370271809.43147.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <1370276581.60631.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1D019454-683B-4715-A2D3-298BE917D3C1@delong.com> In-Reply-To: <1D019454-683B-4715-A2D3-298BE917D3C1@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:22:25 -0000 Precision = repeatability. Accuracy = matching a value deemed correct by an external measure. The utility of the bits you measure depends on what you want to do with them: - Precision without accuracy can be corrected to include accuracy if measured against a separate measure that is both accurate and precise. - Precision without accuracy can be used to correctly measure relative shifts. - Accuracy without precision is useless. In the context of this discussion, reporting values down to the picosecond is probably meaningless in terms of accuracy, but not necessarily in terms of precision. And both are useful for NTP. Joe On 6/3/2013 10:56 AM, Owen DeLong wrote: > You are mistaking precision for accuracy. > > Let me attempt to explain the difference. > > It is not uncommon for digital temperature sensors to provide 0.001 > degrees C of precision. > > Most of them are not accurate to less than 0.1ºC. > > Just because you get three decimal places in the number doesn't mean > that the contents of those decimal places are inherently correct. > > Owen > > On Jun 3, 2013, at 11:23 AM, Nalini Elkins > > wrote: > >> HAHAHA >> >> From RFC5905:Network Time Protocol Version 4: Protocol and Algorithms Specification >> >> The 64-bit timestamp format is used in >> packet headers and other >> places with limited word size. It includes a 32-bit unsigned seconds >> field spanning 136 years and a 32-bit fraction field resolving 232 >> picoseconds. The 32-bit short format is used in delay and dispersion >> header fields where the full resolution and range of the other >> formats are not justified. It includes a 16-bit unsigned seconds >> field and a 16-bit fraction field. >> >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> ------------------------------------------------------------------------ >> *From:* Randy Bush >> *To:* Nalini Elkins >> *Cc:* IPv6 Ops WG >> *Sent:* Monday, June 3, 2013 9:19 AM >> *Subject:* Re: [v6ops] new draft: >> draft-elkins-v6ops-ipv6-end-to-end-rt-needed >> >> > Picoseconds is the granularity of the timestamps. >> >> i would be amazed if you had time measurements with a precision within >> a factor of O(10^6) of that >> >> A gentleman accosts a guard in the museum and asks, "How old is that >> mummy?" >> The guard responds, "I believe it is 2005 years old." >> The gentleman asks "Why that particular age, 2005?" >> The guard responds "Well, I was told it was 2000 years old when I >> started work here five years ago." >> >> randy >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From albert.e.manfredi@boeing.com Mon Jun 3 12:23:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 brian.e.carpenter@gmail.com Mon Jun 3 13:36:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0423821E80C6 for ; Mon, 3 Jun 2013 14:21:38 -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 etuXfEbDODLs for ; Mon, 3 Jun 2013 14:21:22 -0700 (PDT) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with ESMTP id 292E121F86F5 for ; Mon, 3 Jun 2013 14:16:18 -0700 (PDT) Received: from [98.139.212.146] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:16:17 -0000 Received: from [98.139.212.228] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:16:17 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:16:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 685881.17938.bm@omp1037.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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:21:40 -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 markzzzsmith@yahoo.com.au Mon Jun 3 14:38:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5627911E8117 for ; Mon, 3 Jun 2013 14:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=0.867, 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 KPZ53NTYuinM for ; Mon, 3 Jun 2013 14:37:46 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2DA21F94BA for ; Mon, 3 Jun 2013 14:33:22 -0700 (PDT) Received: from [98.139.215.141] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:33:21 -0000 Received: from [98.139.212.214] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:33:21 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:33:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 739647.83679.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 25523 invoked by uid 60001); 3 Jun 2013 21:33:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1370295201; bh=OM0nRe8rHITC0nBxzFN/XMPfnSKWI9BUlH3AQULGPyM=; 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=VqfzvR4ZoTQQpGWblJBkFKT/vL49P3uu7P/0J53dzZWrtxrr6S0GQ9pgTfwhdSXKrCma1KK8hr+V3Ed26YzqkMmUY9iJOfpCdaA6IzP1PiqypC1ZMSvD6qViBGCkGYpKQU/rIBshn9D5nPdJReqM7HsIBmGSmX7QIzoRiaiBsGw= 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=ErTG10JPiZ5HJydpW23oPPr1YhAF35MBvm93/6p773wHQ1pxV93hw0O7BGjCI/idS65nekPqksB2vsphBiNO881UKxdroH7Ml7dbNrgNKWaPay/Rt0Bf07BgHzuO46qsMqPboo8ix4+V/IzMLsefJAevjo5M6qtV4driypEoZRQ=; X-YMail-OSG: H5wauCsVM1nmPvwWSMUPjJr23_caFZxsutdbmbtnKXsYxtz j_fNzvIv_GKy7xgXX6uwaqffUlvEFKV7kwsNYe4YRpFsejc9Wl5ej1hoPc_C W7aeguhm93Ns1G32j26DlRMNKeXyoXzKEGbVVRuDer4MgCc_TabOEWfmclhg OXEwj6wwxN5QL475n8AXZWb5JFGO.uxmOJ81haagyeD9qPoKydEs6fLmeeim i6.VrDmIrLQqIBN_XZ5btDzqjz6laf6NyvU9NxUQawaCjK22cHZ4kH0LjK5_ WJ82dN2wGY3oWkXeMsEgg7I7836zF1zz4601Q_0t7QfAxy1jyKQuif2hJZmN gInjzGnIv69l7.yOhglWL2x_JZWwVtCmCPFeN4bGRSnBXxNRWmDfiOtvae10 biMoSpmsqwBwq0PV3eR_DHglcfhxYKYVAab4yiiMkDHlFbzR622hg8nd36f_ nZcsgvhedKpjqjEFvW5L5kl_tWe8dsil6Q8NffUTsMGWOjRtjPXkUhwFgLro 3XcML0DWC6gaAh4D4eZV29vBC7LTZOqDRlOcolzt.6USYHPR02DaK5OQlnPs ibWD8dbTSgA-- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Mon, 03 Jun 2013 14:33:20 PDT X-Rocket-MIMEInfo: 002.001, Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IE5hbGluaSBFbGtpbnMgPG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPgo.VG86IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPiAKPkNjOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.OyAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1lbmQtdG8tZW5kLXJ0LW5lZWRlZEB0b29scy5pZXRmLm9yZyIgPGRyYWZ0LWVsa2lucy0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370269844.30551.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Message-ID: <1370295200.19858.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Mon, 3 Jun 2013 14:33:20 -0700 (PDT) From: Mark Smith To: Nalini Elkins , Lorenzo Colitti In-Reply-To: <1370269844.30551.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:38:02 -0000 =0A>________________________________=0A> From: Nalini Elkins =0A>To: Lorenzo Colitti =0A>Cc: Fe= rnando Gont ; "v6ops@ietf.org" ; "dr= aft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" =0A>Sent: Tuesday, 4 June 201= 3 12:30 AM=0A>Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-t= o-end-rt-needed=0A> =0A>=0A>=0A>>>I'm afraid that that is known as the "kil= ler app" fallacy. I say "fallacy" instead of "argument" because such argume= nts have been tried many times but have not been very successful to date. I= don't think it will be very convincing - especially since these=0A>>>compa= nies already have what they need from IPv4, right?=0A>=0A>=0A>Possibly you = are right but given that the execs in question asked me about budget for IP= v6, I would suspect that you are wrong. =A0You underestimate how much compa= nies spend on agents for gathering response time data which is required for= Service Level Agreements. =A0AND how attractive it is to NOT have to do th= at. =A0This extension header provides them capabilities they do NOT have wi= th IPv4.=0A>=0A=0ACan you explain this further? Where are these agents loca= ted - on hosts, on routers or as separate probes? Where is the big cost in = gathering this data, given that storage and processing power are cheap (and= we're starting to be in an era of "big data", so tools to handle large amo= unts of data are becoming more available)? How does your proposed IPv6 exte= nsion header eliminate the need to perform measurement, collection and anal= ysis of SLA data?=0A=0AAs a random idea, would agents in the hosts that tri= gger SNMP traps when there are TCP duplicate segments or out of order deliv= ery solve the issue? It wouldn't work with UDP as UDP doesn't support detec= ting or recovering from these things, and they'd have to be detected at lay= ers above UDP e.g. with RTP as Dan Wing mentioned.=0A=0AIn other words, bet= ter instrumenting hosts to detect and report these faults based on informat= ion they're already collecting for other reasons might be better than tryin= g to develop and deploy a new IPv6 extension header.=A0=0A=0A>=0A=0A>>> Als= o - supposing you do implement an extension header - how will the host know= whether to use it or not? If it uses it to talk to the Internet, then the = packet will get dropped. Does the host know which destinations understand i= t and which do not? Or will=0A>>>you be forced to specify and implement str= ipping this header in intermediate nodes?=0A>=0A>=0A>Now this is a better p= oint. =A0But, there is a bigger issue here. =A0The companies and agencies t= hat I work with on implementing IPv6, already need to plan for how to diffe= rentiate between internal traffic or traffic to business partners vs. traff= ic to the Internet. =A0 Some alternatives used are Internet proxies, a sepa= rate prefix for Internet traffic vs. trusted traffic etc. =A0This is just o= ne more issue that needs to be dealt with. =A0That is, on such routes or to= such destinations, we do not use this header.=0A>=0A=0AThis sounds like mu= lti-lever security, and Common Architecture Label IPv6 Security Option (CAL= IPSO) (RFC5570) might be the answer.=0A=0A=A0=0ARegards,=0AMark. From joelja@bogus.com Mon Jun 3 16:09:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 16:00:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Andrew McGregor To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0149397a872a6804de47e94e X-Mailman-Approved-At: Mon, 03 Jun 2013 16:22:36 -0700 Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 shengjiang@gmail.com Mon Jun 3 18:37:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=089e0158c2acb408fd04de499730 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: Sheng Jiang To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8f83a6590b7d7804de499b10 Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: Sheng Jiang To: "Bless, Roland (TM)" Content-Type: multipart/alternative; boundary=001a11c34204a55cc004de49c890 Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 18:56:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42F511E8103 for ; Mon, 3 Jun 2013 18:56:10 -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 56rcobNsh53y for ; Mon, 3 Jun 2013 18:56:01 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9068521F9798 for ; Mon, 3 Jun 2013 18:24:31 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gw10so1674801lab.16 for ; Mon, 03 Jun 2013 18:24:30 -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=p7EMQEh4EfNP55da+YnT9S75UMkhY3XlugmVjCO/neI=; b=he+SfiPC71QXzmQgv5UPi1UHiB1v74xl08H38QBfdKthSgiFy535+ABdg/gutjn1fG GLtUrCxc0aBW3RjvR/FEkHlQVBe8UKqTlXlTlqdcjmx9rEGx98GnrWkoPfbaQzkxSGxX Tj9T1RKt5ORkYU2vzc7Rim6hMQQhlZU6KTHMm7IupazaTpZvwPyO7HNDdqTczO+o8HmR nS6bTQ+/bfqvnjC23LFxsvlSXziXHxtPThxUUpcsZPwjdw6DtnFcdQhvdXyquP0nLzJ6 45dXv5XxPiMDJXrjMKcIuJrRYMIPqP2vCkVwZAriLQ+S5z8wl53tbHzgjSJCmhpqmrFy 9oug== MIME-Version: 1.0 X-Received: by 10.112.181.130 with SMTP id dw2mr11191019lbc.81.1370309070409; Mon, 03 Jun 2013 18:24:30 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 18:24:29 -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> Date: Tue, 4 Jun 2013 09:24:29 +0800 Message-ID: From: Sheng Jiang To: trejrco@gmail.com Content-Type: multipart/alternative; boundary=001a11c36c5a5fd37b04de49f13d Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:56:11 -0000 --001a11c36c5a5fd37b04de49f13d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, TJ, No one trying to standardizing the overload-semantics at the ISP level. We all think it is a bad idea to make any global semantics. It is only an observation that ISPs give semantics in their own network. The semantics does not cross the boundary of the ISP domain. Sheng On 3 June 2013 22:53, TJ wrote: > > On Mon, Jun 3, 2013 at 10: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 consume= r >> 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 steal= ing >> 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 networki= ng. >> 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 th= ink >> are valid. What we should be talking about is not whether they can do >> these experiments, but why they are doing them. >> > > > Perhaps the biggest difference is one point of view is proposing taking > those bits now and making them special, while the other keeps them > available for future uses. That is, looking more to future flexibility v= s. > using them in the here and now. Not saying either PoV is right or wrong, > just making an observation. > > Well, that and voicing a vote against standardizing the overload-semantic= s > at the ISP level in this way. > Other ways/reasons may sway me, but these do not ... > > > /TJ *<-- willing to settle for a /56 if it gets us one mental hurdle > closer to more widespread deployment ...* > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --001a11c36c5a5fd37b04de49f13d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, TJ,
=C2=A0
No one trying to s= tandardizing the overload-semantics at the ISP level. We all think it is a = bad idea to make any global semantics. It is only an observation that ISPs = give semantics in their own network. The semantics does not cross the bound= ary of the ISP domain.
=C2=A0
Sheng


<= div class=3D"gmail_quote">On 3 June 2013 22:53, TJ <trejrco@gmail.com&= gt; wrote:

On Mon, Jun 3, 2013 at 10:22 AM, Ted Lemon <= Ted.Lemon@nominu= m.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.


Perhaps the biggest differen= ce is one point of view is proposing taking those bits now and making them = special, while the other keeps them available for future uses. =C2=A0That i= s, looking more to future flexibility vs. using them in the here and now. = =C2=A0Not saying either PoV is right or wrong, just making an observation. = =C2=A0

Well, that and voicing a vote against standardizing the overload-semant= ics at the ISP level in this way. =C2=A0
Other ways/reasons may s= way me, but these do not ...=C2=A0


= /TJ <-- willing to settle for a /56 if it gets us one mental hurdle c= loser to more widespread deployment ...
=C2=A0

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




--
Sheng Jiang =E8=92= =8B=E8=83=9C --001a11c36c5a5fd37b04de49f13d-- From shengjiang@gmail.com Mon Jun 3 19:01:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7bf0c5be8fa9b204de4a04a1 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 02:01:33 -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:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A2F21E80CC for ; Mon, 3 Jun 2013 19:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 Jz78slUoqpIi for ; Mon, 3 Jun 2013 19:23:17 -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 B9E2711E817C for ; Mon, 3 Jun 2013 18:44:57 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id f6so299941qej.23 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=oLVm0s67jkWCn3+fssdoTWjBM0874ad2yxEU52/60xkZhmWpvwrLyqsSuByvPO5fVg fBc3oS9JaPOF2Vhr6rYopl61azKz3ZoqwNMccVr0wYPJBmiinUU0bHRcXsNQG+izN5SM qEqfuoVaSVKtI6oBawYa8YZDcz3T+Flqn6o6gkerXaMoay4XT7kxz7pmM+kW+dPHJ777 fv+ARTuV8Ci3vDeI7hkUI9V/uH43DCvz+Mcs7vsGWtbm+0HU2BhwpVCHxli130Wm4per LMdCOgmAN1R69/NKdq9lBl2RNgQ5XsGCTtbQf4x+cvQmcvFUy/NLmJMXFpvAD7Xa6p7M 26rA== 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: To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= Content-Type: multipart/alternative; boundary=00235452fd9c7d39c904de4a3a17 X-Gm-Message-State: ALoCoQmrS+VaLx/iS8GBoqjsB3UoEwfRZdSZmdZhSLfF8fm7U/0vWkpWeDgDf8NQlDRTDHdHgj1tkJ3PcI7IBHwD396cVOeyjs2q5L/SjcFK6lpcbMTeeifv7axSFqGfxJkWcR3h+OjX4L37or8U2C3Ru9o1XvEKhAuV+nvg5T0WtsLTuKyxonV2uYJgeV8FZrESiA1m2fNd Cc: "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 02:23:38 -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 nalini.elkins@insidethestack.com Mon Jun 3 19:24:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1944C21E80F2 for ; Mon, 3 Jun 2013 19:24:55 -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.109, 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 ELf1b4X4KUw4 for ; Mon, 3 Jun 2013 19:24:35 -0700 (PDT) Received: from nm11-vm0.access.bullet.mail.sp2.yahoo.com (nm11-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.124]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9D211E8183 for ; Mon, 3 Jun 2013 18:45:41 -0700 (PDT) Received: from [98.139.44.104] by nm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jun 2013 01:45:34 -0000 Received: from [98.139.44.84] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jun 2013 01:45:34 -0000 Received: from [127.0.0.1] by omp1021.access.mail.sp2.yahoo.com with NNFMP; 04 Jun 2013 01:45:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 810873.81035.bm@omp1021.access.mail.sp2.yahoo.com Received: (qmail 43855 invoked by uid 60001); 4 Jun 2013 01:45:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370310333; bh=ibLB+0R7Rj++FNLYF4JieJ0ng/eBo43DUwADtzNYrXk=; 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=XROlwfqj48g0CNpH0RkKEvm9XArQHn/R9TMatdRrHxWjsl51K8tCaQewjLQNIEZTcs+jc1V9Gr2crXHxN/cJC0/mYf6vygKBB1Gl/xYAvwyHbfPO1EVNQ5bXpH5M/xi/JS+orDJgoFEdtaHQE0rcdiGV21hYHrnsrZqI57hk6kw= X-YMail-OSG: ICX8VloVM1l5NpFoJo25WGccGuZAXtrcnu3qJFMxZ66gQ9N uNjy6Wy9bxswhQtTqn4cEB2z0ihOM2CsyDoLddsLQ4cHVxzdZvk1a0pVTLI1 TwHNap84IBnSwe7WnNpkyGz0nDyjqwpOwRr7aYF2n_mDxqPBUNSfRlVRlC9z B9uvgY1WhU3Phl278uytRIC3DEFEiZJ5CkTuD9..EPFKSSaoGar8EsIHBYCf YRB.VPGAbqXSi3eMXWskH1oy_qPwGp2EyxmT3JkralWMqVRJUy.fsk3kF_I2 bhRNwoBPM1w7KJZBWBQOxuZJubEl1Tt4UUa2_BVCA9mLtsW_HA7FErYfQE.v fP51QD8oxvmFbYoKQ7iKUuf0ksqCMKEwntK2pjn0p7qMHYv.6XauxqNBnaUi 5fb66J_LjdFMETbjWbzhD.9MJ.yi3DGwvKhlugl_Sy64OCzqWarphyqTAkpb vORTB3PfykV.3_sOEJWho1iORLoYvTmKP011rwwWFIFSiI.nb5bgqWZRnPWF J.tQPiBRsw6WBbLMQGHCumuvIyG9ceBETcoERisW18PpuEDSS034sKn2lRVt QlvLcA03we44BSJHVMkIM8ziVwD_WMqQ897HoEtzqsAX.C6.6Jz3MLirHrRS DzdeJ52A8V42lBfNcvSpbFLHn Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 18:45:33 PDT X-Rocket-MIMEInfo: 002.001, Cgo.PkNhbiB5b3UgZXhwbGFpbiB0aGlzIGZ1cnRoZXI_IFdoZXJlIGFyZSB0aGVzZSBhZ2VudHMgbG9jYXRlZCAtIG9uIGhvc3RzLCBvbiByb3V0ZXJzIG9yIGFzIHNlcGFyYXRlIHByb2Jlcz_CoAoKT2Z0ZW4gYWdlbnRzIGFyZSBsb2NhdGVkIGF0IHRoZSBlbmQgwqB1c2VyIGRldmljZS7CoAoKPj7CoFdoZXJlIGlzIHRoZSBiaWcgY29zdCBpbiBnYXRoZXJpbmcgdGhpcyBkYXRhLCBnaXZlbiB0aGF0IHN0b3JhZ2UgYW5kIHByb2Nlc3NpbmcgcG93ZXIgYXJlIGNoZWFwIChhbmQgd2UncmUgc3RhcnRpbmcgdG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370269844.30551.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <1370295200.19858.YahooMailNeo@web142503.mail.bf1.yahoo.com> Message-ID: <1370310333.42116.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 18:45:33 -0700 (PDT) From: Nalini Elkins To: Mark Smith , Lorenzo Colitti In-Reply-To: <1370295200.19858.YahooMailNeo@web142503.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-92495964-1370310333=:42116" Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 02:24:55 -0000 --1510626085-92495964-1370310333=:42116 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A>>Can you explain this further? Where are these agents located - on h= osts, on routers or as separate probes?=A0=0A=0AOften agents are located at= the end =A0user device.=A0=0A=0A>>=A0Where is the big cost in gathering th= is data, given that storage and processing power are cheap (and we're start= ing to be in an era of "big data", so tools to handle large amounts of data= are becoming more available)?=A0=0A=0AThis is a question better asked of t= he vendors of such agents. =A0 Presumably, they feel that the coordination = of agents to a gathering point at a central location as well as the time an= d effort spent in developing agent code is worth paying for. =A0 Cost and p= rice are two different things. =A0The price charged is what the market will= bear.=0A=0A>>=A0How does your proposed IPv6 extension header eliminate the= need to perform measurement, collection and analysis of SLA data?=0A=0ALet= me give you a simple scenario:=0A=0A1. =A0Packet a is sent from source hos= t a. =A0It is timestamped when it leaves host a. =A0The timestamp is in the= proposed PDM extension header.=0A=0A2. =A0A free packet trace tool such as= WireShark sits at a host b server location.=0A=0A3. =A0When packet a reach= es the host b, we know how long the network time was to get from host a to = host b because there is a timestamp. =A0Without a timestamp, there is no wa= y of knowing.=0A=0A4. =A0When host b finishes its processing. =A0It sends p= acket b back to host a. =A0The packet trace tool knows how long the server = time was -- the delta between when the packet was received at host b to whe= n the packet was sent back to host a.=0A=0A5. These times can be used for S= ervice Level Agreements of network time and server times. =A0 =A0=A0=0A=0AY= ou can develop elaborate systems to collect this data, =A0but it simplifies= many things.=0A=0A>>=A0As a random idea, would agents in the hosts that tr= igger SNMP traps when there are TCP duplicate segments or out of order deli= very solve the issue? It wouldn't work with UDP as UDP doesn't support dete= cting or recovering >>from these things, and they'd have to be detected at = layers above UDP e.g. with RTP as Dan Wing mentioned.=0A=0ASeveral question= s arise:=0A=0A1. =A0Who is to code such agents? =A0This is hardly simple co= de. =A0You have to capture all packets and then find duplicates or out of o= rder in real time and then send traps. =A0AND, you have to do all this in a= way that you don't use up all the resources of the host in doing the trace= capture and analysis. =A0Then, you have to send all the data to a central = collection point - reliably.=0A=0A2. =A0The other day, I worked with a devi= ce which was sending a duplicate acknowledgment once every millisecond. =A0= If this host was to send SNMP traps =A0once every millisecond, this would b= e not a very nice situation.=0A=0A>>=A0In other words, better instrumenting= hosts to detect and report these faults based on information they're alrea= dy collecting for other reasons might be better than trying to develop and = deploy a new IPv6 extension header.=A0=0A=0AI beg to differ. =A0I think tha= t the new header is much the easiest way. =A0 Agent architecture is tremend= ously difficult and costly to develop and maintain. =A0In particular as we = go to a more and more mobile world.=0A=0A>>This sounds like multi-lever sec= urity, and Common Architecture Label IPv6 Security Option (CALIPSO) (RFC557= 0) might be the answer.=0A=0A=0AHow this fits into the discussion is someth= ing that you might want to explain more. =A0I am afraid that it is eluding = me.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 6= 59-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______________________________= _=0A From: Mark Smith =0ATo: Nalini Elkins ; Lorenzo Colitti =0ACc: = Fernando Gont ; "v6ops@ietf.org" ; "= draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" =0ASent: Monday, June 3, 20= 13 2:33 PM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to= -end-rt-needed=0A =0A=0A=0A>________________________________=0A> From: Nali= ni Elkins =0A>To: Lorenzo Colitti =0A>Cc: Fernando Gont ; "v6ops@ietf.or= g" ; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ie= tf.org" =0A>S= ent: Tuesday, 4 June 2013 12:30 AM=0A>Subject: Re: [v6ops] new draft: draft= -elkins-v6ops-ipv6-end-to-end-rt-needed=0A> =0A>=0A>=0A>>>I'm afraid that t= hat is known as the "killer app" fallacy. I say "fallacy" instead of "argum= ent" because such arguments have been tried many times but have not been ve= ry successful to date. I don't think it will be very convincing - especiall= y since these=0A>>>companies already have what they need from IPv4, right?= =0A>=0A>=0A>Possibly you are right but given that the execs in question ask= ed me about budget for IPv6, I would suspect that you are wrong. =A0You und= erestimate how much companies spend on agents for gathering response time d= ata which is required for Service Level Agreements. =A0AND how attractive i= t is to NOT have to do that. =A0This extension header provides them capabil= ities they do NOT have with IPv4.=0A>=0A=0ACan you explain this further? Wh= ere are these agents located - on hosts, on routers or as separate probes? = Where is the big cost in gathering this data, given that storage and proces= sing power are cheap (and we're starting to be in an era of "big data", so = tools to handle large amounts of data are becoming more available)? How doe= s your proposed IPv6 extension header eliminate the need to perform measure= ment, collection and analysis of SLA data?=0A=0AAs a random idea, would age= nts in the hosts that trigger SNMP traps when there are TCP duplicate segme= nts or out of order delivery solve the issue? It wouldn't work with UDP as = UDP doesn't support detecting or recovering from these things, and they'd h= ave to be detected at layers above UDP e.g. with RTP as Dan Wing mentioned.= =0A=0AIn other words, better instrumenting hosts to detect and report these= faults based on information they're already collecting for other reasons m= ight be better than trying to develop and deploy a new IPv6 extension heade= r.=A0=0A=0A>=0A=0A>>> Also - supposing you do implement an extension header= - how will the host know whether to use it or not? If it uses it to talk t= o the Internet, then the packet will get dropped. Does the host know which = destinations understand it and which do not? Or will=0A>>>you be forced to = specify and implement stripping this header in intermediate nodes?=0A>=0A>= =0A>Now this is a better point. =A0But, there is a bigger issue here. =A0Th= e companies and agencies that I work with on implementing IPv6, already nee= d to plan for how to differentiate between internal traffic or traffic to b= usiness partners vs. traffic to the Internet. =A0 Some alternatives used ar= e Internet proxies, a separate prefix for Internet traffic vs. trusted traf= fic etc. =A0This is just one more issue that needs to be dealt with. =A0Tha= t is, on such routes or to such destinations, we do not use this header.=0A= >=0A=0AThis sounds like multi-lever security, and Common Architecture Label= IPv6 Security Option (CALIPSO) (RFC5570) might be the answer.=0A=0A=A0=0AR= egards,=0AMark. --1510626085-92495964-1370310333=:42116 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

>>Can you explain this further? Where are these ag= ents located - on hosts, on routers or as separate probes? 

Often agen= ts are located at the end  user device. 

>> Where is the big cost in ga= thering this data, given that storage and processing power are cheap (and w= e're starting to be in an era of "big data", so tools to handle large amoun= ts of data are becoming more available)? 

This is a question better asked of = the vendors of such agents.   Presumably, they feel that the coordinat= ion of agents to a gathering point at a central location as well as the tim= e and effort spent in developing agent code is worth paying for.   Cos= t and price are two different things.  The price charged is what the m= arket will bear.

>> How does your proposed IPv6 extension header eliminate the need to= perform measurement, collection and analysis of SLA data?

Let me give you a simple scenario:

1.  Packet a is sent from source host a.  It is timestampe= d when it leaves host a.  The timestamp is in the proposed PDM extensi= on header.

2.  A free packet tr= ace tool such as WireShark sits at a host b server location.

3.  When packet a reaches the host b, = we know how long the network time was to get from host a to host b because = there is a timestamp.  Without a timestamp, there is no way of knowing= .

4.  When host b finishes its = processing.  It sends packet b back to host a.  The packet trace = tool knows how long the server time was -- the delta between when the packe= t was received at host b to when the packet was sent back to host a.

5. These times can be used for S= ervice Level Agreements of network time and server times.    &nbs= p;

You can develop elaborate systems= to collect this data,  but it simplifies many things.
<= br>
>> As a random idea, would agents in the hosts that trigger SNMP traps = when there are TCP duplicate segments or out of order delivery solve the is= sue? It wouldn't work with UDP as UDP doesn't support detecting or recoveri= ng >>from these things, and they'd have to be detected at layers abov= e UDP e.g. with RTP as Dan Wing mentioned.

Several = questions arise:

1.  Who is to = code such agents?  This is hardly simple code.  You have to captu= re all packets and then find duplicates or out of order in real time and th= en send traps.  AND, you have to do all this in a way that you don't u= se up all the resources of the host in doing the trace capture and analysis= .  Then, you have to send all the data to a central collection point -= reliably.

2.  The other= day, I worked with a device which was sending a duplicate acknowledgment o= nce every millisecond.  If this host was to send SNMP traps  once= every millisecond, this would be not a very nice situation.

>> In other words, better instrume= nting hosts to detect and report these faults based on information they're alrea= dy collecting for other reasons might be better than trying to develop and = deploy a new IPv6 extension header. 

I beg to differ.  I think that the new header is much the= easiest way.   Agent architecture is tremendously difficult and costl= y to develop and maintain.  In particular as we go to a more and more = mobile world.

>>This sounds like multi-lever security, and Common Architecture Labe= l IPv6 Security Option (CALIPSO) (RFC5570) might be the answer.

How this fits in= to the discussion is something that you might want to explain more.  I= am afraid that it is eluding me.
 =
Thanks,

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

=
From: Mark Smith <markzzzsmith= @yahoo.com.au>
To: = Nalini Elkins <nalini.elkins@insidethestack.com>; Lorenzo Colitti <= ;lorenzo@google.com>
Cc: Fernando Gont <fgont@si6networks.com>; "v6ops@ietf.org" <v6o= ps@ietf.org>; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.o= rg" <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org> Sent: Monday, June 3, 20= 13 2:33 PM
Subject: Re= : [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0A
>________________________________=
> From: Nalini Elkins <nalini.elkins= @insidethestack.com>
>To: Lorenzo Colitti <lorenzo@google.= com>
>Cc: Fernando Gont <fgont@si6networks.com&= gt;; "v= 6ops@ietf.org" <v6ops@ietf.org>; "draft-elkins-v6ops-ipv6-en= d-to-end-rt-needed@tools.ietf.org" <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org>
&= gt;Sent: Tuesday, 4 June 2013 12:30 AM
>Subject: Re: [v6ops] new draf= t: draft-elkins-v6ops-ipv6-end-to-end-rt-needed
>
>
>>>>I'm afraid that that is known as the "killer app" fallacy. I s= ay "fallacy" instead of "argument" because such arguments have been tried m= any times but have not been very successful to date. I don't think it will = be very convincing - especially since these
>>>companies alread= y have what they need from IPv4, right?
>
>
>Possibly you= are right but given that the execs in question asked me about budget for I= Pv6, I would suspect that you are wrong.  You underestimate how much c= ompanies spend on agents for gathering response time data which is required= for Service Level Agreements.  AND how attractive it is to NOT have to do that.  This extension header provides them capabilities th= ey do NOT have with IPv4.
>

Can you explain this further? Wher= e are these agents located - on hosts, on routers or as separate probes? Wh= ere is the big cost in gathering this data, given that storage and processi= ng power are cheap (and we're starting to be in an era of "big data", so to= ols to handle large amounts of data are becoming more available)? How does = your proposed IPv6 extension header eliminate the need to perform measureme= nt, collection and analysis of SLA data?

As a random idea, would age= nts in the hosts that trigger SNMP traps when there are TCP duplicate segme= nts or out of order delivery solve the issue? It wouldn't work with UDP as = UDP doesn't support detecting or recovering from these things, and they'd h= ave to be detected at layers above UDP e.g. with RTP as Dan Wing mentioned.=

In other words, better instrumenting hosts to detect and report these faults based on information they're already collecting for ot= her reasons might be better than trying to develop and deploy a new IPv6 ex= tension header. 

>

>>> Also - supposing you = do implement an extension header - how will the host know whether to use it= or not? If it uses it to talk to the Internet, then the packet will get dr= opped. Does the host know which destinations understand it and which do not= ? Or will
>>>you be forced to specify and implement stripping t= his header in intermediate nodes?
>
>
>Now this is a bett= er point.  But, there is a bigger issue here.  The companies and = agencies that I work with on implementing IPv6, already need to plan for ho= w to differentiate between internal traffic or traffic to business partners= vs. traffic to the Internet.   Some alternatives used are Internet pr= oxies, a separate prefix for Internet traffic vs. trusted traffic etc.  This is just one more issue that needs to be dealt with.  = That is, on such routes or to such destinations, we do not use this header.=
>

This sounds like multi-lever security, and Common Architect= ure Label IPv6 Security Option (CALIPSO) (RFC5570) might be the answer.
=
 
Regards,
Mark.


 --1510626085-92495964-1370310333=:42116-- From lorenzo@google.com Mon Jun 3 19:27:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7358F21E8110 for ; Mon, 3 Jun 2013 19:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, 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 1pB2QeWLoz8K for ; Mon, 3 Jun 2013 19:27:07 -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 CE16921F99DA for ; Mon, 3 Jun 2013 18:47:46 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s11so2621816qcw.15 for ; Mon, 03 Jun 2013 18:47:46 -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=WCUoRjVhHzuLb4BO1MBU+h9yIk8kr6nWo6lXeQd0VSo=; b=VV0GLuEORBi+SXil2FEFNyCPIZAeuQDKjMLmwtwbGrpwWO9iAaAyZVI03ICaNqqto8 6PPHKyrsZMa9KKK2BUqr1dNas5g4Yxdy49Tn325CkaI/FfRIEoboVXsoZ9H0M45zzim5 RrZX57bdJjWOKncle5fM2a5/pw4DY1cs8CUhrduOlNsWHy2cauWTLSZ7A4iA8vY8fowz YoByAsN8DriOJ2tz+L6nCTYVZgLWmGF5frWQI6xHzUQ8H1eC5zDcgF1VnT9+2c3ypEfr 3LYeMzO4AmMbV+Tp4UDD0uKCgILk0WtaddWlMU7c+3DqC13f0uY06WJd0L8+oCd8ZJcu u5VA== 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=WCUoRjVhHzuLb4BO1MBU+h9yIk8kr6nWo6lXeQd0VSo=; b=ODLADgw5qswaHJ8QxqSuJV0iTa52RI/8V/Jv9A9iAcsrmCSvU4Qq3XQDFIo2C3+o3b zF2eRDYJ4L1JKpi3q1xpmihrUIKJnKoVpTeEZMMwG2BiYiIfOIuEMm2SwLLc9FcA1NDw 8vTyDUcw8HUMh0/e1B09cjtEFemA8Hf4FhfqD4Dt7espGNQeYx4IUhMpDFnSRGGQ1HJp 9pmThs/weDcn2Pdfr2PjohGbTJop89atdhojorTMM0PvKVXIEb9qemy8MqOLA0CoEfMt zApHJPM+SO52Bgk+PPwH4gUIlzZTHT8TuCTJomCTpOqhOflyvr3EuKzeX102sBuPvIsr JCXw== X-Received: by 10.229.143.79 with SMTP id t15mr8584108qcu.127.1370310466119; Mon, 03 Jun 2013 18:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Mon, 3 Jun 2013 18:47:24 -0700 (PDT) In-Reply-To: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Tue, 4 Jun 2013 10:47:24 +0900 Message-ID: To: Bill Jouris Content-Type: multipart/alternative; boundary=90e6ba30927e90effb04de4a44a2 X-Gm-Message-State: ALoCoQmSItDAHMNqOabcBI+mvYUATwuwXYqbukHjho5lu2wbVC7/NQy6T+DkQ28QlUUWNBr+bVYujNb20Jrk4U4snyvmhFyTPxJx+LU2Y5bJPt8uMoukz9rMSflZM6AQq3P2+v38666coYOM9OAUkgjirIJGzqAhCA+uXjBcf8aLQR05He4gPx+IlJviIkYEspR6BvIMIpCs Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 02:27:17 -0000 --90e6ba30927e90effb04de4a44a2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 12:21 AM, Bill Jouris wrote: > > P.S.: Before any attempt on this path, one should probably ask: are we > > suppoed to have this ind of functionality at the Internet layer? Is this > > worth the pain for most implementations? Is this going to work in the > > general case, or is this going to be the subject of lots fo breakage? > > (e.g., packet drops) > > Fernando, the problem with using any other layer is that it would require > implementation across ALL of the various protocols. Which is far more > disruptive than this implementation in the IP layer would be. > But on the other hand, implementing it at the Internet layer pushes this complexity to every host on the Internet, whereas this functionality is obviously targeted at private network deployments (since it cannot work anywhere else). --90e6ba30927e90effb04de4a44a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 12:21 AM, Bill Jouris <bill.jouris@insidethestack.com> wrote:
> P.S.: Before any attempt on this path, one should pr= obably ask: are we
> suppoed to have this ind of functionality at th= e Internet layer? Is this
> worth the pain for most implementations?= Is this going to work in the
> general case, or is this going to be the subject of lots fo breakage? =
> (e.g., packet drops)

Fernando, the problem with using= any other layer is that it would require implementation across ALL of the = various protocols.=A0 Which is far more disruptive than this implementation= in the IP layer would be.

But on the= other hand, implementing it at the Internet layer pushes this complexity t= o every host on the Internet, whereas this functionality is obviously targe= ted at private network deployments (since it cannot work anywhere else).
--90e6ba30927e90effb04de4a44a2-- From lorenzo@google.com Mon Jun 3 20:01:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF50611E80F3 for ; Mon, 3 Jun 2013 20:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, 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 gELcmIta2d7f for ; Mon, 3 Jun 2013 20:00:51 -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 1798F11E80FA for ; Mon, 3 Jun 2013 19:08:40 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bn16so2247576qab.7 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=Vr49nLGb18I137oj6loJ46MctZ8BTa4asfOaNT2gyiI7RHrxaIu0wx/VUbJnkIWDqX 0vo+NKVhZ3X7z1SVp5E6GZMSgN4wWvMlqlqHHO6G988a/+DbsFPmmyzzPiI8voBfKfRJ 42VnHW1ME4scOlUSaE1T5GEgFdODOL+iWY4n3mds0EHzpqZ7yPdsbkZ3iDd2mwZ+7BYG Jti4SWgUiF0JlXkk68Qk1MvbWQD5BwBPlhBiOKIyTXXytWYrErnAvpR8JV7sOhatbKsD ZP5a/m1vYseey1by3XsPGnOryfR+PejlN9n0aoSUIp9xLxynMPeTelVZYSMdI5dcOpSt QE9w== 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: To: Sheng Jiang Content-Type: multipart/alternative; boundary=047d7bd7566a52272204de4a8fb1 X-Gm-Message-State: ALoCoQm3/NNbFOhlSkyvRVQQ/8wcNaNYN5HoJB3j7WghD3qAeA1rGKPTfefiAqPpyvr0JM994usEmzFDm82+R+JDuGqnECHbieRMMDfSyjx2biOly2mGzXxu/g21LEdEaH4XDwJhNF0d6p69wfdFmEoAI4Jtg6Tv8Z1/VGqW4pCbjx/zebSSnzBpBxzyvGhdqm9X7jh11i/a Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 03:01:06 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 Date: Tue, 4 Jun 2013 04:11:33 +0200 To: joel jaeggli Cc: "v6ops@ietf.org WG" , manning bill , "ipv6@ietf.org" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 andrewmcgr@gmail.com Mon Jun 3 18:59:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Andrew McGregor To: joel jaeggli Content-Type: multipart/alternative; boundary=001a11c36dae00305104de49fd48 X-Mailman-Approved-At: Mon, 03 Jun 2013 20:08:53 -0700 Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 20:52:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a11c33fd2d194c904de4b39b3 Cc: "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 ggm@algebras.org Mon Jun 3 21:25:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845AC21E80D3 for ; Mon, 3 Jun 2013 21:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[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 7WOvnK2hy6wk for ; Mon, 3 Jun 2013 21:24:52 -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 4AAF221E80F6 for ; Mon, 3 Jun 2013 20:25:20 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so6550123pbc.25 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=UCqBZFl8hBi6Ez00g8A7Z7Im819tJzHnLouKAHuJBZiTkcU/ge8ccIXTRn0m4uqvDG huTDr/NRxMyQJrmpGi/iiTWp/zZGnzqPGOTS8I6aDHVjmEFBy08bWdlimInvXJx5/+5q 1gK2zCSx2sBcxhSE2STle0tZ2FZKEI8y7fz56m9TPcT2TWlbyqfkle2Afy1HmqA6rRqh Hpj6V4lpbDxDV7EHI9t9oBPSMt49AFMi5kVu5PSeHpJxEsgdzXSOxG5Iy4QHr+2IiLKw mJ3gozUQJkl1cJLF7xv94C948eM/72rN0NFn7HHm3xhaClkt4Px1QFSpExRzhgFc0gfv XiIg== 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: From: George Michaelson To: Ivan Pepelnjak Content-Type: multipart/alternative; boundary=bcaec544eb967b06fa04de4ba139 X-Gm-Message-State: ALoCoQneDkHSRga4f7DnY5HvBoVU/2tSVhVcAXkhqAmLG6c4MkffTj9iQZ+bRmZ4qkVGjKzuZkmu Cc: "v6ops@ietf.org WG" , Andrew McGregor , "ipv6@ietf.org" , manning bill Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:25:03 -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 nalini.elkins@insidethestack.com Mon Jun 3 21:36:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8807E21E80F3 for ; Mon, 3 Jun 2013 21:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 HU9DrWLbtZbG for ; Mon, 3 Jun 2013 21:36:06 -0700 (PDT) Received: from nm25-vm0.access.bullet.mail.mud.yahoo.com (nm25-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.191]) by ietfa.amsl.com (Postfix) with ESMTP id 88A4221E814D for ; Mon, 3 Jun 2013 20:38:32 -0700 (PDT) Received: from [66.94.237.126] by nm25.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 03:38:32 -0000 Received: from [66.94.237.115] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 03:38:32 -0000 Received: from [127.0.0.1] by omp1020.access.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 03:38:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 136753.78733.bm@omp1020.access.mail.mud.yahoo.com Received: (qmail 78771 invoked by uid 60001); 4 Jun 2013 03:38:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370317111; bh=6sxbFCxGo0vM8vaRLE4pCA+QH4pG0DhvNeDLoPfzrao=; 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=Yn2bZ8z2cifi5eOtibzYUpWI06enWv/Y6+9rzu3IAbf//o/2SVnBMaaT/ykHZtAwxkSNvUh+lVwdfd5WIdyFaxIrlGpaxXZu8n77CwoRm3umxEz+WvZptZsI/a76IkKJmDs34SYwTloEgJJmrmHXPGKvb4CvXKSRYeJ2BMR16AY= X-YMail-OSG: 9U5aDoAVM1lQkrzrlV6a7Zjg8Y0vHQ.a_fMlH00ToAoRGdn 34r0dLb34nbNSYZOAn5iNdul3V9aY1WfH73NbWL9g5DzGuEaECL9Oqfm7KJC FrZ6bqBFGfGu1utgNoNNjzrdWCBEcInH9jmli4E8E.TBMU3.g8tO2IIaUcOd kXZSRafA5DA2ObjUz9gI5M7jVjAw9cNII7nVf4lAYRBT9Rs8eLIgSJ7sOKar tJx.a0FE9_pB15JAPbPBx7v_D17Uvy5wm57U5rWY_8.YL27XDvWCZG53aRKs _KYMZZ_aP3kKi3S4gdWbVNtd6XaZNl.mQfSKDN7lAeXhORJgUUhE_qUkY5o5 FFYSeiyP.baj0Snv.5JoUs9.cQqXPArE7SAc3X9rnQByXEzBX9xOF8CQxOje m6_jJolPDsNLXLTE90j1.hjbdeiB35SVyOZ7RE1EVazL80UW_KPEHe58Q9gz 4LvOqwwjrW7ZBqDKlJXtIk8cI0jZOXapWPBKY.HwAjJZZoGBqTUN8A.j5ImL lqzndmGQpLVBC79ntu326Qu_lQuZo4p4OxWnYagxUCEpH6h13ALRPIckQkp8 1VtDvfPXoCy2AI1TRNWHKSBiq21LrkelSNj256WxxTPtA9b7Mo1Aa.MT0YC4 muoT7La2mPoDaVaW8nIjACn433aBBcw-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Mon, 03 Jun 2013 20:38:31 PDT X-Rocket-MIMEInfo: 002.001, Pj5CdXQgb24gdGhlIG90aGVyIGhhbmQsIGltcGxlbWVudGluZyBpdCBhdCB0aGUgSW50ZXJuZXQgbGF5ZXIgcHVzaGVzIHRoaXMgY29tcGxleGl0eSB0byBldmVyeSBob3N0IG9uIHRoZSBJbnRlcm5ldCwgd2hlcmVhcyB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgb2J2aW91c2x5IHRhcmdldGVkIGF0IHByaXZhdGUgbmV0d29yayBkZXBsb3ltZW50cyAoc2luY2UgaXQgY2Fubm90IHdvcmsgYW55d2hlcmUgZWxzZSkuCgpUaGlzIGlzIGFuIG9wdGlvbmFsIGhlYWRlci4gwqBUaGF0IG1lYW5zIHRoYXQgYSBzdGFjayABMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> Message-ID: <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 20:38:31 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti , Bill Jouris In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-722244437-1370317111=:77475" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:36:21 -0000 ---1551098171-722244437-1370317111=:77475 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>But on the other hand, implementing it at the Internet layer pushes this = complexity to every host on the Internet, whereas this functionality is obv= iously targeted at private network deployments (since it cannot work anywhe= re else).=0A=0AThis is an optional header. =A0That means that a stack or op= erating system can be implemented so that the default is to NOT send this h= eader. =A0End of complexity.=0A=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AIns= ide Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A___= _____________________________=0A From: Lorenzo Colitti = =0ATo: Bill Jouris =0ACc: "v6ops@ietf.org"= =0ASent: Monday, June 3, 2013 6:47 PM=0ASubject: Re: [v6o= ps] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn = Tue, Jun 4, 2013 at 12:21 AM, Bill Jouris = wrote:=0A=0A> P.S.: Before any attempt on this path, one should probably as= k: are we =0A>> suppoed to have this ind of functionality at the Internet l= ayer? Is this =0A>> worth the pain for most implementations? Is this going = to work in the =0A>> general case, or is this going to be the subject of lo= ts fo breakage? =0A>> (e.g., packet drops)=0A>=0A>Fernando, the problem wit= h using any other layer is that it would require implementation across ALL = of the various protocols.=A0 Which is far more disruptive than this impleme= ntation in the IP layer would be. =0A> =0A=0ABut on the other hand, impleme= nting it at the Internet layer pushes this complexity to every host on the = Internet, whereas this functionality is obviously targeted at private netwo= rk deployments (since it cannot work anywhere else).=0A____________________= ___________________________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps:/= /www.ietf.org/mailman/listinfo/v6ops ---1551098171-722244437-1370317111=:77475 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>>But on the other hand, implementing it at the Internet la= yer pushes this complexity to every host on the Internet, whereas this func= tionality is obviously targeted at private network deployments (since it ca= nnot work anywhere else).

This is an optional head= er.  That means that a stack or operating system can be implemented so= that the default is to NOT send this header.  End of complexity.

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

From: Lorenzo Colitti <lorenzo@google.com>
To: Bill Jouris <bill.jouris@i= nsidethestack.com>
Cc:<= /b> "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Monday, June 3, 2013 6:47 PM
Subject: Re: [v6ops] new draft: draft-e= lkins-v6ops-ipv6-end-to-end-rt-needed

=0A
On Tue, Jun 4= , 2013 at 12:21 AM, Bill Jouris <bill.jouris@insidethestack.com&g= t; wrote:
=0A=0A
= =0A=0A
> P.S.: Before any attempt on this p= ath, one should probably ask: are we
> suppoed to have this ind of f= unctionality at the Internet layer? Is this
> worth the pain for mos= t implementations? Is this going to work in the
=0A=0A> general case= , or is this going to be the subject of lots fo breakage?
> (e.g., p= acket drops)

Fernando, the problem with using any other layer = is that it would require implementation across ALL of the various protocols= .  Which is far more disruptive than this implementation in the IP lay= er would be.
=0A=0A

But on the other hand, implementing it at the Internet la= yer pushes this complexity to every host on the Internet, whereas this func= tionality is obviously targeted at private network deployments (since it ca= nnot work anywhere else).
=0A=0A
=0A

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


---1551098171-722244437-1370317111=:77475-- From owen@delong.com Mon Jun 3 21:43:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC0C11E813F for ; Mon, 3 Jun 2013 21:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OODnP+Va0+b0 for ; Mon, 3 Jun 2013 21:43:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 68E8B11E8156 for ; Mon, 3 Jun 2013 20:47: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 r543lZx9000868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 20:47:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r543lZx9000868 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370317657; bh=SPjKKul9c2VL5wblkPPbAfn9qgM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=eXPNnyNznACwnEQIZT79gCWKQoGOUuBizL3Y/23UMFn1MeOtdWZG4J7f5dPCUik/M RP7+WkqMtaNJK4jNJIwG5Rh8Se8tuwd21uCmZ71H272Z5/tdtBhFz8zzBRSdBjyXXW D7nj+n0XsmFuMwuUJr2kAv5Qll2g3/2d+i0optSo= Content-Type: multipart/alternative; boundary="Apple-Mail=_B631F0CD-3F51-4CD5-B495-142C5171C96B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1370310333.42116.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Mon, 3 Jun 2013 20:47:35 -0700 Message-Id: <8C13C09D-56B7-444D-8548-90616087A675@delong.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370269844.30551.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <1370295200.19858.YahooMailNeo@web142503.mail.bf1.yahoo.com> <1370310333.42116.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> To: Nalini Elkins X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 03 Jun 2013 20:47:37 -0700 (PDT) Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:43:39 -0000 --Apple-Mail=_B631F0CD-3F51-4CD5-B495-142C5171C96B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 3, 2013, at 18:45 , Nalini Elkins = wrote: >=20 > >>Can you explain this further? Where are these agents located - on = hosts, on routers or as separate probes?=20 >=20 > Often agents are located at the end user device.=20 >=20 > >> Where is the big cost in gathering this data, given that storage = and processing power are cheap (and we're starting to be in an era of = "big data", so tools to handle large amounts of data are becoming more = available)?=20 >=20 > This is a question better asked of the vendors of such agents. = Presumably, they feel that the coordination of agents to a gathering = point at a central location as well as the time and effort spent in = developing agent code is worth paying for. Cost and price are two = different things. The price charged is what the market will bear. >=20 > >> How does your proposed IPv6 extension header eliminate the need to = perform measurement, collection and analysis of SLA data? >=20 > Let me give you a simple scenario: >=20 > 1. Packet a is sent from source host a. It is timestamped when it = leaves host a. The timestamp is in the proposed PDM extension header. >=20 > 2. A free packet trace tool such as WireShark sits at a host b server = location. >=20 > 3. When packet a reaches the host b, we know how long the network = time was to get from host a to host b because there is a timestamp. = Without a timestamp, there is no way of knowing. But the accurate resolution of this knowledge is on the order of =B1 = tens if not hundreds of milliseconds, not the picoseconds you stated = earlier. The relative difference in timestamps between packets sent from the same = host may be microseconds or even sub-microseconds (very unlikely nano, = let alone pico seconds), but the accuracy when comparing time on server = b to timestamps created by host a is much much less, even with NTP = synchronizing both hosts. > 4. When host b finishes its processing. It sends packet b back to = host a. The packet trace tool knows how long the server time was -- the = delta between when the packet was received at host b to when the packet = was sent back to host a. But it cannot know how long it took the packet b to arrive back at host = a, which I would expect must be part of any meaningful SLA as well. Remember, the return route from b to a does not necessarily have = anything in common with the pat from a to b. The traversal time could be = radically different or the packet might never arrive at host a. Without = an agent on host a, you cannot measure this. > 5. These times can be used for Service Level Agreements of network = time and server times. =20 >=20 Not as a complete solution, they can't. You still need the agent on host = a to measure the total time between when it sent packet a and when it = received packet b. > You can develop elaborate systems to collect this data, but it = simplifies many things. >=20 > >> As a random idea, would agents in the hosts that trigger SNMP traps = when there are TCP duplicate segments or out of order delivery solve the = issue? It wouldn't work with UDP as UDP doesn't support detecting or = recovering >>from these things, and they'd have to be detected at layers = above UDP e.g. with RTP as Dan Wing mentioned. >=20 > Several questions arise: >=20 > 1. Who is to code such agents? This is hardly simple code. You have = to capture all packets and then find duplicates or out of order in real = time and then send traps. AND, you have to do all this in a way that = you don't use up all the resources of the host in doing the trace = capture and analysis. Then, you have to send all the data to a central = collection point - reliably. You don't have to capture all packets... You only have to capture the = packets in flows you are interested in analyzing. >=20 > 2. The other day, I worked with a device which was sending a = duplicate acknowledgment once every millisecond. If this host was to = send SNMP traps once every millisecond, this would be not a very nice = situation. >=20 I'm not sure I follow the relationship here. Why does the result from = the host have to be different from the result that would be produced as = a result of your extension header? If the extension header wouldn't = cause the host to send an SNMP trap every ms, why would the agent have = to do so? Owen --Apple-Mail=_B631F0CD-3F51-4CD5-B495-142C5171C96B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 nalini.elkins@insidethest= ack.com> wrote:


>>Can = you explain this further? Where are these agents located - on hosts, on = routers or as separate probes? 
Often agents are located at the = end  user device. 

>> Where is the big cost in = gathering this data, given that storage and processing power are cheap = (and we're starting to be in an era of "big data", so tools to handle = large amounts of data are becoming more = available)? 

This is a question better asked = of the vendors of such agents.   Presumably, they feel that the = coordination of agents to a gathering point at a central location as = well as the time and effort spent in developing agent code is worth = paying for.   Cost and price are two different things.  The = price charged is what the market will bear.

>> How does your proposed IPv6 = extension header eliminate the need to perform measurement, collection = and analysis of SLA data?

Let = me give you a simple scenario:

1. =  Packet a is sent from source host a.  It is timestamped when = it leaves host a.  The timestamp is in the proposed PDM extension = header.

2.  A free = packet trace tool such as WireShark sits at a host b server = location.

3.  When = packet a reaches the host b, we know how long the network time was to = get from host a to host b because there is a timestamp.  Without a = timestamp, there is no way of = knowing.

But the accurate = resolution of this knowledge is on the order of =B1 tens if not hundreds = of milliseconds, not the picoseconds you stated = earlier.

The relative difference in timestamps = between packets sent from the same host may be microseconds or even = sub-microseconds (very unlikely nano, let alone pico seconds), but the = accuracy when comparing time on server b to timestamps created by host a = is much much less, even with NTP synchronizing both = hosts.

>> As a random idea, would agents in the hosts that trigger = SNMP traps when there are TCP duplicate segments or out of order = delivery solve the issue? It wouldn't work with UDP as UDP doesn't = support detecting or recovering >>from these things, and they'd = have to be detected at layers above UDP e.g. with RTP as Dan Wing = mentioned.

Several questions = arise:

1.  Who is to = code such agents?  This is hardly simple code.  You have to = capture all packets and then find duplicates or out of order in real = time and then send traps.  AND, you have to do all this in a way = that you don't use up all the resources of the host in doing the trace = capture and analysis.  Then, you have to send all the data to a = central collection point - = reliably.

You don't have to = capture all packets... You only have to capture the packets in flows you = are interested in analyzing.


2.  The other = day, I worked with a device which was sending a duplicate acknowledgment = once every millisecond.  If this host was to send SNMP traps =  once every millisecond, this would be not a very nice = situation.


I'm= not sure I follow the relationship here. Why does the result from the = host have to be different from the result that would be produced as a = result of your extension header? If the extension header wouldn't cause = the host to send an SNMP trap every ms, why would the agent have to do = so?

Owen

= --Apple-Mail=_B631F0CD-3F51-4CD5-B495-142C5171C96B-- From owen@delong.com Mon Jun 3 21:52:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 joelja@bogus.com Mon Jun 3 22:19:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 lorenzo@google.com Mon Jun 3 23:04:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA64521F8546 for ; Mon, 3 Jun 2013 23:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.040, 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 H6SidAPUkp5N for ; Mon, 3 Jun 2013 23:04:48 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 729F621E8123 for ; Mon, 3 Jun 2013 22:00:35 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ci6so148264qab.9 for ; Mon, 03 Jun 2013 22:00:34 -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=P04BZxPJnoESCYbWRQzmlfqDOWMSTEfwvE5gO2UlZ+Q=; b=KlZ+NwXYaDF6kzHgb2wm0iuyA0pMZkJYu2tiYdmlgsuaekgZfsjuzZOlZqCQbNFa0Z v/YeeYdYdbo0Y+0xiTLr3uYajwULsTKjxmq9ilrUBKaEZDxslk1YR+I5cUrFZpZHAS7U LV0pBBmv90tE8gSpL5amhXkjBXvCpSN/DpXEAWrk2B3vr8t6ViNzfYXS6V6Z02B3Heqv lg5imHkkVolUXaLmu1Lz9woUl8cFA2KbCSH+PITUN8s0Hg8XdjCuTUbjEtyZ/oIQegZF VxyPM/5rukzr5uPlqdqN5zh9jiycb0fkSvlXc9w3e6e0yQjPzdRbBwQL3f2fH+9D3979 52FQ== 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=P04BZxPJnoESCYbWRQzmlfqDOWMSTEfwvE5gO2UlZ+Q=; b=QoeqXLMg/FYMrUpUyZsyeihtL3uk64bhW1n+vJW5NncYW0FFyttuBAs0Qb/qLsg+ND DNzJ85iSeqR32x51FMkJ1DFU6Pknq8OY90esUDvoQz/hxzUyhReRJL0swmTPwjYcDlMe /7ihpOpZJPljQjTcPnfBPQf9N2LgoYpNearQ3EwNbmfOGvlR0DsxzUK89+aanRxdMciW vo4GMLhzyL+5jjEa62O3AVUp4mkJyMwB72OgFAhxM6rZkyiqOnC/FmcpqB7w8i3ovEJY /wNZLrBHiLycBHWGAaT9wD7NAH3lm4bhxi/ZrsBMLN3gxvTYmNRJFJ4exwZ+fkB53vMR SPzw== X-Received: by 10.224.46.66 with SMTP id i2mr22213758qaf.45.1370322034751; Mon, 03 Jun 2013 22:00:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Mon, 3 Jun 2013 22:00:14 -0700 (PDT) In-Reply-To: <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Tue, 4 Jun 2013 14:00:14 +0900 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=001a11c29e0a1c177e04de4cf645 X-Gm-Message-State: ALoCoQlOcEg0Ksr5nzi4l2lbCda4rN01VHkLTU2N2luFJqKCxmKlGdlMvPbh35ukIuZNZibRjFQ+ox/C46df3tp6j0mqNsX6UDn5Gl1sYxSQaEtL3sGdeYKKdIxf/e5BXXBjJxtVDQwobn6Uc7U2xMAuKSJX/hAnTsZun9Xktyi8KUoGaEV2UbFo8SypBbrAsRyeF21Pe/KT Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 06:04:58 -0000 --001a11c29e0a1c177e04de4cf645 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 12:38 PM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > >>But on the other hand, implementing it at the Internet layer pushes this > complexity to every host on the Internet, whereas this functionality is > obviously targeted at private network deployments (since it cannot work > anywhere else). > > This is an optional header. That means that a stack or operating system > can be implemented so that the default is to NOT send this header. End of > complexity. > Well, but complexity that is off by default is still complexity. Kernel code has to be written to implement the header, testing must be done to ensure it works, firewalls need to be modified to not drop it, and so on. This complexity can only be avoided by not implementing the header. If you implement the complexity above the Internet layer, then you don't need to add complexity to the Internet layer and you can implement it at the application layer only for those applications that need it. That way, the applications implementing the complexity are also the ones getting the benefit. If you don't want to do it at the application layer, an alternative that also doesn't involve adding complexity to general Internet hosts would be an Internet-layer header that is not implemented in standard Internet hosts and standard operating systems, but is only implemented by hosts in networks that need this functionality. Is that approach acceptable, or do you want this functionality to be part of every Internet-connected host? --001a11c29e0a1c177e04de4cf645 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 12:38 PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
>>But on the ot= her hand, implementing it at the Internet layer pushes this complexity to e= very host on the Internet, whereas this functionality is obviously targeted= at private network deployments (since it cannot work anywhere else).

This is an optional header. =A0That means that a = stack or operating system can be implemented so that the default is to NOT = send this header. =A0End of complexity.

Well, but complexity that is off by = default is still complexity. Kernel code has to be written to implement the= header, testing must be done to ensure it works, firewalls need to be modi= fied to not drop it, and so on. This complexity can only be avoided by not = implementing the header.

If you implement the complexity above the I= nternet layer, then you don't need to add complexity to the Internet la= yer and you can implement it at the application layer only for those applic= ations that need it. That way, the applications implementing the complexity= are also the ones getting the benefit.

If you don't want to do it at the appli= cation layer, an alternative that also doesn't involve adding complexit= y to general Internet hosts would be an Internet-layer header that is not i= mplemented in standard Internet hosts and standard operating systems, but i= s only implemented by hosts in networks that need this functionality. Is th= at approach acceptable, or do you want this functionality to be part of eve= ry Internet-connected host?
--001a11c29e0a1c177e04de4cf645-- From ipepelnjak@gmail.com Mon Jun 3 23:12:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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 Cc: v6ops@ietf.org, 'manning bill' , ipv6@ietf.org, 'Andrew McGregor' Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 v6ops@globis.net Tue Jun 4 00:57:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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, 'Andrew McGregor' Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 mackermann@bcbsm.com Tue Jun 4 06:41:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C628D21F99B7 for ; Tue, 4 Jun 2013 06:41: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, 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 2aB7zBiCxomC for ; Tue, 4 Jun 2013 06:40:47 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id B7D1F21F9998 for ; Tue, 4 Jun 2013 05:09:12 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id C428A9ADA88 for ; Tue, 4 Jun 2013 07:09:11 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 024A49ADA7E; Tue, 4 Jun 2013 07:09:10 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 9F6B64F804D; Tue, 4 Jun 2013 08:04:47 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id 906A24F8049; Tue, 4 Jun 2013 08:04:47 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 08:09:10 -0400 From: "Ackermann, Michael" To: "Fred Baker (fred)" , "Dan Wing (dwing)" Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOXfzaHn4XBQzX90KTpobgByNivpkgSnIAgADqggCAAxI6oA== Date: Tue, 4 Jun 2013 12:09:09 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A77505A@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:41:01 -0000 I would like to agree with what I believe Fred is saying. That is, that = for those of us that do diagnostics at large DataCenters (EDCO), the = problem resolution needs addressed here span multiple protocols and are = not limited to TCP. =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Fred Baker (fred) Sent: Saturday, June 01, 2013 10:47 AM To: Dan Wing (dwing) Cc: v6ops=40ietf.org; = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On May 31, 2013, at 5:48 PM, Dan Wing wrote: >=20 > On May 31, 2013, at 5:45 AM, fred=40cisco.com wrote: >=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed. = Please take a look at it and comment. >=20 > I read that document and draft-elkins-v6ops-ipv6-packet-sequence-needed. = Both the documents talk about how IPID is useful on IPv4 (if the sender = is monotonically increasing the IPID, which is a necessity for the = existing system to operate) and how routers sometimes send a packet twice = (which is normal behavior of Ethernet) and that the monotonically = increasing IPID helps distinguish Ethernet re-transmissions from host = stack retransmissions. >=20 > I note that Real Time Protocol (RTP, RFC3550; previously RFC1889 = published in 1996) had similar needs and solved them at the RTP = application layer with sequence numbers and timestamps, and with its RTCP = feedback channel. The two I-Ds that I reviewed did not discuss why this = application timing problem cannot be solved at the application layer like = RTP solved it. >=20 > I did not see an analysis of forcing an IPv6 fragmentation header (as = done by 4rd for transparency, = http://tools.ietf.org/html/draft-ietf-softwire-4rd), as that could provide = a function nearly identical to the existing (ab)use of IPv4 IPID. >=20 > -d Well, we can discuss what layer RTP is in; I'm not sure it's application. = It's usable by a number of applications.=20 I would agree that the requirement to place it in a network layer header = has not been established; they could, for example, use the octet sequence = number in the TCP header, unless everything above the network layer is = encrypted. However, I think it *is* fair to say that putting it lower down = the stack makes it readily accessible for more applications or transports = more quickly. You have experience with Happy Eyeballs, and the fact that = the horrendous design of the socket API forces us to change every = application individually when we could have changed the invisible = underpinnings of an OS API once, and in so doing ported all of the = applications to IPv6 as well. She has a similar problem, but in a packet. _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From mackermann@bcbsm.com Tue Jun 4 06:41:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8930A21F9A88 for ; Tue, 4 Jun 2013 06:41:11 -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 R4kKK4QdNJmk for ; Tue, 4 Jun 2013 06:40:56 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id B86E921F9CE7 for ; Tue, 4 Jun 2013 05:09:13 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 65B939ADA86 for ; Tue, 4 Jun 2013 07:09:13 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 035159ADA7E; Tue, 4 Jun 2013 07:09:12 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 3E7962F0052; Tue, 4 Jun 2013 08:04:42 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 1F8882F0043; Tue, 4 Jun 2013 08:04:42 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 4 Jun 2013 08:09:12 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%11]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 08:09:11 -0400 From: "Ackermann, Michael" To: Simon Perreault , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOXfzaHn4XBQzX90KTpobgByNivpkgSnIAgADqggCAAA17gIACsQyAgABVSaA= Date: Tue, 4 Jun 2013 12:09:10 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A77605F@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC56D3.4070501@viagenie.ca> In-Reply-To: <51AC56D3.4070501@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:41:11 -0000 Possibly true. But when the intended value is understood, perceived and = experienced, then those implememtations that wish to derive the inherent = benefits, will configure accordingly. =20 Anything which is new may be relatively unknown and unused initially, but = the intent is to have a valuable,useful diagnostic facility, once it is = understood (and possible even optimized).=20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Simon Perreault Sent: Monday, June 03, 2013 4:42 AM To: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed Le 2013-06-01 17:35, Nalini Elkins a =E9crit : > The second reason for not having a fragment header is that=20 > unfortunately, a number of firewalls, etc, drop packets which contain > IPv6 fragment headers. About that: I would guess that the number of firewalls that will drop a = new option header will be greater than the number of firewalls that = currently drop fragment headers. So the current situation with firewalls = would argue in favour of using the fragment header... Simon _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From mackermann@bcbsm.com Tue Jun 4 06:41:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8521F9AC2 for ; Tue, 4 Jun 2013 06:41:16 -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 DasnhxsF4akr for ; Tue, 4 Jun 2013 06:41:01 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id DE4BC21F9CE8 for ; Tue, 4 Jun 2013 05:09:13 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id B0E5C2FF6E2 for ; Tue, 4 Jun 2013 07:09:13 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 0B927307483; Tue, 4 Jun 2013 07:09:13 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 3C08F2F004F; Tue, 4 Jun 2013 08:04:42 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 276D22F004D; Tue, 4 Jun 2013 08:04:42 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 08:09:12 -0400 From: "Ackermann, Michael" To: Nalini Elkins , Fernando Gont Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOXfzaHn4XBQzX90KTpobgByNivpkgSnIAgADqggCAAA17gIADBo2AgAADMQCAAAhfgA== Date: Tue, 4 Jun 2013 12:09:12 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A776074PWN401EA160entc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:41:16 -0000 --_000_4FC37E442D05A748896589E468752CAA0A776074PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we are to assume that ALL Extension Headers are going to be dropped = then IPV6 has MUCH BIGGER issues than being addressed in this draft. ________________________________ From: Fernando Gont = > To: Nalini Elkins = > Cc: Fred Baker (fred) >; Dan = Wing (dwing) >; = =22v6ops=40ietf.org=22 = >; = =22draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org=22 = > Sent: Monday, June 3, 2013 6:47 AM Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On 06/01/2013 05:35 PM, Nalini Elkins wrote: > 2. Forcing of IPv6 fragmentation header. We did discuss this in > section 3: > = http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-0= 0=23page-11 > > It is as follows: > > =22The current IPv6 specification does not provide a packet sequence > number or similar field in the IPv6 main header. One option might be > to force all IPv6 packets to contain a Fragment Header. In packets > which are entire in and of themselves, the fragment ID would be zero > - that is, an atomic fragment. This is incorrect. Please reference any RFC section which requires a special Identification value (i.e., zero) for atomic fragments (hint: there's no such a recommendation). > The second reason for not having a fragment header is that > unfortunately, a number of firewalls, etc, drop packets which contain > IPv6 fragment headers. I find this to be unsuitable behavior which I > hope will change . But, it is the reality. Firewalls will usually block all extension headers. My advice in this area would be =22think twice before specifying an IPv6 extension header. Then don't=22. :-) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont=40si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A776074PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif =21mso=5D><=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

If we are to assume that ALL Extension = Headers are going to be dropped then IPV6 has MUCH BIGGER issues than = being addressed in this draft. 

 

From: Fernando Gont <fgont=40si6networks.com>=
To: Nalini Elkins <nalini.elkins=40insi= dethestack.com>
Cc: Fred Baker (fred) <fred=40cisco.com>; Dan Wing = (dwing) <dwing=40cisco.com>; "v6ops=40ietf.org" <v6ops=40ietf.org>; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org&qu= ot; <draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org>
Sent: Monday, June 3, 2013 6:47 AM
Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed


On 06/01/2013 05:35 PM, Nalini Elkins wrote:
> 2.  Forcing of IPv6 fragmentation header.  We did discuss = this in
> section 3:
> http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-0= 0=23page-11
>
>  It is as follows:
>
> "The current IPv6 specification does not provide a packet = sequence
> number or similar field in the IPv6 main header.  One option = might be
> to force all IPv6 packets to contain a Fragment Header.  In = packets
> which are entire in and of themselves, the fragment ID would be = zero
> - that is, an atomic fragment.

This is incorrect. Please reference any RFC section which requires a
special Identification value (i.e., zero) for atomic fragments (hint:
there's no such a recommendation).



> The second reason for not having a fragment header is that
> unfortunately, a number of firewalls, etc, drop packets which = contain
> IPv6 fragment headers.  I find this to be unsuitable behavior = which I
> hope will change .  But, it is the reality.

Firewalls will usually block all extension headers. My advice in this
area would be "think twice before specifying an IPv6 extension = header.
Then don't". :-)

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






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

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

--_000_4FC37E442D05A748896589E468752CAA0A776074PWN401EA160entc_-- From mackermann@bcbsm.com Tue Jun 4 06:41:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A4521F9B93 for ; Tue, 4 Jun 2013 06:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqynji37qYGj for ; Tue, 4 Jun 2013 06:41:11 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 96B3621F9CED for ; Tue, 4 Jun 2013 05:09:15 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 5E5209ADA8C for ; Tue, 4 Jun 2013 07:09:15 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 126359ADA7E; Tue, 4 Jun 2013 07:09:14 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id B19704F804D; Tue, 4 Jun 2013 08:04:50 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id 943864F8055; Tue, 4 Jun 2013 08:04:50 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 4 Jun 2013 08:09:13 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%11]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 08:09:12 -0400 From: "Ackermann, Michael" To: Nalini Elkins , Fernando Gont , Dan Wing Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOXfzaHn4XBQzX90KTpobgByNivpkgSnIAgAP9gwCAAAG0AIAACUXg Date: Tue, 4 Jun 2013 12:09:11 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A77606B@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <51AC9DB0.70201@si6networks.com> <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1370267422.47637.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A77606BPWN401EA160entc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:41:26 -0000 --_000_4FC37E442D05A748896589E468752CAA0A77606BPWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The large IPID numbers and the rapid change due to high bandwidth = connections (and ultimately whether 32 bits is large enough for IPID in = the Fragment header), could conceivably be an issue in a situation with = an extremely large number of fragments, when using the IPID for Fragment = reassembly . However, it would never be an issue using the Packet Sequence Number field = for diagnostic purposes. From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Nalini Elkins Sent: Monday, June 03, 2013 9:50 AM To: Fernando Gont; Dan Wing Cc: v6ops=40ietf.org; = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed >>Given the length of the IPv4 IP ID, badwidths available today, etc., I >> don't think you can/should use the IP ID for much. When diagnosing problems at end locations, often, you finally get down to = a series of packets which is the problem. This may be 10 or 20 packets. It doesn't matter what the bandwidth is, it does matter whether you can = say exactly what happened in those 10 or 20 packets. The case studies we have are from actual operators who actually use this = field. AND find it saves a great deal of time because it works. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: Fernando Gont = > To: Dan Wing > Cc: v6ops=40ietf.org; = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org Sent: Monday, June 3, 2013 6:44 AM Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On 06/01/2013 02:48 AM, Dan Wing wrote: > draft-elkins-v6ops-ipv6-packet-sequence-needed. Both the documents > talk about how IPID is useful on IPv4 (if the sender is monotonically > increasing the IPID, which is a necessity for the existing system to > operate) This is not correct. The IP ID is not required to be monotonically increasing -- it just need to not be reused to quickly. A simple (and poor implementation) could have an array of 65536 integers in the range 0-65535 (without repeating any value), and then the stack would select the IP ID as: array=5Bfragment=5D -- where =22fragment=22 is the number of fragments that have been sent so = far. As a datapoint, look at OpenBSD's IP ID generation. > and how routers sometimes send a packet twice (which is > normal behavior of Ethernet) and that the monotonically increasing > IPID helps distinguish Ethernet re-transmissions from host stack > retransmissions. Given the length of the IPv4 IP ID, badwidths available today, etc., I don't think you can/should use the IP ID for much. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont=40si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A77606BPWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif =21mso=5D><=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

The large IPID numbers and the rapid change due = to high bandwidth connections (and ultimately whether 32 bits is large = enough for IPID   in the Fragment header),  could conceivably be an issue in a situation with an extremely = large number of fragments, when using the IPID for Fragment reassembly = =2E   

However, it would never be an issue using the = Packet Sequence Number field for diagnostic purposes. 

 

From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Nalini Elkins
Sent: Monday, June 03, 2013 9:50 AM
To: Fernando Gont; Dan Wing
Cc: v6ops=40ietf.org; = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org
Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed

 

>>Given the length of the IPv4 IP ID, = badwidths available today, etc., I

>> don't think you can/should use = the IP ID for much.

 

When diagnosing problems at end locations, = often, you finally get down to a series of packets which is the problem. =   This may be 10 or 20 packets.  

 

It doesn't matter what the bandwidth is, it = does matter whether you can say exactly what happened in those 10 or 20 = packets.   

 

The case studies we have are from actual = operators who actually use this field.  AND find it saves a great = deal of time because it works.

 

Thanks,

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

From: Fernando Gont <fgont=40si6networks.com>=
To: Dan Wing <dwing=40cisco.com>
Cc: v6ops=40ietf.org; = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org
Sent: Monday, June 3, 2013 6:44 AM
Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed


On 06/01/2013 02:48 AM, Dan Wing wrote:
> draft-elkins-v6ops-ipv6-packet-sequence-needed.  Both the = documents
> talk about how IPID is useful on IPv4 (if the sender is = monotonically
> increasing the IPID, which is a necessity for the existing system = to
> operate)

This is not correct. The IP ID is not required to be monotonically
increasing -- it just need to not be reused to quickly.

A simple (and poor implementation) could have an array of 65536 integers
in the range 0-65535 (without repeating any value), and then the stack
would select the IP ID as:

array=5Bfragment=5D

--  where "fragment" is the number of fragments that have = been sent so far.



As a datapoint, look at OpenBSD's IP ID generation.


> and how routers sometimes send a packet twice (which is
> normal behavior of Ethernet) and that the monotonically increasing
> IPID helps distinguish Ethernet re-transmissions from host stack
> retransmissions.

Given the length of the IPv4 IP ID, badwidths available today, etc., I
don't think you can/should use the IP ID for much.

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




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


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

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

--_000_4FC37E442D05A748896589E468752CAA0A77606BPWN401EA160entc_-- From mackermann@bcbsm.com Tue Jun 4 07:02:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5507021F9D6B for ; Tue, 4 Jun 2013 07:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1deqLv9TaVx for ; Tue, 4 Jun 2013 07:02:06 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id AC0F821F9BA2 for ; Tue, 4 Jun 2013 05:28:09 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id DA0832FF6E2 for ; Tue, 4 Jun 2013 07:09:14 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 2B66E307483; Tue, 4 Jun 2013 07:09:14 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id D07424F805D; Tue, 4 Jun 2013 08:04:50 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id B2E2E4F8053; Tue, 4 Jun 2013 08:04:50 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 08:09:11 -0400 From: "Ackermann, Michael" To: Fernando Gont , Nalini Elkins Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOXfzaHn4XBQzX90KTpobgByNivpkgSnIAgADqggCAAA17gIADBo2AgAABRWA= Date: Tue, 4 Jun 2013 12:09:10 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A776066@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> In-Reply-To: <51AC9E8D.9060609@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 14:02:26 -0000 As a diagnostic person, I would prefer this information to be in the Main = IP Header, as in IPV4. =20 However, understanding all the issues from the previous IETF meeting in = Orlando, the best solution was an extension Header.=20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Fernando Gont Sent: Monday, June 03, 2013 9:48 AM To: Nalini Elkins Cc: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org; = v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On 06/01/2013 05:35 PM, Nalini Elkins wrote: > 2. Forcing of IPv6 fragmentation header. We did discuss this in=20 > section 3: > http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-nee > ded-00=23page-11 > > It is as follows: >=20 > =22The current IPv6 specification does not provide a packet sequence=20 > number or similar field in the IPv6 main header. One option might be=20 > to force all IPv6 packets to contain a Fragment Header. In packets=20 > which are entire in and of themselves, the fragment ID would be zero > - that is, an atomic fragment. This is incorrect. Please reference any RFC section which requires a = special Identification value (i.e., zero) for atomic fragments (hint: there's no such a recommendation). > The second reason for not having a fragment header is that=20 > unfortunately, a number of firewalls, etc, drop packets which contain > IPv6 fragment headers. I find this to be unsuitable behavior which I > hope will change . But, it is the reality. Firewalls will usually block all extension headers. My advice in this area = would be =22think twice before specifying an IPv6 extension header. Then don't=22. :-) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont=40si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From shengjiang@gmail.com Tue Jun 4 08:04:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11c377da28a48204de53de8b Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: Sheng Jiang To: George Michaelson Content-Type: multipart/alternative; boundary=089e01493c0eb9393004de5400ad Cc: "v6ops@ietf.org WG" , manning bill , "ipv6@ietf.org" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 nick@inex.ie Tue Jun 4 08:41:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4E521F9B1B for ; Tue, 4 Jun 2013 08:41:20 -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 MjIyaAn09ndS for ; Tue, 4 Jun 2013 08:41:10 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A021F9A60 for ; Tue, 4 Jun 2013 06:44:16 -0700 (PDT) X-Envelope-To: Received: from pancake.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r54DiBhp029134 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 4 Jun 2013 14:44:11 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <51ADEF2B.4000008@inex.ie> Date: Tue, 04 Jun 2013 14:44:11 +0100 From: Nick Hilliard 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: v6ops@ietf.org References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:41:20 -0000 On 04/06/2013 13:09, Ackermann, Michael wrote: > If we are to assume that ALL Extension Headers are going to be dropped then > IPV6 has MUCH BIGGER issues than being addressed in this draft. That would be a reasonable assessment of v6 extension headers, yes. Nick From nalini.elkins@insidethestack.com Tue Jun 4 09:08:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676C621F9B0D for ; Tue, 4 Jun 2013 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.115, 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 egBIg7eZXB99 for ; Tue, 4 Jun 2013 09:08:29 -0700 (PDT) Received: from nm19-vm0.access.bullet.mail.mud.yahoo.com (nm19-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4371421F9A30 for ; Tue, 4 Jun 2013 06:59:58 -0700 (PDT) Received: from [66.94.237.199] by nm19.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 13:59:57 -0000 Received: from [66.94.237.107] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 13:59:57 -0000 Received: from [127.0.0.1] by omp1012.access.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 13:59:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 695889.7652.bm@omp1012.access.mail.mud.yahoo.com Received: (qmail 19772 invoked by uid 60001); 4 Jun 2013 13:59:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370354397; bh=MCh+MhLm6Szz+Wp7VMJYjXt4knJHzBbdCAK0zDBCBiI=; 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=6Ag3ZaQH4JBq4Vq8Id63x4cYGf/npBH0wwdJvfzOJu6mfhHAk5dJG8WhwP6yKM/ylO7sJldH9XVR1/4U2peT72GE6OaJmP0g2CJPXGmztVqzxHV32dswQJMaMwUDDch0yzh19DHzfC3lx9Azx1PwhgrdPBIAlueh7utaGTcI1V0= X-YMail-OSG: YEcTVcoVM1k0pEqvOvu.0njCkMmsdhyXZmZhY_mOTZ0zvxc .g6_nDEfoqi8z6zSzdjuyZ3sgoRgj.J86WprJRbPi69NGX38vOs.Ez613h.S PolS6M849bttqHOsf.eGM34CBUSn_Kf9Syrf8PDADh4z5O7tkNNAOoModHkE BFHcSkyAtFxndmGrayrvNqxHW9Ar4JWGHPZo8.US9ZFLkxIFAi_U8._th.93 5LrZM4_cnoVIii.b0M_aQCM9.dPCUXLdJTI3KAm5FZsWSktZtHUwAuY.QZWo kp7i0F.gkJLQGscvBeoR_8oAv9QMZnSrr0VmTtGnCKzJHA5A6Yn.rn8lzZ5U qWSSNifUpoOxiUfFNQWibPbt.elSSQuBErjiIYqZJNc7Uoy3YSZLCT.svkwi khQByWnZXitLyxxs1EBXkX48OnnqCFQeZQ6rs6Wbwd1CvkZgj.fIWHcggWNg NqDXDtsHAUsh0JYiPu77V6tpTymtS1g7rTL7oF_7XRMTSFsZU4eNJFEkI.Td 55DgUt9WmRSL4LcufdiTTvpKFAzs62h63wfQQ9omDFfpuDEofgnLkjKaYGch YGfgzhKojF8HMsJVykjtMyUklAZapZitAgEROU0UX44rswp9Wqtlp07OzbBQ _SssZ1p8AAkbKNH8EfZ7jhWXvfWFCmw-- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 04 Jun 2013 06:59:57 PDT X-Rocket-MIMEInfo: 002.001, Pj5JZiB5b3UgZG9uJ3Qgd2FudCB0byBkbyBpdCBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIsIGFuIGFsdGVybmF0aXZlIHRoYXQgYWxzbyBkb2Vzbid0IGludm9sdmUgYWRkaW5nIGNvbXBsZXhpdHkgdG8gZ2VuZXJhbCBJbnRlcm5ldCBob3N0cyB3b3VsZCBiZSBhbiBJbnRlcm5ldC1sYXllciBoZWFkZXIgdGhhdCBpcyBub3QgaW1wbGVtZW50ZWQgaW4gc3RhbmRhcmQgSW50ZXJuZXQgaG9zdHMgYW5kID4.c3RhbmRhcmQgb3BlcmF0aW5nIHN5c3RlbXMsIGJ1dCBpcyBvbmx5IGltcGxlbWVudGVkIGJ5IGhvc3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Message-ID: <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 4 Jun 2013 06:59:57 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-675526451-1370354397=:17515" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:08:50 -0000 ---153701192-675526451-1370354397=:17515 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>If you don't want to do it at the application layer, an alternative that = also doesn't involve adding complexity to general Internet hosts would be a= n Internet-layer header that is not implemented in standard Internet hosts = and >>standard operating systems, but is only implemented by hosts in netwo= rks that need this functionality. Is that approach acceptable, or do you wa= nt this functionality to be part of every Internet-connected host?=0A=0AHow= might this work? =A0Our folks use Windows, Unix, etc just as all others do= .=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659= -8360=0Awww.insidethestack.com=0A=0A=0A=0A________________________________= =0A From: Lorenzo Colitti =0ATo: Nalini Elkins =0ACc: Bill Jouris ; "v6ops@ietf.org" =0ASent: Tuesday, June 4, 2013 12:00= AM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt= -needed=0A =0A=0A=0AOn Tue, Jun 4, 2013 at 12:38 PM, Nalini Elkins wrote:=0A=0A>>But on the other hand, implementin= g it at the Internet layer pushes this complexity to every host on the Inte= rnet, whereas this functionality is obviously targeted at private network d= eployments (since it cannot work anywhere else).=0A>=0A>=0A>This is an opti= onal header. =A0That means that a stack or operating system can be implemen= ted so that the default is to NOT send this header. =A0End of complexity.= =0A=0AWell, but complexity that is off by default is still complexity. Kern= el code has to be written to implement the header, testing must be done to = ensure it works, firewalls need to be modified to not drop it, and so on. T= his complexity can only be avoided by not implementing the header.=0A=0AIf = you implement the complexity above the Internet layer, then you don't need = to add complexity to the Internet layer and you can implement it at the app= lication layer only for those applications that need it. That way, the appl= ications implementing the complexity are also the ones getting the benefit.= =0A=0AIf you don't want to do it at the application layer, an alternative t= hat also doesn't involve adding complexity to general Internet hosts would = be an Internet-layer header that is not implemented in standard Internet ho= sts and standard operating systems, but is only implemented by hosts in net= works that need this functionality. Is that approach acceptable, or do you = want this functionality to be part of every Internet-connected host? ---153701192-675526451-1370354397=:17515 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>>If you don't want to do it at the a= pplication layer, an alternative that also doesn't involve adding complexit= y to general Internet hosts would be an Internet-layer header that is not i= mplemented in standard Internet hosts and >>standard operating system= s, but is only implemented by hosts in networks that need this functionalit= y. Is that approach acceptable, or do you want this functionality to be part of every= Internet-connected host?

How might this work? &nb= sp;Our folks use Windows, Unix, etc just as all others do.
 
Thanks,

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

Fr= om: Lorenzo Colitti <lorenzo@google.com>
To: Nalini Elkins <nalini.elkins@ins= idethestack.com>
Cc: Bill Jouris <bill.jouris@insidethestack.com>; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Tuesday, June 4, 2013 12:00 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-e= nd-to-end-rt-needed

= =0A
On Tue, Jun 4, 2013 at 12:38 = PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
=0A=0A
=0A=0A
>>But on the other hand, implementing it a= t the Internet layer pushes this complexity to every host on the Internet, = whereas this functionality is obviously targeted at private network deploym= ents (since it cannot work anywhere else).
=0A=0A

=
This is an optional header.  That means that a stack or operating= system can be implemented so that the default is to NOT send this header. =  End of complexity.
=0A=0A

Well, but complexity that is off by defa= ult is still complexity. Kernel code has to be written to implement the hea= der, testing must be done to ensure it works, firewalls need to be modified= to not drop it, and so on. This complexity can only be avoided by not impl= ementing the header.
=0A=0A

I= f you implement the complexity above the Internet layer, then you don't nee= d to add complexity to the Internet layer and you can implement it at the a= pplication layer only for those applications that need it. That way, the ap= plications implementing the complexity are also the ones getting the benefi= t.
=0A=0A

If you don't want t= o do it at the application layer, an alternative that also doesn't involve = adding complexity to general Internet hosts would be an Internet-layer head= er that is not implemented in standard Internet hosts and standard operatin= g systems, but is only implemented by hosts in networks that need this func= tionality. Is that approach acceptable, or do you want this functionality t= o be part of every Internet-connected host?
=0A=0A
= =0A


---153701192-675526451-1370354397=:17515-- From lorenzo@google.com Tue Jun 4 09:45:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A92121F9DC6 for ; Tue, 4 Jun 2013 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.037, 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 qvjF7rLEEj85 for ; Tue, 4 Jun 2013 09:45:31 -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 1040B21F9843 for ; Tue, 4 Jun 2013 07:29:47 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id k15so173760qcv.14 for ; Tue, 04 Jun 2013 07:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TRir+DSmwBjwacHFcJQR8ATyO1JyhbQFFz4iRgclDaA=; b=EsdfXM0LjSA7+FSLWRRWkH+nKAvENnUvqfjq0X8Y6TncSrFV2UKgbwm3vfFlVJTkje F8gTX3Gku4zOgs3TMU9aq61z2kt/u3QPHyqfoIQCB11t1sBb2wd1KRha0JmhNLQPp8T2 MHeLB3KczGIvrAEphPGDBeUeYv/BI/RRc3YVq2TLnLQwtJd9r/bBCYkajefGoZkmN7UB zVYf2EVHY1dL8Jv6RE2Kcv4HHXurg+xYqrtybItCqfS6HFg1vgBe1ZfVhco9vouCTzx5 RM+jYixyLEXZ9uEM4JmdwObo4TV1iRMHIDbnsK1cFKF8mX8DDG0vJ22KJx93hpQFkFS5 U9og== 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=TRir+DSmwBjwacHFcJQR8ATyO1JyhbQFFz4iRgclDaA=; b=XokT1puiOJEeNLuYtAMsdtsg63ZfFeKy4osJJI59B86xvQ2QpesoGLLT64v1RZE6+r 2s0Lgii+MDxK62QBmIGRhUo3pO4Cdp3tFPXMG5hKtEUR/FpRaC9OcPQQ+dLAgiHakEs2 T5hYgkzm0FTn9ZsqhX5zkL64XOb5kD+iDIm48mGGdNKHZqMRYVZhp0TVqrCU8afuN6SP rlJLy1GiiLqc4ad1+R/YN911TrGYrkf9J3Qnyks4nPvgyYIQSsf5PTe/DZOruPfX4odm rJz2NXw2kiJmWK9qGzb3EvcbRaspdFaWwGfDOcSgUUk2a1LYiJ69U6YM9ERqn2UCse2u Nh6A== X-Received: by 10.229.100.198 with SMTP id z6mr1342218qcn.3.1370356187330; Tue, 04 Jun 2013 07:29:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Tue, 4 Jun 2013 07:29:26 -0700 (PDT) In-Reply-To: <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> From: Lorenzo Colitti Date: Tue, 4 Jun 2013 23:29:26 +0900 Message-ID: To: "Ackermann, Michael" Content-Type: multipart/alternative; boundary=089e0160c958c3274404de54e962 X-Gm-Message-State: ALoCoQkWlpgRmSNIMqs6ycvPv46F2bt/TVdxw2IlX/tn8PJHO2w4CPgXqnQn8BiBWowlOThTyWQZiKE4BkHdD0T7e015V1VkYf+C2h9J0fNaX7+Ghgp0KoeXwnYaRqQvm/AJQiYGlAIwZhnuwP3OQRQY76p7fmWjN9nd1miUiDNNa8JfdH/5mrfCUrfeLGS1IH+/ino5U/x6 Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:45:45 -0000 --089e0160c958c3274404de54e962 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, Michael wrote: > If we are to assume that ALL Extension Headers are going to be > dropped then IPV6 has MUCH BIGGER issues than being addressed in this > draft. > I'm afraid that on the Internet, a lot of the time, they are: http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf --089e0160c958c3274404de54e962 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, Michael <MA= ckermann@bcbsm.com> wrote:

If we are to assume that ALL Extension Headers are going to be dro= pped then IPV6 has MUCH BIGGER issues than being addressed in this draft.= =A0


I'm afraid that on the Internet, a lot of the time, they are:

--089e0160c958c3274404de54e962-- From lorenzo@google.com Tue Jun 4 09:45:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2921F9BEF for ; Tue, 4 Jun 2013 09:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.035, 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 JoZIVlx7a2Lj for ; Tue, 4 Jun 2013 09:45:45 -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 E9B0521F96C2 for ; Tue, 4 Jun 2013 07:30:18 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id k15so176058qcv.0 for ; Tue, 04 Jun 2013 07:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rfU9EZ5557VxXQrFIYQ3fNzieK4mz6MErVLrJKiUW/E=; b=FT57fbezDgefhK3cim1xd4qqB5qyM3kvS1f/UgB0mchfQF5NWFv4fVqiXHCD7PLQVO 4l2oe1DFnBCVfSjkeGIBV1tlCr4V9vd60TlP8U7p22TyPHEGbB28oZGDE94FmuGoSAWq LtNNU85DMms8+yG1+r5dyOp0k82IlH+JGQCy5LPEhRzi536zs5dvkmBosMZYa/hXj5lM BRXVegVEkvaMKczFWguWdlZ16t/02VyqXZgDa6Auf1YyCHOjT014fIlkq3UIFboUKYMa sAtDkL2xzmAff9b21CLy9WDS6xRS0HoJNj9Q+6TQjAyubC/zgTeLNJeuy6lSLoEA53r0 ITwA== 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=rfU9EZ5557VxXQrFIYQ3fNzieK4mz6MErVLrJKiUW/E=; b=m2SPipe5LEmw+se6lO+T2ngS+z1FY1QHDKOR9IsNDtaumghdjD7U1wZOhMDOWCKNCu OCOdCtafGEhwPoQFp0wmPOYWInS6vDm3DBeHtB65Wy8X3QRjNCYN7xtAC4c9aWOBWDMH i5tfBKYxCGQljrZZ09QtEL16dKUr92sMkhFDwQ+T61MBPDOFxiEv7i05RbqBnB6bqaH5 54LwLtBOPmPvGB8wZluNJupED3VR9mHnyEJGBNIuF/1pGSRVXIMMBbZi8mibN1/ARZxa IqzmttB/oJqcCMcv6S1XNo65XEAt48VMGQXT4tn55AeBzRfkiUP1LDT0ou15TUp8Esdv jwTQ== X-Received: by 10.224.42.195 with SMTP id t3mr23188097qae.44.1370356218427; Tue, 04 Jun 2013 07:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Tue, 4 Jun 2013 07:29:58 -0700 (PDT) In-Reply-To: <4FC37E442D05A748896589E468752CAA0A776066@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <4FC37E442D05A748896589E468752CAA0A776066@PWN401EA160.ent.corp.bcbsm.com> From: Lorenzo Colitti Date: Tue, 4 Jun 2013 23:29:58 +0900 Message-ID: To: "Ackermann, Michael" Content-Type: multipart/alternative; boundary=089e0160bbb29dbaea04de54eb47 X-Gm-Message-State: ALoCoQnN38+u5Ns7tyTnhaO7dbYlXT7zqzrlNSqsIkciizcTDnsJgWCD7hiavVTXaA9zbYyeR5tY52wdwxVMT5u+k+cZveE0u1nAsusThPHObiJZQQ71KhUNAVN7f83Xx23muredm9iLrEGDyC6Ys08h8eQru2pQMMwgOT2iBhBBr9CM9OlOI3jU/dW+edzvQviE9fl1LGsy Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:45:55 -0000 --089e0160bbb29dbaea04de54eb47 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, Michael wrote: > As a diagnostic person, I would prefer this information to be in the Main > IP Header, as in IPV4. > Changing the IP header is not realistic. That ship sailed about 15 years ago. --089e0160bbb29dbaea04de54eb47 Content-Type: text/html; charset=ISO-8859-1
On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
As a diagnostic person, I would prefer this information to be in the Main IP Header, as in IPV4.

Changing the IP header is not realistic. That ship sailed about 15 years ago.
--089e0160bbb29dbaea04de54eb47-- From lorenzo@google.com Tue Jun 4 09:47:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0321F9058 for ; Tue, 4 Jun 2013 09:47:40 -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 iZtfIbMu+Otx for ; Tue, 4 Jun 2013 09:47:31 -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 9637E21F9CF2 for ; Tue, 4 Jun 2013 07:32:00 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id cr7so424650qab.18 for ; Tue, 04 Jun 2013 07:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3oBoW6XTUvQBvdpjjDcjOk6jNQBEIybh6p24djMKS9U=; b=AiNhlE4VELWHg9T0J6ZpFUBq6m3lqirOMn3BsXQwDLo1W6e/UK7TW4/lMGaadZMPy9 /pZ66idai/XunMhm8Vq7ffqbxrmoaxLc7HfFOompozmRom/8YC4KjDO53TI9HJp5JUEV ipi5LznhIsmvLRL9HbcYqK9B+cJKT/a85xVg1oimM9dr2l5jAbBayRvaF7BtxWuZmnOb mxLAarL6LCARCDodz9RU6kJqqr5UBXEFH2KC4l8DKqdrMD9DfsaLuZyzC1MjlVnewSru 4fGABavLjEcMnCBlue+67UuRnJ+M2qfC4yx3UzU+wHFivGIIjU5FTtE4sB59hNpgQMke DdpQ== 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=3oBoW6XTUvQBvdpjjDcjOk6jNQBEIybh6p24djMKS9U=; b=LuIG8SEpHe5E57qtuqagcMjMqMj8NjMEiEIWSLBmClQWPtXmiAJ8fQJOb06lz+MlUI mY1g2Hbq2l+iPNFKSF7yArB6AtbHIJZle2Ejjtbd720Ppsc/EpiZdfTvRlY1v4/VydJ8 47SKaGloJbmDw9BWTel+TQoG9B/mShVpgXtQ+higFap1DRfyElO6hGRAgFV4yeo5iLnq 7Aq+oHXhaVezYgePUgCJYV+h550lj84Io9IwDuofNSHeqkHGyrgvAtGKSIEeEp9uP1wS TZlYRTOJlA0UIWpdXngN9ILqVmGL2e6p/U/5n68L18QWe9g+AqavfCmcW3fZDJV59lIf Vz3g== X-Received: by 10.49.71.203 with SMTP id x11mr27564461qeu.19.1370356320053; Tue, 04 Jun 2013 07:32:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Tue, 4 Jun 2013 07:31:39 -0700 (PDT) In-Reply-To: <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Tue, 4 Jun 2013 23:31:39 +0900 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=047d7b6dc474ac4b2504de54f116 X-Gm-Message-State: ALoCoQm1G6w3RBmKUAm7MREDRP7+b0ZA470nrinmRDd6JEzE0JUVpDL43lYPKzCrwKAjxgH3gLC6dnAxtypxZNs/xoEEostvivgeYJWOsSN8OFGVeRWtF6x3z9rhOH+4SDavnbKOjGJBwsVa0q8is0/4KhYyiYZ7z7ZyYNwzdY+g1qRpWihRT55zDJgSRZrnp2tgN119Pb+u Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:47:40 -0000 --047d7b6dc474ac4b2504de54f116 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 10:59 PM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > >>If you don't want to do it at the application layer, an alternative > that also doesn't involve adding complexity to general Internet hosts would > be an Internet-layer header that is not implemented in standard Internet > hosts and >>standard operating systems, but is only implemented by hosts in > networks that need this functionality. Is that approach acceptable, or do > you want this functionality to be part of every Internet-connected host? > > How might this work? Our folks use Windows, Unix, etc just as all others > do. > So then it's the case that you want every host running one of these operating systems to support this functionality, just in case someone wants to use it? The bar for that is quite high. --047d7b6dc474ac4b2504de54f116 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 10:59 PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
>>If you don&#= 39;t want to do it at the application layer, an alternative that also doesn= 't involve adding complexity to general Internet hosts would be an Inte= rnet-layer header that is not implemented in standard Internet hosts and &g= t;>standard operating systems, but is only implemented by hosts in netwo= rks that need this functionality. Is that approach acceptable, or do you want this functionality to be part of every= Internet-connected host?

How might this wor= k? =A0Our folks use Windows, Unix, etc just as all others do.
So then i= t's the case that you want every host running one of these operating sy= stems to support this functionality, just in case someone wants to use it? = The bar for that is quite high.
--047d7b6dc474ac4b2504de54f116-- From shengjiang@gmail.com Tue Jun 4 09:48:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: manning bill Content-Type: multipart/alternative; boundary=089e01493c0e987a9704de54f380 Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 nalini.elkins@insidethestack.com Tue Jun 4 09:52:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BA121F9B0E for ; Tue, 4 Jun 2013 09:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 9o+H7PanV25U for ; Tue, 4 Jun 2013 09:52:15 -0700 (PDT) Received: from nm29-vm0.access.bullet.mail.mud.yahoo.com (nm29-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.255]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8AD21F9D7A for ; Tue, 4 Jun 2013 07:39:03 -0700 (PDT) Received: from [66.94.237.200] by nm29.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 14:39:02 -0000 Received: from [66.94.237.118] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 14:39:02 -0000 Received: from [127.0.0.1] by omp1023.access.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 14:39:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 964308.77218.bm@omp1023.access.mail.mud.yahoo.com Received: (qmail 58991 invoked by uid 60001); 4 Jun 2013 14:39:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370356742; bh=AXTyZ+iNIIeDJpeHGKwvUTnmh+NgH9ypghwo8ztSAYI=; 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=XLyhMgsESXRxLB2GUDBQx9enGukZy0vL0mQX0pF1Zgd99hNw8JDUmB+IQCAKwh36uO7lzlZ/xCt08yu1UV/Gi5zSc2upFjkS7CFZ9jcK00hNZV/G92FOKpVFvxxMJIlvMOZRlowriOi60LYc2ugeYF/QJr3Oc3iuWk0i9nGV3/w= X-YMail-OSG: L63c_bgVM1k3FRLADuBlS4N9Iz7xlF0q5C05yqiuf3s3GN5 6IeQafQY2UrSlh__Vi.5xk_2Mpmdq_oBp2eC6fkSwW3R3CzsJt0YvYL6gsp_ RSGG57VzM2gkPWDSs9R9qyaeAj1qRwydwqiOYVqQmt_4PeBbGJJunGArLrgj KboclUI0n0iN2As2yaIjFx7qSeEgRUUtO9CLqNREA2GWnTJW2uKUb2mvisD3 yNdrvFKZCtU5HSuv5KF7k274SP8U6B5Yj1FLdlxFfCM.oK_Yh62rZy75_Tlu fImW7oQtLM3_RPRvBdg37uaFr7zaUtJWgSIWtxdLQeDLHSrIKvv78ChfH5oV BPiwYM0sgiCXMEMUKGE6m3gHVmfXoGcxwee.dv3JaEbVnZAb1pTFH2Ywn28v 4kVZgG19tvtnIklSnSYJ4SM1ZlXcUxxfEj9xHKPjUEDeJWiVa4qdJCR9jJVW C8Pimi9luPvfDq29H.8qJtBE.RwEu4wA1LX4.kVakNq8m7PMapO97G8ewHtv mqD_7PYqnKOSLwVpHF6D5gvYH.hoyVSssKH7JQRMAV9tfwINd7Id6hW0ECVi NqrbwB4M9Y_L76o3EmXO0mmSEio67XCPDcz2HxkKw8LGuIKHNIp7p4ROAphg TZBWjaXlEeWazzRsQYCqFK2l9.PWNEQ-- Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Tue, 04 Jun 2013 07:39:02 PDT X-Rocket-MIMEInfo: 002.001, Pj4gU28gdGhlbiBpdCdzIHRoZSBjYXNlIHRoYXQgeW91IHdhbnQgZXZlcnkgaG9zdCBydW5uaW5nIG9uZSBvZiB0aGVzZSBvcGVyYXRpbmcgc3lzdGVtcyB0byBzdXBwb3J0IHRoaXMgZnVuY3Rpb25hbGl0eSwganVzdCBpbiBjYXNlIHNvbWVvbmUgd2FudHMgdG8gdXNlIGl0PyBUaGUgYmFyIGZvciB0aGF0IGlzIHF1aXRlIGhpZ2guCgoKSSBkb24ndCBrbm93IGFib3V0IHRoZSAianVzdCBpbiBjYXNlIi4gwqBNeSBmZWVsaW5nIGlzIHRoYXQgbWFueSBjb3Jwb3JhdGlvbnMgd2lsbCB3YW50IHRoaXMuCgpBY3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Message-ID: <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Tue, 4 Jun 2013 07:39:02 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-743646756-1370356742=:58824" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:52:30 -0000 ---1051860855-743646756-1370356742=:58824 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> So then it's the case that you want every host running one of these oper= ating systems to support this functionality, just in case someone wants to = use it? The bar for that is quite high.=0A=0A=0AI don't know about the "jus= t in case". =A0My feeling is that many corporations will want this.=0A=0AAc= tually, I was just working on a problem this morning with a customer not 10= minutes ago where they could have used this feature.=0A=0AIs the "bar" you= are talking about getting the stack vendors to implement? =A0If so, I have= already started discussions with some.=0A=A0=0AThanks,=0A=0A=0ANalini Elki= ns=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A= =0A=0A________________________________=0A From: Lorenzo Colitti =0ATo: Nalini Elkins =0ACc: Bil= l Jouris ; "v6ops@ietf.org" =0ASent: Tuesday, June 4, 2013 7:31 AM=0ASubject: Re: [v6ops] new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn Tue, Jun 4, 201= 3 at 10:59 PM, Nalini Elkins wrote:=0A= =0A>>If you don't want to do it at the application layer, an alternative th= at also doesn't involve adding complexity to general Internet hosts would b= e an Internet-layer header that is not implemented in standard Internet hos= ts and >>standard operating systems, but is only implemented by hosts in ne= tworks that need this functionality. Is that approach acceptable, or do you= want this functionality to be part of every Internet-connected host?=0A>= =0A>=0A>How might this work? =A0Our folks use Windows, Unix, etc just as al= l others do.=0ASo then it's the case that you want every host running one o= f these operating systems to support this functionality, just in case someo= ne wants to use it? The bar for that is quite high. ---1051860855-743646756-1370356742=:58824 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>> So then it's = the case that you want every host running one of these operating systems to= support this functionality, just in case someone wants to use it? The bar = for that is quite high.

I don= 't know about the "just in case".  My feeling is that many corporation= s will want this.

Actually, I wa= s just working on a problem this morning with a customer not 10 minutes ago= where they could have used this feature.

<= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: arial, helv= etica, sans-serif; background-color: transparent; font-style: normal;">Is the "bar" you are talking about getting the stack vendors to implement= ?  If so, I have already started discussions with some.
 
Thanks,

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

=20
From: Lorenzo C= olitti <lorenzo@google.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
= Cc: Bill Jouris <bill.j= ouris@insidethestack.com>; "v6ops@ietf.org" <v6ops@ietf.org>
= Sent: Tuesday, June 4, 201= 3 7:31 AM
Subject: Re:= [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0A
On Tue, Jun 4, 2013 at 10:59 PM, Nalini Elkins <na= lini.elkins@insidethestack.com> wrote:
=0A=0A
=0A=0A
=0A=0A
>>If you don't= want to do it at the application layer, an alternative that also doesn't i= nvolve adding complexity to general Internet hosts would be an Internet-lay= er header that is not implemented in standard Internet hosts and >>st= andard operating systems, but is only implemented by hosts in networks that= need this functionality. Is that=0A approach acceptable, or do you want th= is functionality to be part of every Internet-connected host?
How might this work?  Our folks use Windows, Unix, e= tc just as all others do.
=0A=0A
So then it's the case that you want = every host running one of these operating systems to support this functiona= lity, just in case someone wants to use it? The bar for that is quite high.=
=0A=0A
=0A


= ---1051860855-743646756-1370356742=:58824-- From owen@delong.com Tue Jun 4 10:16:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 Fred.L.Templin@boeing.com Tue Jun 4 10:23:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169E121F9B35 for ; Tue, 4 Jun 2013 10:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvGVzvYaAkzB for ; Tue, 4 Jun 2013 10:23:27 -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 5EB3721F9CD7 for ; Tue, 4 Jun 2013 08:39:49 -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 r54Fdb1M031089 for ; Tue, 4 Jun 2013 08:39:37 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r54FdbFa031084 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 4 Jun 2013 08:39:37 -0700 Received: from XCH-BLV-207.nw.nos.boeing.com (10.57.37.63) by XCH-NWHT-02.nw.nos.boeing.com (130.247.70.248) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 4 Jun 2013 08:39:37 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-207.nw.nos.boeing.com ([169.254.7.162]) with mapi id 14.02.0328.011; Tue, 4 Jun 2013 08:39:36 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: ISATAP Operational Guidance Thread-Index: AQHOXkM1cisG4pPmVkaNg2jUvvoAqpklssAg Date: Tue, 4 Jun 2013 15:39:36 +0000 Message-ID: <2134F8430051B64F815C691A62D98318097B2D@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: [v6ops] FW: ISATAP Operational Guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:23:32 -0000 Hello, There are millions of hosts in operational deployment today with ISATAP enabled by default. Those hosts try to enable ISATAP when there is no native IPv6 available, but administrative action is required to activate the service within the site. RFC 6964 now provides "Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)" (see below). It takes no position on whether the service should be activated, but provides guidance to administrators who are considering its use. The document is therefore offered to the community as an informational resource. Fred fred.l.templin@boeing.com=20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of rfc-editor@rfc-editor.org Sent: Friday, May 31, 2013 2:08 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: RFC 6964 on Operational Guidance for IPv6 Deployment in IPv4 Sites= Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) A new Request for Comments is now available in online RFC libraries. =20 RFC 6964 Title: Operational Guidance for IPv6 Deployment=20 in IPv4 Sites Using the Intra-Site=20 Automatic Tunnel Addressing Protocol (ISATAP)=20 Author: F. Templin Status: Informational Stream: Independent Date: May 2013 Mailbox: fltemplin@acm.org Pages: 20 Characters: 49568 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-templin-v6ops-isops-19.txt URL: http://www.rfc-editor.org/rfc/rfc6964.txt Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From bill.jouris@insidethestack.com Tue Jun 4 10:30:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9B321F9D30 for ; Tue, 4 Jun 2013 10:30:40 -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 XpdZyaZjmdN2 for ; Tue, 4 Jun 2013 10:30:33 -0700 (PDT) Received: from nm27.access.bullet.mail.sp2.yahoo.com (nm27.access.bullet.mail.sp2.yahoo.com [98.139.44.154]) by ietfa.amsl.com (Postfix) with ESMTP id B0DEC21F9E35 for ; Tue, 4 Jun 2013 08:49:59 -0700 (PDT) Received: from [98.139.44.98] by nm27.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jun 2013 15:49:46 -0000 Received: from [98.139.44.64] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jun 2013 15:49:46 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 04 Jun 2013 15:49:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 885764.87012.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 4327 invoked by uid 60001); 4 Jun 2013 15:49:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370360986; bh=B+4V5iN9E5zrnQbZvxt3hFkGAXwDEQ45YHAw+2Ga+rs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U8JmqgrjIeGv90gxON96qo+sB85ZxTb1hnxNohWnRDUGOdQUvYVNWdey+FG57EUuGdJiCkbGQTPHV02TOSroGV0MCsCfQOdqOtYfQh/yaEE25T2WjKl4akJ18i6phGdmNAPorUFRTq8iQefX11lHlGO1raSn/lt3myMC6EsuWPk= X-YMail-OSG: Nwk.KYkVM1nnip_6xHbWae_d0tlHhToXp4CohI0GjnyCEOH xV5ownRqX9N4hai2WIusRQWyQuTDEknJC_yzsFurZtJdJ1zo9qJpbTqsbhym X968PHsW8qUVsVOEiMkGCJQ9UqQx8Y.bAG4fxiZ7QNi4UtqyVq99CRPaGsRg NURtoNrr36Xbr2Q5HOUPIYZNnOH86.qL0mI06bDH3N7.yQbHW9OdyjWbIR1z ovLNZQygDbKnM3uov0RVZ09lmSkH62h03sC1HedqE1A5v_OgGw.EOzG9_4I2 aJAyVvX70Gdj3IP.B5QoP4bt7529xeoSbpUCI8JnTjillBAt8F4hoU9rWql1 LQzgMX9qVwzdvFw8rHAytmvetjoWDZiKssJoM.G3YQ2CsY80L2af7beZk3Ph iKu46tiSKo9sg3Z4xzU3wQibajNcNGMoy.0dxoO0GG5xX5rjL3KDLqpHZkG. jZyd8MeeINudR75uncO65xjecuDI6NsV6kdKZpe5tAmF7s.fBcIivL5Q8ClX zKW54Vy1lctakLKpoM6MlPFYQsYQqziMy67GeznKIZQ7MyyNfLzlZxg2JZVm bqvxFpD6ZsWm7dO5bydYdt_tigQ3KerKM4_m_wFXCWA7qsyxlZJy8IthzR1Y 9zQCOSMWUSSrzQLKJZIvgdQg- Received: from [50.148.178.232] by web2806.biz.mail.ne1.yahoo.com via HTTP; Tue, 04 Jun 2013 08:49:46 PDT X-Rocket-MIMEInfo: 002.001, LS0tIE9uIE1vbiwgNi8zLzEzLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4gd3JvdGU6DQoNCgoKCgo.IFAuUy46IEJlZm9yZSBhbnkgYXR0ZW1wdCBvbiB0aGlzIHBhdGgsIG9uZSBzaG91bGQgcHJvYmFibHkgYXNrOiBhcmUgd2UgDQo.IHN1cHBvZWQgdG8gaGF2ZSB0aGlzIGluZCBvZiBmdW5jdGlvbmFsaXR5IGF0IHRoZSBJbnRlcm5ldCBsYXllcj8gSXMgdGhpcyANCj4gd29ydGggdGhlIHBhaW4gZm9yIG1vc3QgaW1wbGVtZW50YXRpb25zPyBJcyB0aGlzIGdvaW5nIHRvIHdvcmsgaW4BMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.145.547 Message-ID: <1370360986.1548.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> Date: Tue, 4 Jun 2013 08:49:46 -0700 (PDT) From: Bill Jouris To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-540474736-1370360986=:1548" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:30:40 -0000 --1510626085-540474736-1370360986=:1548 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Mon, 6/3/13, Lorenzo Colitti wrote: =0A=0A=0A=0A> P.S.: Before any attempt on this path, one should probably as= k: are we=20 > suppoed to have this ind of functionality at the Internet layer? Is this= =20 > worth the pain for most implementations? Is this going to work in the=20 =0A=0A> general case, or is this going to be the subject of lots fo breakag= e?=20 > (e.g., packet drops) Fernando,=0A the problem with using any other layer is that it would requir= e =0Aimplementation across ALL of the various protocols.=A0 Which is far mo= re =0Adisruptive than this implementation in the IP layer would be.=20 =0A=0A But =0Aon the other hand, implementing it at the Internet layer pushes this= =0Acomplexity to every host on the Internet, whereas this functionality is= =0Aobviously targeted at private network deployments (since it cannot work= =0Aanywhere else). =0A=0A=0A Why do you assume that this functionality is targetted at private network d= eployments?=A0=20 Certainly it will be very useful there.=A0 But any company that does signif= icant business on-line is going to be interested in being able to see WHY t= heir customers are having problems or getting bad response when coming in o= ver the Internet.=A0 And that is also where they cannot rely on specialize = software (e.g. agents) being installed along the route between host and use= r, or at the user's node.=A0 Unless the information is available in the hea= der somewhere, they are blind. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --1510626085-540474736-1370360986=:1548 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
--- On Mon, 6/3/13, Lorenzo Colitti <= ;lorenzo@google.com> wrote:

=0A=0A
=0A=0A
> P.S.: Before any attempt on this path, one should pro= bably ask: are we
> suppoed to have this ind of functionality at the= Internet layer? Is this
> worth the pain for most implementations? = Is this going to work in the
=0A=0A> general case, or is this going = to be the subject of lots fo breakage?
> (e.g., packet drops)
Fernando,=0A the problem with using any other layer is that it would= require =0Aimplementation across ALL of the various protocols.  Which= is far more =0Adisruptive than this implementation in the IP layer would b= e.
=0A=0A

But =0Aon the other hand, implementing it at the Internet layer pus= hes this =0Acomplexity to every host on the Internet, whereas this function= ality is =0Aobviously targeted at private network deployments (since it can= not work =0Aanywhere else).
=0A=0A
=0A
Why do you assume that this functionality is targetted at priva= te network deployments? 

Certainly it will be very useful ther= e.  But any company that does significant business on-line is going to= be interested in being able to see WHY their customers are having problems= or getting bad response when coming in over the Internet.  And that i= s also where they cannot rely on specialize software (e.g. agents) being in= stalled along the route between host and user, or at the user's node. = Unless the information is available in the header somewhere, they are blin= d.

Bill Jouris
Inside Pr= oducts, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (dir= ect)

--1510626085-540474736-1370360986=:1548-- From Ted.Lemon@nominum.com Tue Jun 4 10:53:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: "" , "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 sthaug@nethelp.no Tue Jun 4 11:26:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC7721F9A4D for ; Tue, 4 Jun 2013 11:26:21 -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 dJ26SR68Mzxk for ; Tue, 4 Jun 2013 11:26:16 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 63D3521F9B7B for ; Tue, 4 Jun 2013 10:45:35 -0700 (PDT) Received: (qmail 47694 invoked from network); 4 Jun 2013 17:45:33 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Jun 2013 17:45:33 -0000 Date: Tue, 04 Jun 2013 19:45:33 +0200 (CEST) Message-Id: <20130604.194533.74723224.sthaug@nethelp.no> To: bill.jouris@insidethestack.com From: sthaug@nethelp.no In-Reply-To: <1370360986.1548.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> References: <1370360986.1548.YahooMailClassic@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:26:22 -0000 > Why do you assume that this functionality is targetted at private net= work deployments?=A0 = > = > Certainly it will be very useful there.=A0 But any company that does = significant business on-line is going to be interested in being able to= see WHY their customers are having problems or getting bad response wh= en coming in over the Internet.=A0 And that is also where they cannot r= ely on specialize software (e.g. agents) being installed along the rout= e between host and user, or at the user's node.=A0 Unless the informati= on is available in the header somewhere, they are blind. Are you sure the *customers* are interested in this? Speaking solely for myself, I feel that Google, Amazon, etc knows more than enough about me already. I don't wish to share more information. I= may be old-fashioned here... Steinar Haug, AS 2116 From mackermann@bcbsm.com Tue Jun 4 11:31:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C00121F9B7F for ; Tue, 4 Jun 2013 11:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.240, 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 068xVDBqgVOn for ; Tue, 4 Jun 2013 11:31:33 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 6F99421F9BAC for ; Tue, 4 Jun 2013 11:01:08 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 2DF9C9ADB67 for ; Tue, 4 Jun 2013 13:01:08 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 17A659ADB5C; Tue, 4 Jun 2013 13:01:07 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 9B3D32F0057; Tue, 4 Jun 2013 13:56:35 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 8DAA52F0055; Tue, 4 Jun 2013 13:56:35 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 4 Jun 2013 14:01:06 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%11]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 14:01:05 -0400 From: "Ackermann, Michael" To: Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOXfzaHn4XBQzX90KTpobgByNivpkgSnIAgADqggCAAA17gIADBo2AgAADMQCAAAhfgIABklwA///3mMA= Date: Tue, 4 Jun 2013 18:01:05 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A776318PWN401EA160entc_" MIME-Version: 1.0 Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:31:38 -0000 --_000_4FC37E442D05A748896589E468752CAA0A776318PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Understood. But that should change or at least the message should be = loud and clear, that this is not acceptable. In certain situations dropping EH's will be necessary and/or appropriate. = But as a general practice or default, it suggests that the IPV6 = architecture is flawed. I don't want to believe that. From: Lorenzo Colitti =5Bmailto:lorenzo=40google.com=5D Sent: Tuesday, June 04, 2013 10:29 AM To: Ackermann, Michael Cc: Nalini Elkins; Fernando Gont; v6ops=40ietf.org; = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, Michael = > wrote: If we are to assume that ALL Extension Headers are going to be dropped = then IPV6 has MUCH BIGGER issues than being addressed in this draft. I'm afraid that on the Internet, a lot of the time, they are: http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.= pdf The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A776318PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Understood.      But = that should change or at least the message should be loud and clear, that = this is not acceptable.    

 

In certain situations dropping EH&=238217;s = will be necessary and/or appropriate.   But as a general = practice or default, it suggests that the IPV6 architecture is flawed.      I don&=238217;t want to believe = that. 

 

From: Lorenzo Colitti =5Bmailto:lorenzo=40google.com=5D
Sent: Tuesday, June 04, 2013 10:29 AM
To: Ackermann, Michael
Cc: Nalini Elkins; Fernando Gont; v6ops=40ietf.org; = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=40tools.ietf.org
Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed

 

On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, = Michael <MAckermann=40bcbsm.com> wrote:

If we are to assume that ALL Extension = Headers are going to be dropped then IPV6 has MUCH BIGGER issues than = being addressed in this draft. 

 

I'm afraid that on the Internet, a lot of the = time, they are:

 


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

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

--_000_4FC37E442D05A748896589E468752CAA0A776318PWN401EA160entc_-- From mackermann@bcbsm.com Tue Jun 4 11:32:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CD521F9C57 for ; Tue, 4 Jun 2013 11:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 x2CIvREvbOMn for ; Tue, 4 Jun 2013 11:32:33 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE3721F9C49 for ; Tue, 4 Jun 2013 11:08:01 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 965849ADB47 for ; Tue, 4 Jun 2013 13:08:01 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id E114F9ADB41; Tue, 4 Jun 2013 13:08:00 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 71B922F0057; Tue, 4 Jun 2013 14:03:29 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 647652F004F; Tue, 4 Jun 2013 14:03:29 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 4 Jun 2013 14:08:00 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%11]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 14:07:59 -0400 From: "Ackermann, Michael" To: Lorenzo Colitti , Nalini Elkins Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOYG4EHn4XBQzX90KTpobgByNivpklDR0AgAAfDICAABbVAIAAlsuAgAAI24D///iKsA== Date: Tue, 4 Jun 2013 18:07:59 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A7773CD@PWN401EA160.ent.corp.bcbsm.com> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A7773CDPWN401EA160entc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:32:39 -0000 --_000_4FC37E442D05A748896589E468752CAA0A7773CDPWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess you could say only hosts for which availability, reliability and = performance are issues? In my world that is pretty much every host. I would like to see it at least be an option on every host. Some = Vendors can choose to not implement it, which may make their customers = less pleased. Customers can choose to not turn it on or turn it on = selectively, as appropriate. From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Lorenzo Colitti Sent: Tuesday, June 04, 2013 10:32 AM To: Nalini Elkins Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On Tue, Jun 4, 2013 at 10:59 PM, Nalini Elkins = > wrote: >>If you don't want to do it at the application layer, an alternative that = also doesn't involve adding complexity to general Internet hosts would be = an Internet-layer header that is not implemented in standard Internet = hosts and >>standard operating systems, but is only implemented by hosts = in networks that need this functionality. Is that approach acceptable, or = do you want this functionality to be part of every Internet-connected host? How might this work? Our folks use Windows, Unix, etc just as all others = do. So then it's the case that you want every host running one of these = operating systems to support this functionality, just in case someone = wants to use it? The bar for that is quite high. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A7773CDPWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

I guess you could say only hosts for which = availability, reliability and performance are = issues?       In my world that is pretty = much every host.  

 

I would like to see it at least be an option on = every host.       Some Vendors can choose to = not implement it, which may make their customers less = pleased.    Customers can choose to not turn it on or turn it on selectively, as = appropriate. 

 

From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Lorenzo Colitti
Sent: Tuesday, June 04, 2013 10:32 AM
To: Nalini Elkins
Cc: v6ops=40ietf.org
Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed

 

On Tue, Jun 4, 2013 at 10:59 PM, Nalini Elkins = <nalini.elkins=40insidethestack.com> = wrote:

>>If you don't want to do it at the = application layer, an alternative that also doesn't involve adding = complexity to general Internet hosts would be an Internet-layer header that is not implemented in standard Internet hosts and = >>standard operating systems, but is only implemented by hosts in = networks that need this functionality. Is that approach acceptable, or do = you want this functionality to be part of every Internet-connected host?

 

How might this work?  Our folks use = Windows, Unix, etc just as all others do.

So then it's the case that you want every host = running one of these operating systems to support this functionality, just = in case someone wants to use it? The bar for that is quite = high.


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

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

--_000_4FC37E442D05A748896589E468752CAA0A7773CDPWN401EA160entc_-- From nick@inex.ie Tue Jun 4 11:36:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7C021F962D for ; Tue, 4 Jun 2013 11:36:10 -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 vSWYOh6jbys7 for ; Tue, 4 Jun 2013 11:36:09 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7170921F961F for ; Tue, 4 Jun 2013 11:20:55 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r54IKnpK030426 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 19:20:49 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51AE3001.7040905@inex.ie> Date: Tue, 04 Jun 2013 19:20:49 +0100 From: Nick Hilliard 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: Nalini Elkins References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> In-Reply-To: <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:36:10 -0000 On 04/06/2013 15:39, Nalini Elkins wrote: > Actually, I was just working on a problem this morning with a customer not > 10 minutes ago where they could have used this feature. Nalini, we understand that the concept is useful. You've proposed two methods so far which don't seem to be runners: - modifying the ipv6 header: ain't gonna happen. The moment you change the header, it's no longer ipv6. - adding an extension header: which has been roundly trashed because extension headers cause serious operational difficulties. Can we park these two ideas and move on? Everyone is arguing in circles and the entire conversation has rat-holed once more. Nick From nalini.elkins@insidethestack.com Tue Jun 4 11:41:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190CC21F8F2C for ; Tue, 4 Jun 2013 11:41:10 -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.100, 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 CeOtiYrhxLcz for ; Tue, 4 Jun 2013 11:41:04 -0700 (PDT) Received: from nm2.access.bullet.mail.mud.yahoo.com (nm2.access.bullet.mail.mud.yahoo.com [66.94.237.203]) by ietfa.amsl.com (Postfix) with ESMTP id A492B21F9C0E for ; Tue, 4 Jun 2013 11:32:28 -0700 (PDT) Received: from [66.94.237.195] by nm2.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 18:32:28 -0000 Received: from [66.94.237.101] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 18:32:28 -0000 Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 04 Jun 2013 18:32:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 86367.44475.bm@omp1006.access.mail.mud.yahoo.com Received: (qmail 34369 invoked by uid 60001); 4 Jun 2013 18:32:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370370747; bh=qLHRseis33OmiBMg3w4yz/6ZaNS3WXx65OKsF2vBhO4=; 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=o0612KPYq3St96kgkFGS6t03s9Ly7J711KKBDwyWGy8MhVHdXG6tPmGUplR2AzelG1Nq0WW30Ab7g4u788KB3/ld6RSB3USdOh1YG4LkTyjS9E1jmgDpVQhGyCk5MXxJF8t0SSU6uBGG+pO0kVDGajyNofdHRpwcbo4h9zUvSic= X-YMail-OSG: NsXeZ_AVM1nGU8q_nvixQd54_Whz502PDXmRw3T1YAwC5wW HwmQbNehYQltTrZQHsgW3vn1T1jSGdvngnVffg0Xxl_jZMLZVx7Cz7an7zxB tbgolmVVAVhAvB2VNP7aOeTAnfkM3Ld2v8X16tNKF1NjZ3gbH1n65NGeRHWf p3vafExdriuxmhBWEsATbyN3xiJXGNRtNiKAiU7BUge2Jq6E.ttrphEcZu2q QCinbEuOAau60xvoe_22tFQ1B2ch0DfL.cm1VD.F4HuGqsYMbxHyrT3tCsyB eiN_4BHZXLOgNtBMIVPPIPQ2.IYd3jppJGsM1lmYqLhcoQwhcfHrdHxzaN44 hROGgTL1RtPpCmdhrs0hEyQvUD70Pcv7.SzJ_Cfro41ZXB0Au6XcDqBq_aGU mynD0oTnVSzcxFqjQIMswz4a5Gpt5MJnwFhBd_hgzcbdvKk3B.DunltjVePy 55i3ebW1.l5VFB.YCQROXVBB1tbAMgYywvwvSs0dXXXPAZzNK9sxzIq1ZBKQ 0KsnNt42mubj4KBKXPT6b1dO_4J6kmJT7hLmGbptDIeS3VDutbq_NfZxqYUx qVle.EgeGNb.pomHdrfmULAgv66jkVodss1VoSaFf2Zi.j4rIDNqLEXr1Duz 5kCytPQc.g_9hqggI68AdmK8wneOodg-- Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Tue, 04 Jun 2013 11:32:27 PDT X-Rocket-MIMEInfo: 002.001, Pj4gYWRkaW5nIGFuIGV4dGVuc2lvbiBoZWFkZXI6IHdoaWNoIGhhcyBiZWVuIHJvdW5kbHkgdHJhc2hlZCBiZWNhdXNlCj4.wqBleHRlbnNpb24gaGVhZGVycyBjYXVzZSBzZXJpb3VzIG9wZXJhdGlvbmFsIGRpZmZpY3VsdGllcy4KCgoKSXMgdGhpcyBJRVRGIGNvbnNlbnN1czogSVB2NiBleHRlbnNpb24gaGVhZGVycyBzaG91bGQgbm8gbG9uZ2VyIGJlIHVzZWQ_CgpNYXliZSB0aGVuLCBhbGwgdGhlIFJGQ3MgbmVlZCB0byBiZSB1cGRhdGVkLiDCoCBMZXQncyBzdGFydCB3aXRoIFJGQzI0NjAgLS0gYWxsIGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> Message-ID: <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Tue, 4 Jun 2013 11:32:27 -0700 (PDT) From: Nalini Elkins To: Nick Hilliard In-Reply-To: <51AE3001.7040905@inex.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1873424959-1370370747=:32298" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:41:10 -0000 --1510626085-1873424959-1370370747=:32298 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> adding an extension header: which has been roundly trashed because=0A>>= =A0extension headers cause serious operational difficulties.=0A=0A=0A=0AIs = this IETF consensus: IPv6 extension headers should no longer be used?=0A=0A= Maybe then, all the RFCs need to be updated. =A0 Let's start with RFC2460 -= - all extension headers are henceforth deprecated. =A0 Who is going to take= this on?=0A=0AIs this what we are saying? =A0AH and ESP too? =A0Why not go= backwards and take them out in IPv4 as well?=0A=0A=0AThanks,=0A=0A=0ANalin= i Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com= =0A=0A=0A=0A________________________________=0A From: Nick Hilliard =0ATo: Nalini Elkins =0ACc: Loren= zo Colitti ; "v6ops@ietf.org" =0ASent:= Tuesday, June 4, 2013 11:20 AM=0ASubject: Re: [v6ops] new draft: draft-elk= ins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0AOn 04/06/2013 15:39, Nalini El= kins wrote:=0A> Actually, I was just working on a problem this morning with= a customer not=0A> 10 minutes ago where they could have used this feature.= =0A=0ANalini,=0A=0Awe understand that the concept is useful.=0A=0AYou've pr= oposed two methods so far which don't seem to be runners:=0A=0A- modifying = the ipv6 header: ain't gonna happen.=A0 The moment you change the=0Aheader,= it's no longer ipv6.=0A=0A- adding an extension header: which has been rou= ndly trashed because=0Aextension headers cause serious operational difficul= ties.=0A=0ACan we park these two ideas and move on?=A0 Everyone is arguing = in circles=0Aand the entire conversation has rat-holed once more.=0A=0ANick --1510626085-1873424959-1370370747=:32298 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>> adding an extension header: which has been r= oundly trashed because
>>&= nbsp;extension headers cause ser= ious operational difficulties.


Is this IETF consensus= : IPv6 extension headers should no longer be used?

Maybe then, all the RFCs need to be updated.   Let's start wit= h RFC2460 -- all extension headers are henceforth deprecated.   Who is= going to take this on?

Is this what we ar= e saying?  AH and ESP too?  Why not go backwards and take them ou= t in IPv4 as well?

<= span>
Thanks,

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

<= font size=3D"2" face=3D"Arial"> From:<= /span> Nick Hilliard <nick@inex.ie>
To: Nalini Elkins <nalini.elkins@insidethestack.= com>
Cc: Lorenzo Co= litti <lorenzo@google.com>; "v6ops@ietf.org" <v6ops@ietf.org> <= br> Sent: Tuesday, June 4, 2013 11:20 = AM
Subject: Re: [v6ops= ] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0AOn 04/06/2013 15:39, Nalini Elkins = wrote:
> Actually, I was just working on a problem this morning with = a customer not
> 10 minutes ago where they could have used this featu= re.

Nalini,

we understand that the concept is useful.

= You've proposed two methods so far which don't seem to be runners:

-= modifying the ipv6 header: ain't gonna happen.  The moment you change= the
header, it's no longer ipv6.

- adding an extension header: w= hich has been roundly trashed because
extension headers cause serious op= erational difficulties.

Can we park these two ideas and move on?&nbs= p; Everyone is arguing in circles
and the entire conversation has rat-ho= led once more.

Nick



--1510626085-1873424959-1370370747=:32298-- From mackermann@bcbsm.com Tue Jun 4 12:52:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B8321F9B00 for ; Tue, 4 Jun 2013 12:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.128, 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 s1f+JQODu62y for ; Tue, 4 Jun 2013 12:51:58 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id AA45921F9AAD for ; Tue, 4 Jun 2013 11:54:38 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 17A992FF755 for ; Tue, 4 Jun 2013 13:54:38 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 98102307505; Tue, 4 Jun 2013 13:54:37 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 258D72F0051; Tue, 4 Jun 2013 14:50:06 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 169E22F0043; Tue, 4 Jun 2013 14:50:06 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 14:54:36 -0400 From: "Ackermann, Michael" To: "sthaug@nethelp.no" , "bill.jouris@insidethestack.com" Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOYG4EHn4XBQzX90KTpobgByNivpklDR0AgADrWwCAACBZgP//z+RQ Date: Tue, 4 Jun 2013 18:54:36 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A777681@PWN401EA160.ent.corp.bcbsm.com> References: <1370360986.1548.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> <20130604.194533.74723224.sthaug@nethelp.no> In-Reply-To: <20130604.194533.74723224.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 19:52:04 -0000 I don't see this as providing more information about YOU, per say. But = rather more about the performance of your IP packets. NO protected or = personal information as we say in my field. =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of sthaug=40nethelp.no Sent: Tuesday, June 04, 2013 1:46 PM To: bill.jouris=40insidethestack.com Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed > Why do you assume that this functionality is targetted at private=20 > network deployments? >=20 > Certainly it will be very useful there.=A0 But any company that does = significant business on-line is going to be interested in being able to = see WHY their customers are having problems or getting bad response when = coming in over the Internet.=A0 And that is also where they cannot rely on = specialize software (e.g. agents) being installed along the route between = host and user, or at the user's node.=A0 Unless the information is = available in the header somewhere, they are blind. Are you sure the *customers* are interested in this? Speaking solely for myself, I feel that Google, Amazon, etc knows more = than enough about me already. I don't wish to share more information. I = may be old-fashioned here... Steinar Haug, AS 2116 _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From gert@space.net Tue Jun 4 14:42:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54A21F8B21 for ; Tue, 4 Jun 2013 14:42: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 ROdRBC9mkoST for ; Tue, 4 Jun 2013 14:42:52 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id B34D721F9B9E 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 A286460A81 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 784D760A69 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 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:42:52 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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: "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 nick@inex.ie Tue Jun 4 14:49:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA76D21F8168 for ; Tue, 4 Jun 2013 14:49:13 -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 RnSHOcTJNVQ9 for ; Tue, 4 Jun 2013 14:49:13 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4AD21F90BB for ; Tue, 4 Jun 2013 14:49:09 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r54Ln4SD031333 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 22:49:05 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51AE60CF.6000709@inex.ie> Date: Tue, 04 Jun 2013 22:49:03 +0100 From: Nick Hilliard 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: Nalini Elkins References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:49:14 -0000 On 04/06/2013 19:32, Nalini Elkins wrote: > Is this IETF consensus: IPv6 extension headers should no longer be used? The ietf hasn't deprecated them, but as you can see from the reaction in this group, the operator community doesn't like them because they cause serious operational difficulties. The IETF won't deprecate them either, because there are as many people who think they are wonderful as think they are a disaster. If this discussion opened up, consensus would not be achieved either way. There is no point going there. > Maybe then, all the RFCs need to be updated. Let's start with RFC2460 -- > all extension headers are henceforth deprecated. Who is going to take > this on? > > Is this what we are saying? AH and ESP too? Why not go backwards and take > them out in IPv4 as well? With regard to ipv6, they are a royal pain - AH and ESP included. As an aside, for ipv4 I would dearly love to see AH deprecated in favour of ESP (see draft-bhatia-ipsecme-avoiding-ah for why); alas there is a noisy crowd in the ipsec working group which won't are fully intent on blocking this sensible move. I won't bore you with the details, but you can read all about it on the ietf ipsec mailing list. ESP/ipv4 is fine - it's easily handled by firewalls because you can run a simple bitfield comparison on the incoming packet. ESP is protocol 50 and this ID is located in bits 72-79 in ipv4. You can check for this really fast in hardware and as the packet is encrypted anyway, there is no point inspecting further inside the payload, which means that your forwarding engine can handle this very quickly. All of which point to the core problem of extension headers: they use TLVs. This was one of these things that seemed like a good idea at the time, way back in 1995. People had realised that one of the annoying limitations of ipv4 was that the header used a fixed-length construct and it was difficult to extend the protocol. So a TLV structure was devised to allow arbitrary headers to be attached to an ipv6 packet. This seemed sensible, because most packet forwarding was done in software and it was relatively easy to write code to inspect deep into packets - in software. Also, for the most part, people were more interested in forwarding packets than not forwarding packets. But as time moved on, more and more forwarding decisions got moved to ASICs and NPUs, and these had more limitations, particularly with regard to packet structures which were difficult to parse, especially on ASICs. E.g. lots of silicon today will perform a forwarding lookup based on only the first N octets of the header, and if your extension header falls outside that lookup window, it will not be parsed in the forwarding path. Your options are to drop regardless, to forward regardless or to punt to a slow cpu. I'm not sure which is the least broken of these options. We don't have widespread silicon which can make forwarding decisions based on arbitrary TLV structures, because that would mean inspecting ipv6 packets of pretty much arbitrary length. I'm not saying it doesn't exist - there are some chipsets and NPUs out there which will do this, but they are not the norm. Also, given that we're having trouble building hardware to meet the demands of current forwarding requirements, I don't think we're going to see tlv processing on 100ge / 400ge any time soon, although no doubt it will happen at some stage. Many firewall stacks have not bothered to implement proper stacked EH processing because it's hard to do right. And network operators don't necessarily understand how they operate either, which means that you will often end up with misconfigured firewalls which block EHs to an even greater extent than firewall operators currently block e.g. ICMP today. This leaves us in the awkward position that we've got this great protocol which is too cool to actually work at the sorts of speed that we expect from ipv4, and with the same feature levels. Maybe it will work one day when we get forwarding path feature parity with ipv4 at the speeds we need. Until then, they are a gross inconvenience which cause identifiable and serious operational problems. Nick From brian.e.carpenter@gmail.com Tue Jun 4 15:17:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62ED21F99AF for ; Tue, 4 Jun 2013 15:17:37 -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 uyqoFSBehXVV for ; Tue, 4 Jun 2013 15:17:32 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id DA79621F9993 for ; Tue, 4 Jun 2013 15:17:32 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w16so856193pde.23 for ; Tue, 04 Jun 2013 15:17:32 -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=WCml94gSWDCdZc91ADH2R5zwIGbm9n4eqjNsTDPtpI4=; b=ha4yOLNrmdyRitHBZy5h6xQ0EGe2Nv+iGI/mZ76s4dRDWI/q8F1ZGSlR5Ri5XDMeA5 shWHYhbzVqhNjYEcfl8W5cNffS3TXOXmurwf3Vus7f4CrVMSYXlV1Nrg41z8tiG52X3I Zg/JP1Ii0jQ8As7DoXJkVL4lrLMVMN1Uk1NihpAXhunnZ9B9z66S62RjShIuytXIoB0p 53LAcdDZQSbPAZW7oKSicC/2qNw34i4Oes49bLF3BfRDB/nOk+T5USRo4T2ax+U47yYI LZUC6MDoMIYQqf/gCpdjE7xfbC+pixxKok08L1i3JTf9fiNYjRlTZxnAPRBFQ8Stq/Oq IMRw== X-Received: by 10.66.251.101 with SMTP id zj5mr30694012pac.122.1370384252541; Tue, 04 Jun 2013 15:17:32 -0700 (PDT) Received: from [172.23.65.85] (wireless-nat-5.auckland.ac.nz. [130.216.30.116]) by mx.google.com with ESMTPSA id cr3sm8465047pac.0.2013.06.04.15.17.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 15:17:31 -0700 (PDT) Message-ID: <51AE6779.8080605@gmail.com> Date: Wed, 05 Jun 2013 10:17:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> In-Reply-To: <51AE60CF.6000709@inex.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 22:17:38 -0000 On 05/06/2013 09:49, Nick Hilliard wrote: > On 04/06/2013 19:32, Nalini Elkins wrote: >> Is this IETF consensus: IPv6 extension headers should no longer be used? > > The ietf hasn't deprecated them, but as you can see from the reaction in > this group, the operator community doesn't like them because they cause > serious operational difficulties. The IETF won't deprecate them either, > because there are as many people who think they are wonderful as think they > are a disaster. If this discussion opened up, consensus would not be > achieved either way. There is no point going there. Not there exactly, but see https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit/ because we can't leave things as messy as they are. (If you want to discuss that draft, please do so on the 6man list. It's intended to allow firewalls to do what they need to do, *and* to allow standardised extensions to actually get deployed. That's a narrow line to tread, as this thread has illustrated.) Brian From nick@inex.ie Tue Jun 4 15:44:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0017C21F9936 for ; Tue, 4 Jun 2013 15:44:41 -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 gCfz1zx1kYjB for ; Tue, 4 Jun 2013 15:44:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9D21F9923 for ; Tue, 4 Jun 2013 15:44:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r54MiXgn031588 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 23:44:35 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51AE6DD0.9030407@inex.ie> Date: Tue, 04 Jun 2013 23:44:32 +0100 From: Nick Hilliard 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: Brian E Carpenter References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <51AE6779.8080605@gmail.com> In-Reply-To: <51AE6779.8080605@gmail.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 22:44:42 -0000 On 04/06/2013 23:17, Brian E Carpenter wrote: > Not there exactly, but see > https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit/ > because we can't leave things as messy as they are. > (If you want to discuss that draft, please do so on the 6man list. > It's intended to allow firewalls to do what they need to do, *and* > to allow standardised extensions to actually get deployed. That's > a narrow line to tread, as this thread has illustrated.) there's also draft-ietf-6man-nd-extension-headers, which encourages safe use of extension headers for ND stuff; and rfc6564, which attempts to limit future damage. The underlying theme of all these documents is that extension headers cause trouble. Nick From bmanning@isi.edu Tue Jun 4 06:49:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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 X-Mailman-Approved-At: Tue, 04 Jun 2013 16:22:03 -0700 Cc: ipv6@ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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) 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 X-Mailman-Approved-At: Tue, 04 Jun 2013 16:22:06 -0700 Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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) 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 X-Mailman-Approved-At: Tue, 04 Jun 2013 16:22:07 -0700 Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 mackermann@bcbsm.com Tue Jun 4 16:34:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4A21F9920 for ; Tue, 4 Jun 2013 16:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 Utqmcs1NPYTH for ; Tue, 4 Jun 2013 16:34:40 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id E245221F8F78 for ; Tue, 4 Jun 2013 16:34:39 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id A3CFC2FF6BB for ; Tue, 4 Jun 2013 18:34:38 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 2EA9F307469; Tue, 4 Jun 2013 18:34:38 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 34B972F004D; Tue, 4 Jun 2013 19:30:06 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 2B55F2F0043; Tue, 4 Jun 2013 19:30:06 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 4 Jun 2013 19:34:37 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%11]) with mapi id 14.01.0438.000; Tue, 4 Jun 2013 19:34:36 -0400 From: "Ackermann, Michael" To: Nick Hilliard , Nalini Elkins Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOYG4EHn4XBQzX90KTpobgByNivpklDR0AgAAfDICAABbVAIAAlsuAgAAI24CAAAIRAIAAPfeA///XvuA= Date: Tue, 4 Jun 2013 23:34:35 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A7777B9@PWN401EA160.ent.corp.bcbsm.com> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> In-Reply-To: <51AE3001.7040905@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:34:44 -0000 What are the serious operational difficulties caused by extension headers? = =20 And are not extension headers an intrinsic component of IPV6? =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Nick Hilliard Sent: Tuesday, June 04, 2013 2:21 PM To: Nalini Elkins Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On 04/06/2013 15:39, Nalini Elkins wrote: > Actually, I was just working on a problem this morning with a customer=20 > not > 10 minutes ago where they could have used this feature. Nalini, we understand that the concept is useful. You've proposed two methods so far which don't seem to be runners: - modifying the ipv6 header: ain't gonna happen. The moment you change = the header, it's no longer ipv6. - adding an extension header: which has been roundly trashed because = extension headers cause serious operational difficulties. Can we park these two ideas and move on? Everyone is arguing in circles = and the entire conversation has rat-holed once more. Nick _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From joelja@bogus.com Tue Jun 4 16:41:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9518821F8F41 for ; Tue, 4 Jun 2013 16:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.866 X-Spam-Level: X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=0.133, 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 g46aLPCF6HUE for ; Tue, 4 Jun 2013 16:41:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1D37621F8F2C for ; Tue, 4 Jun 2013 16:41:13 -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 r54NfD1T014367 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 4 Jun 2013 23:41:13 GMT (envelope-from joelja@bogus.com) Message-ID: <51AE7B14.1010307@bogus.com> Date: Tue, 04 Jun 2013 16:41:08 -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: Nick Hilliard , Nalini Elkins References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> In-Reply-To: <51AE60CF.6000709@inex.ie> 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, 04 Jun 2013 23:41:13 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:41:14 -0000 On 6/4/13 2:49 PM, Nick Hilliard wrote: > But as time moved on, more and more forwarding decisions got moved to ASICs > and NPUs, and these had more limitations, particularly with regard to > packet structures which were difficult to parse, especially on ASICs. E.g. > lots of silicon today will perform a forwarding lookup based on only the > first N octets of the header, and if your extension header falls outside > that lookup window, it will not be parsed in the forwarding path. Other possible consequences of a longer header chain are packet take a different path than a flow with a shorter one due to L4 header contribution hashing/ecmp decision making not being able to find it. Some ACLs either can't be applied (bad) because the L4 header falls outside of the parseable N octets of the packet or policy drops the packet because the L4 header can't be found (also bad). > Your > options are to drop regardless, to forward regardless or to punt to a slow > cpu. I'm not sure which is the least broken of these options. > > We don't have widespread silicon which can make forwarding decisions based > on arbitrary TLV structures, because that would mean inspecting ipv6 > packets of pretty much arbitrary length. I'm not saying it doesn't exist - > there are some chipsets and NPUs out there which will do this, but they are > not the norm. Also, given that we're having trouble building hardware to > meet the demands of current forwarding requirements, I don't think we're > going to see tlv processing on 100ge / 400ge any time soon, although no > doubt it will happen at some stage. > > Many firewall stacks have not bothered to implement proper stacked EH > processing because it's hard to do right. And network operators don't > necessarily understand how they operate either, which means that you will > often end up with misconfigured firewalls which block EHs to an even > greater extent than firewall operators currently block e.g. ICMP today. > > This leaves us in the awkward position that we've got this great protocol > which is too cool to actually work at the sorts of speed that we expect > from ipv4, and with the same feature levels. Maybe it will work one day > when we get forwarding path feature parity with ipv4 at the speeds we need. > Until then, they are a gross inconvenience which cause identifiable and > serious operational problems. > > Nick > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shengjiang@gmail.com Tue Jun 4 16:44:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: manning bill Content-Type: multipart/alternative; boundary=e89a8f83a659c84e4404de5ca9b3 Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 joelja@bogus.com Tue Jun 4 16:55:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D0721F994D for ; Tue, 4 Jun 2013 16:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[AWL=0.100, 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 KobMe1QDipjd for ; Tue, 4 Jun 2013 16:55:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6521F994C for ; Tue, 4 Jun 2013 16:55:37 -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 r54NtXD1014522 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 4 Jun 2013 23:55:33 GMT (envelope-from joelja@bogus.com) Message-ID: <51AE7E70.6000008@bogus.com> Date: Tue, 04 Jun 2013 16:55:28 -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: "Ackermann, Michael" , Nick Hilliard , Nalini Elkins References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <4FC37E442D05A748896589E468752CAA0A7777B9@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A7777B9@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 04 Jun 2013 23:55:34 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:55:38 -0000 On 6/4/13 4:34 PM, Ackermann, Michael wrote: > What are the serious operational difficulties caused by extension headers? http://tools.ietf.org/html/draft-wkumari-long-headers-00 > > > And are not extension headers an intrinsic component of IPV6? I'd say the fragmentation header is too... http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 but we have issues. > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard > Sent: Tuesday, June 04, 2013 2:21 PM > To: Nalini Elkins > Cc: v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed > > On 04/06/2013 15:39, Nalini Elkins wrote: >> Actually, I was just working on a problem this morning with a customer >> not >> 10 minutes ago where they could have used this feature. > Nalini, > > we understand that the concept is useful. > > You've proposed two methods so far which don't seem to be runners: > > - modifying the ipv6 header: ain't gonna happen. The moment you change the header, it's no longer ipv6. > > - adding an extension header: which has been roundly trashed because extension headers cause serious operational difficulties. > > Can we park these two ideas and move on? Everyone is arguing in circles and the entire conversation has rat-holed once more. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shengjiang@gmail.com Tue Jun 4 16:55:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: Sheng Jiang To: Gert Doering Content-Type: multipart/alternative; boundary=089e014943089fc70d04de5cd09f Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFCF21F9944 for ; Tue, 4 Jun 2013 19:15:16 -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 20cpYlx7n9Sz for ; Tue, 4 Jun 2013 19:15:15 -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 091C721F8FAF for ; Tue, 4 Jun 2013 19:15:06 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id o13so3024975qaj.18 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=dmsfScnPRUkrdIa2mRChk7LxJU4p1jnRjTeiiwcV9aXFYjaNVBXk7ZtnOhrx3m96rK vOKFgcLQKV8dCbIqpeMAMQqoRJ9tfqLgkx14KX4B0jNTP/0Q3Tz6Ju4z3DVX3v3om5Cq FQEw8z6yDOm8srVzJINksa6qhA530AzWyvpD7N0uNqZ1cun4K1qPYVt5ZN/ClHNcvuzl NeP/pKR3WnqVNaQfK3I66qsc2yxFnavmaJke/gnggquLwyoij+QzSRDN19avXr5YbmcI hXM8VTxx7yuCCjZZatqp6zyOGWjyQTDtTDTJKASzIrz/fFNtLFS8I0ThIb0nJQflxwhD KHPg== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae9472d5b3e2a1004de5ec3da X-Gm-Message-State: ALoCoQlo0iadRKRiEPnRup7hyJb/dCL4nuK/sbR6GjYlWiE1UcsYo1rrK6d1vK94DfEgMO6ga7nDY43xeRkTiKsrqaOgePZ/P5C/MgZUdfBWdL/ZvaBK5b2s9YwNGf05EXYRhh/cGgnYcpaVdF5qAozD8Q68TNOKoS7YIZEM7u5cwWDD52QmhVZLTY+jwQRlalpPWSc5IS/T Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:15:18 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0995921F9B35 for ; Tue, 4 Jun 2013 19:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.133, 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 d+3TWYv05QCx for ; Tue, 4 Jun 2013 19:53:54 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id B98C021F9B27 for ; Tue, 4 Jun 2013 19:53:53 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id w7so722489qeb.19 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=dKMaA28mJugeBDNOIywn1tNdwjYvnzF+70VcCLcZsnXsY8b19uNPYfaBwCyzWkIlQV 9W6SBncENx0WilhbYShO4LdbS/QvsurlCoqrxVWsP3iVwEcssgSDDQBaoRAPlxjB5AXJ dfZvUNByiz1UPrq/2VNoWgkVuC0PdjZSCtb0ghZHAtaNhR/ZMZGlu4uKw9jDktecmuHM Vs2EwodccP8dT7Qeg3HQAqfyB1b5YQhjh3QBmznwGGvI8XBZEqVq5nU8mcZrjnUbVgbl rDVuhXJ2K5MFC8q1SECbAs6YTQ/qlPpR1o1NysKh2IbnKD4F0hY7ovNF42vGc1oIoG0I ew+g== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b6da828dbb35304de5f4ed2 X-Gm-Message-State: ALoCoQmOqcmL1eYAasYeKgVUtrAkb33tyYK8sSGtZOPfeOWnFTm6P3DtBpEMHui8Pex9PnozXHDJyW6+JwaawQHsoruOg2wC5340ylX7DSb59u4lPqK61T3L4ymXkrDI1n27ajUVSxR0YaF6g2UolsF1N75iwRrrGqNdA87QVWOansawr3v59k59jk7HjRig5ajyXCSwY3ge Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:53:59 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8E221F9B3D 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 9JdmzUMj46KC for ; Tue, 4 Jun 2013 20:07:51 -0700 (PDT) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id D2C1721F9B35 for ; Tue, 4 Jun 2013 20:07:50 -0700 (PDT) Received: from mail-we0-f176.google.com ([74.125.82.176]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKUa6rhdStmwT583VaUiaeVUKz09gXnsn7@postini.com; Tue, 04 Jun 2013 20:07:51 PDT Received: by mail-we0-f176.google.com with SMTP id t56so843229wes.7 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=P6EhVOEKg7WyEMjxWITUTyHTphiwl1P3oW5ZBMCwFjb8KsI0bIh0DO98eJEI/kZJdB fTVLcLDPYQm34jmn3R4DH74YWma8NDgJtDqnFatDBJyJnpCH8jjb9XYYi0b9+YKi/KPU ywctuqhoDxkcNXik5RUsGIj17g6ssat1TMvQC2p7d4oai44Ow+382JHLNrmqwFJMbBGI bdfG8wVUTKahm08BuSvxCSfSBTQXQh026/xx3jOjg/688SGn0jHcokWKTqSzFvWQXL11 TasZEipeYBxUmkrYso8vykja/gp3mbIvsKXrlIiaC8T/7B0RXmQu3KqEshqaHyDnwa9H nPyw== X-Received: by 10.180.9.80 with SMTP id x16mr4208655wia.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: To: Sheng Jiang Content-Type: multipart/alternative; boundary=001a11c21f84a18a1c04de5f80b6 X-Gm-Message-State: ALoCoQmoIU7fWNCtMWzWEePEoAvTAb6yHU7YVr3j2QLn48NfFZOgkZw1UlpQ1iZymqqi4P5VqVGtUjiq1F1QqjFQ0WeZUCK/JYZttnf9pxE7IHrWvOg4+WY8W4MJCxGKYduPDG1ApIPdSsRnib894QHTyq1VOh6tcA== Cc: Ray Hunter , "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605FF21F960D 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.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.034, 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 FjX8z8K56T8Q for ; Tue, 4 Jun 2013 20:11:42 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id A178B21F93E1 for ; Tue, 4 Jun 2013 20:11:42 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id bs12so873880qab.19 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=kzE5uyX8W5Qp4OmlKNZaYIkhvTATtP95du6bWpH+JsWnwKhUvgs1jL2c1rsqcLBOlw brByk0VRZyELdf/HiJnE1H22Y2K78jAvv8Y16ApFXBtHx1irpJJFXNeLPoiK/N4/TrAH w2WNQ8eM4uD92Cn5KrZkOTQeBRv881M2FLSVPC1lg45us1lp5EnaDQGkK9mOzxxP2KDN rFbRaByz+wnQ+rmYB94Qt3yg+2Nf7FtcqBgKxN2rZxKITj1HiypN2SGhorBcORFV2p1p 35mjhjUWyAYMznoPpqM+EIFHq1DwSqYrbxIhJz70rBoOmL47axA/v/sXpk/dU0iIsrgh oKHQ== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae9472d5b90f0c704de5f8eeb X-Gm-Message-State: ALoCoQmsLapBD7KTNhq8nEKJAgatvCKosmCB1lEE63N3lcWndY4nOD5dGUO5iRLA7FkrwaDTYiKwuIlW/856ZDhMj6lQITJiWdh+kVa0nm4kbCzvLO7cH635jClrTD7BsGyLvzxdR5aamkio4p11RRc/wWsd/vJZKvRTgwXKRq3DCYRaWO0UxAViN5XzPQAxZLZijvAWGSfd Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F16921F9AAD 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 bmjXUe0tMhfq for ; Tue, 4 Jun 2013 20:43:11 -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 4302F21F9AB5 for ; Tue, 4 Jun 2013 20:43:09 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id o13so3060121qaj.18 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=VTKaZSMFIgerDqaXIKSO4aUwCymzAVmoUGbsurOb7SS5Yjon4xQo9H5qRKUzEO5AFq kwk5KyilYjBb/2PSF4mQUYz/MSAQKHyJxpEhwmwiM62tXaeA7Dap3Zm9HeirgFiYjnYN /vqceJQpcp4Rk7ZNleVx4FUGYxJA1N7O1aptsMho+NWd/KENSoTiBX3UxcsvirAcV4u+ 5rAPpwrieUJOiNnzAj58Ypat41nCBnZnGbIe2kMUyWqgi4uthIMFhto/euZ9n/cGlwHI 9FbHsu06izUR+UjBAnAcBXchpnmRxkPTU4oRF6jEN/TGf82LYdIERZdwF+cNHGcmIPlz bjPw== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b6da82805471d04de5fffc6 X-Gm-Message-State: ALoCoQlHabW2r/JvbXlhQyc0lMM0vQeM7LDxCIq+ibn0w2zMCKdC2+gJBtWNES3bnAnq2441GIkdlk/JuLY3rRSb18SY45RwHrUAlXOawg47xkswU5bOvH9qdNy1HtU7/rrfibNSI+HdGvfMzbArNnit0y7Sq7vd4RH3ZJA3OOYxQr4PWW+K8PRIrHuMnOxBv8w/n3Ugy129 Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 lorenzo@google.com Tue Jun 4 21:10:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDB921F86F5 for ; Tue, 4 Jun 2013 21:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, 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 LlH45lQe5kcd for ; Tue, 4 Jun 2013 21:10:47 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 270E621F85F4 for ; Tue, 4 Jun 2013 21:10:46 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id ih17so190706qab.19 for ; Tue, 04 Jun 2013 21:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lqptm8KWTp0usuzdMRYidpuqcO+Z/+Zx0KEs4CEVOqY=; b=LMTTDjiBuIdPAJdpF0P8xDoX5I3wxSMlDQG4AIcHn3MfgIv0+oNgVpJ+3yjDH1OEk8 SQ+xA4CPGG3+ZbEpc/FPaZf7vr9KqguEi8OlTiY+X0zpNcBWPYwGbbM9ZGnzbh8uHDGF PsRhEEK+KL4hJ1OTY2m6lwcfZCtXKKmIxEDBIbdte1uq1TNL63BRPbMJOCtQnIgFphWL 139ge9rRKnJ3NfSx+i8mCdr0c07UGNRSDUSSPTRPp+Vh2QEt4TepONommfJDHuSWvEeh 6WUmoc3GsOyNa+jKos+JHPj2NokUQQsGgnjzaipNIyC13dyeFqZOdyVwvdxy/qIy7X7v D+Bg== 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=lqptm8KWTp0usuzdMRYidpuqcO+Z/+Zx0KEs4CEVOqY=; b=Qtp/Ddj+sss2KS+40CA/7QmIBGl9/nLQe2KEX8n+64TlxyQUQPAHjK/gGcV0cPl3Ae KpQJGEkuiVzCcpE0RvHEjh2niR+Me2D4yhChFxIEi6Q+ASnTo95UOh4Y0f8NfHk8PRgl h01o7gVat4ZmrHlUvbBmfWxO0xI24l4woQrDIq84Rjdc121JY5H1IbzNrNqTNcQ9cX98 vzIXsWIGqXCNwqvnqMCskPDVUfPaii/WsliwAkpG2Zto8NZ3bEi+nrcw7hv/XfER9Tuk d3WqrNuLLprO13RC9zcIhZBmJcN/CD+aVF6yDoyI67N9YJGpVc+b2/7Mzbm0SItnfJi2 kkgg== X-Received: by 10.224.98.65 with SMTP id p1mr25938299qan.70.1370405443885; Tue, 04 Jun 2013 21:10:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Tue, 4 Jun 2013 21:10:23 -0700 (PDT) In-Reply-To: <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> From: Lorenzo Colitti Date: Wed, 5 Jun 2013 13:10:23 +0900 Message-ID: To: "Ackermann, Michael" Content-Type: multipart/alternative; boundary=20cf3074d9a4af8e2804de6061f5 X-Gm-Message-State: ALoCoQmNo/Hiy2mquoy3c3vBk7v4oqMYqaE5Nez5OW7lkvKRJg1XlsDltZcm5HJtlPkY2h4xWoEIKxFga4yanUtIWVm9jR7rDpf74gbV/RiYN23u5UChuKznDrH43Qy5Im2cEfBX1DrOOCbWE3kRDJxPpzKN/3BKnN8QcX0NSfOZNTO7LfgfvixsXvkfVmJfBj6AIx9ypBsg Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 04:10:47 -0000 --20cf3074d9a4af8e2804de6061f5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 3:01 AM, Ackermann, Michael wr= ote: > But as a general practice or default, it suggests that the IPV6 > architecture is flawed. I don=92t want to believe that. > You're free to believe what you want, but that data came from real-world measurements. Unfortunately, there are good operational reasons (like lack of hardware support) for this state of affairs, so it will not be sufficient to tell network operators that they are misguided and wait until the problem is fixed. As for the architecture being flawed: remember that the IPv6 protocol was finalized 1998. The Internet was a different place back then. IPv4 is no better of course - there are plenty of features that haven't worked on the Internet for a very long time. Record route? Source routing? Source quench? Non-TCP/UDP protocols? In IPv4, that all stopped working a while ago. --20cf3074d9a4af8e2804de6061f5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 3:01 AM, Ackermann, Michael <MA= ckermann@bcbsm.com> wrote:

But as a general practice or default, it sug= gests that the IPV6 architecture is flawed.=A0=A0=A0=A0=A0 I don=92t want to believe that.=A0

=

You're free to believe wha= t you want, but that data came from real-world measurements. Unfortunately,= there are good operational reasons (like lack of hardware support) for thi= s state of affairs, so it will not be sufficient to tell network operators = that they are misguided and wait until the problem is fixed.

As for the architecture being flawed: remem= ber that the IPv6 protocol was finalized 1998. The Internet was a different= place back then. IPv4 is no better of course - there are plenty of feature= s that haven't worked on the Internet for a very long time. Record rout= e? Source routing? Source quench? Non-TCP/UDP protocols? In IPv4, that all = stopped working a while ago.
--20cf3074d9a4af8e2804de6061f5-- From gert@space.net Wed Jun 5 01:37:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015B421F9A0A 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=[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 8c1P820vzzIt 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 4C7A321F972E 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 345B860A2F 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 E4E2460A14 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 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 ian.farrer@telekom.de Wed Jun 5 01:00:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 03:43:23 -0700 Cc: ipv6@ietf.org, v6ops@ietf.org, draft-jiang-v6ops-semantic-prefix@tools.ietf.org, rdroms.ietf@gmail.com Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 rajiva@cisco.com Wed Jun 5 06:14:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E8621F99C0; Wed, 5 Jun 2013 06:14:13 -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 L2XwwvJ6bt-r; Wed, 5 Jun 2013 06:14:08 -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 0728721F999B; Wed, 5 Jun 2013 06:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1002; q=dns/txt; s=iport; t=1370438048; x=1371647648; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0VuYdvN4FLSfr85yDXqlZf0dSnY6M0edPgKpioihzao=; b=IsFey7HERh4NTYyrtRxyX7IYvSYGwc3qzOAIkhC6cDEseGxeGYeE45Ag v9OaffX2W1HTEiHAGOa8MdxsGDyvqDoqTL6YazdG0M1XSiDxg27/IYSya on/dZtGrpstimj1ra6G2QIMslR+Ca0ifm/wiGk92WeVCg9VIryO7NWkoc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FADc5r1GtJXG9/2dsb2JhbABZFoJzMIJ1vDd8FnSCJQEEOj8SASoUQiYBBAENDQGIBL0MjnoxgwFhA6NfhSCDD4In X-IronPort-AV: E=Sophos;i="4.87,806,1363132800"; d="scan'208";a="219055757" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 13:14:07 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55DE7QQ019360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 13:14:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 08:14:06 -0500 From: "Rajiv Asati (rajiva)" To: "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlA== Date: Wed, 5 Jun 2013 13:14:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:14:13 -0000 Some of you may recall our discussion (during the last IETF) around "how ma= ny TCP/UDP ports are enough with NAPT44" per home, as ISPs move into A+P pa= radigm. ~500, ~1000, ~3000??? Well, I started monitoring my home router and plotting the NAPT44 port util= ization on a minute-by-minute basis. You may find it here - http://www.empl= oyees.org/~rajiva In short, port range of 500 seems ok, though 1000 would be more than enough= for my home. Suffice to say, this is just a sample representation, since t= he port utilization would vary home to home, based on number of active devi= ces, type of applications, the degree of simultaneous device or application= usage etc. If any of you are doing similar monitoring, then please share. Cheers, Rajiv PS: Thanks to Erik Kline, who explained (with sufficient details) how to us= e google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for h= elping me out significantly. PS: My home has 3-4 active devices. From kristian.poscic@alcatel-lucent.com Wed Jun 5 06:33:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE1021F9ABB; Wed, 5 Jun 2013 06:33:17 -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 dLrf+ofQT54B; Wed, 5 Jun 2013 06:33:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EE70B21F9ACF; Wed, 5 Jun 2013 06:33:06 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r55DWwG0026696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Jun 2013 08:32:58 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r55DWtQK002234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 09:32:56 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 09:32:54 -0400 From: "Poscic, Kristian (Kristian)" To: "Rajiv Asati (rajiva)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuw Date: Wed, 5 Jun 2013 13:32:53 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Wed, 05 Jun 2013 06:50:24 -0700 Subject: Re: [v6ops] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:33:17 -0000 Thanks. Can you tell us in general what applications did you use for this? This heavily depends on the application type in use...p2p apps, etc. Since = some apps spawn a large number of TCP ports for example. So the question is to what degree do you think is your sample representativ= e of a general user in any region? For example does it cover 30% of users for an ISP in NA while it covers 80%= of users for another ISP in APAC for example? -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Rajiv Asati (rajiva) Sent: Wednesday, June 05, 2013 6:14 AM To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); behave@ietf.org Cc: Erik Kline (ek@google.com) Subject: [BEHAVE] Home NAPT44 - How many ports? Some of you may recall our discussion (during the last IETF) around "how ma= ny TCP/UDP ports are enough with NAPT44" per home, as ISPs move into A+P pa= radigm. ~500, ~1000, ~3000??? Well, I started monitoring my home router and plotting the NAPT44 port util= ization on a minute-by-minute basis. You may find it here - http://www.empl= oyees.org/~rajiva In short, port range of 500 seems ok, though 1000 would be more than enough= for my home. Suffice to say, this is just a sample representation, since t= he port utilization would vary home to home, based on number of active devi= ces, type of applications, the degree of simultaneous device or application= usage etc. If any of you are doing similar monitoring, then please share. Cheers, Rajiv PS: Thanks to Erik Kline, who explained (with sufficient details) how to us= e google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for h= elping me out significantly. PS: My home has 3-4 active devices. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From sander@steffann.nl Wed Jun 5 07:23:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 nalini.elkins@insidethestack.com Wed Jun 5 07:40:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1721F9922 for ; Wed, 5 Jun 2013 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 ww8pltGKExMB for ; Wed, 5 Jun 2013 07:40:29 -0700 (PDT) Received: from nm30.access.bullet.mail.sp2.yahoo.com (nm30.access.bullet.mail.sp2.yahoo.com [98.139.44.157]) by ietfa.amsl.com (Postfix) with ESMTP id DA4F121F9052 for ; Wed, 5 Jun 2013 07:40:16 -0700 (PDT) Received: from [98.139.44.100] by nm30.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 14:40:16 -0000 Received: from [98.139.44.76] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 14:40:16 -0000 Received: from [127.0.0.1] by omp1013.access.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 14:40:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 498821.61287.bm@omp1013.access.mail.sp2.yahoo.com Received: (qmail 63369 invoked by uid 60001); 5 Jun 2013 14:40:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370443215; bh=BP2cateUJq11eJMzBxnohICGyRupisl/AjCdX2qeF60=; 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=0IzDKtRfMIJL5oa5gnGOvHiOC7ByfHqPgCFWHK+P+UndNkV0gOv8S9ZkmnpweRdPHkUObYb3ezlsXCvsc217IXJj1kcluVbOOgt4/WXEncWZzH3rNAhsmutMNuKQrdSQsM8dTpnaNmi2osKfoWfYIOYnT1POybun87tRKU0pkK4= X-YMail-OSG: rhX_cE8VM1k838yzKu.W8OPoHsFM00eOmdZWG1ctqOS3PLM 30QHEdFCLu5dOOEi4ZPk2AlpoAIInL4027FG9yjlYnxEccuwu5CEKccX_zts NTOG3VuZCRZXKLPx4txJimmmmzk5CvPRL6L6D6n1baicODsCwMGBBL.HQyMK PnPyxv7xyVKH4RPvGWgq2GrJH5dAD89hxVVrI4FsZStrQ9TrYulhKL75D8y6 00eGbQXJSMH2yXFJJWazGsGznRaQj7lSB59bzzTlf_JGwpiJ3StQiaABGYt6 cowdXS1ErE7OrD._ee0BCU86sZDtxZeYG.p5UfZFucXHFBQYPyoUnHuwDip9 ejSZIbwHNlrvky2OZFfeDxOfwDaXiC6TNyiD.XA7ujNaitT.zeVu_NP4rM9e w4v_veSx9eoOcYRwjt42.ZfWH9sICgmcGBKVd29A5Q.mBpUcOdDGVlcjHz2_ v5JTrM7OBF9V.t7oxs.sxT8T6v1TG0_uCrpT.jdPI1GDsDfD7fdP0oBFoHr4 GoYZO7qx6haEIv9fP3yxZTmg45l97E0zplH8x5R3ohKxR_cU7efbDmTOzwAF vmCWEbw7RfolfHBVesE6Fo6MWi6irYGEs24qcp1MjpVXy.BbIsIVqJfk939M h3YScFCgJQLNJp4VwCU_pJA-- Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 07:40:15 PDT X-Rocket-MIMEInfo: 002.001, TmljaywKCj4.IHRoZSBvcGVyYXRvciBjb21tdW5pdHkgZG9lc24ndCBsaWtlIHRoZW0gYmVjYXVzZSB0aGV5IGNhdXNlIHNlcmlvdXMgb3BlcmF0aW9uYWwgZGlmZmljdWx0aWVzLsKgwqAKCldlIGFyZSBvcGVyYXRvcnMgYWxzby4gwqBUaGUgcGVvcGxlIG9uIG15IHRlYW0gcnVuIHZlcnkgbGFyZ2UsIGNvbXBsZXggcHJpdmF0ZSBuZXR3b3Jrcy4gwqAgV2UgYXJlIHRyeWluZyB0byBhZGRyZXNzIG91ciBsb25nLXRlcm0gb3BlcmF0aW9uYWwgZGlhZ25vc3RpYyBkaWZmaWN1bHRpZXMuIMKgIEkgZG8gcmVhbGwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> Message-ID: <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 07:40:15 -0700 (PDT) From: Nalini Elkins To: Nick Hilliard In-Reply-To: <51AE60CF.6000709@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:40:39 -0000 Nick,=0A=0A>> the operator community doesn't like them because they cause s= erious operational difficulties.=A0=A0=0A=0AWe are operators also. =A0The p= eople on my team run very large, complex private networks. =A0 We are tryin= g to address our long-term operational diagnostic difficulties. =A0 I do re= ally=A0appreciate your thoughtful comments. =A0 I hope that we can all work= together to put our energies to fix the difficulties that we all have. =A0= I will be commenting on the 6man list on the=A0https://datatracker.ietf.org= /doc/draft-ietf-6man-ext-transmit/=A0as well. =A0I believe that the issues = you have brought up are some of the most acutely serious facing IPv6 implem= entations today. =A0On the other hand, the issues we are trying to address = are long-term and chronic.=0A=0A>>=A0The IETF won't deprecate them either,= =A0because there are as many people who think they are wonderful as think t= hey=A0are a disaster.=A0=0A=0AI would be interested in hearing from some of= the people who think IPv6 extension headers are wonderful. =A0(I have a fe= eling that I am leaning in that direction myself!). =A0 =A0Are these people= fools? =A0 Do they run slow-as-molasses networks where every packet is bei= ng defaulted to being routed in software? =A0Do they not enable IPv6 extens= ion headers on their networks? =A0What is the story? =A0I will reach out to= some of the organizations that I know who have fairly widespread implement= ations of IPv6 on private networks. =A0=A0=0A=0AWhat do Joint Interoperabil= ity Test Command (JITC) and National Institute of Standards and Technology = (NIST) in the US have to say about this? =A0 They have been in the forefron= t of setting the guidelines for IPv6 implementation in the United States.= =A0Anybody know? Do they say "just kidding"=A0about implementing IPv6 exten= sion headers? =A0If you arbitrarily drop extension headers or route them ve= ry slowly, you are getting rid of some extremely basic functionality.=0A=0A= >> ESP/ipv4 is fine - it's easily handled by firewalls because you can run = a=A0simple bitfield comparison on the incoming packet.=A0 ESP is protocol 5= 0 and=A0this ID is located in bits 72-79 in ipv4.=A0 You can check for this= really=0A>>=A0fast in hardware and as the packet is encrypted anyway, ther= e is no point=A0inspecting further inside the payload, which means that you= r forwarding=A0engine can handle this very quickly.=0A=0ASo IPv6 ESP not fi= ne? =A0This is going to be a surprise to many.=0A=0AAs far as your comments= on ASICs, a few questions:=0A=0A1. =A0I am not getting why forwarding deci= sions are having to be made by looking at anything other than the IP addres= ses. =A0What am I missing here? =A0=0A=0A2. =A0Are you talking about ASICs = on large core switches, routers, firewalls, load balancers or all the above= ?=0A=0A3. =A0It was my understanding the the ASIC size was in the range of = 256 bytes to 1K. =A0This seems to leave plenty of room for the IPv6 main he= ader & quite a few extensions.=0A=0A=0A>>We don't have widespread silicon w= hich can make forwarding decisions based=A0on arbitrary TLV structures, bec= ause that would mean inspecting ipv6=A0packets of pretty much arbitrary len= gth. =A0=0A=0AWell, it seems like maybe what is missing is the old IP heade= r length field. =A0This time including extension headers as well as the mai= n.=0A=0A>>=A0Also, given that we're having trouble building hardware to=A0m= eet the demands of current forwarding requirements, I don't think we're=A0g= oing to see tlv processing on 100ge / 400ge=A0any time soon, although no do= ubt it will happen at some >>stage=0A=0ARealistically, we are talking about= the extension header that we want implemented being available 5 - 6 years = from now (or even more). =A0We are considering the time spent for the IETF = approval process, then to get on the development priority list for the stac= k software vendors, then to get that particular release of the operating sy= stem actually out at customer sites, etc. =A0I hope the world will look a b= it different at that point in this regard.=0A=0A>>=A0Many firewall stacks h= ave not bothered to implement proper stacked EH=A0processing because it's h= ard to do right.=A0=A0=0A=0AThis sounds like another problem which needs to= be addressed. =A0 Why is it that there are no RFCs for firewalls? =A0At le= ast that is my understanding. =A0This is a large hole that IMHO needs to be= fixed.=0A=0A>>=A0And network operators don't=A0necessarily understand how = they operate either=0A=0AThen they should learn. =A0In our country, they ha= ve a saying "ignorance of the law is no excuse". =A0 If my daughter wants t= o drive a car, she can't just go out without learning how to do it. =A0How = is it possible to run networks that way? =A0Sounds pretty irresponsible to = me.=0A=0A=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 6= 59-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______________________________= _=0AFrom: Nick Hilliard =0ATo: Nalini Elkins =0ACc: "v6ops@ietf.org" =0ASent: Tuesda= y, June 4, 2013 2:49 PM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6op= s-ipv6-end-to-end-rt-needed=0A=0A=0AOn 04/06/2013 19:32, Nalini Elkins wrot= e:=0A> Is this IETF consensus: IPv6 extension headers should no longer be u= sed?=0A=0AThe ietf hasn't deprecated them, but as you can see from the reac= tion in=0Athis group, the operator community doesn't like them because they= cause=0Aserious operational difficulties.=A0 The IETF won't deprecate them= either,=0Abecause there are as many people who think they are wonderful as= think they=0Aare a disaster.=A0 If this discussion opened up, consensus wo= uld not be=0Aachieved either way.=A0 There is no point going there.=0A=0A> = Maybe then, all the RFCs need to be updated.=A0=A0=A0Let's start with RFC24= 60 --=0A> all extension headers are henceforth deprecated.=A0=A0=A0Who is g= oing to take=0A> this on?=0A> =0A> Is this what we are saying?=A0 AH and ES= P too?=A0 Why not go backwards and take=0A> them out in IPv4 as well?=0A=0A= With regard to ipv6, they are a royal pain - AH and ESP included.=0A=0AAs a= n aside, for ipv4 I would dearly love to see AH deprecated in favour of=0AE= SP (see draft-bhatia-ipsecme-avoiding-ah for why); alas there is a noisy=0A= crowd in the ipsec working group which won't are fully intent on blocking= =0Athis sensible move.=A0 I won't bore you with the details, but you can re= ad=0Aall about it on the ietf ipsec mailing list.=0A=0AESP/ipv4 is fine - i= t's easily handled by firewalls because you can run a=0Asimple bitfield com= parison on the incoming packet.=A0 ESP is protocol 50 and=0Athis ID is loca= ted in bits 72-79 in ipv4.=A0 You can check for this really=0Afast in hardw= are and as the packet is encrypted anyway, there is no point=0Ainspecting f= urther inside the payload, which means that your forwarding=0Aengine can ha= ndle this very quickly.=0A=0AAll of which point to the core problem of exte= nsion headers: they use TLVs.=0A=0AThis was one of these things that seemed= like a good idea at the time, way=0Aback in 1995.=A0 People had realised t= hat one of the annoying limitations of=0Aipv4 was that the header used a fi= xed-length construct and it was difficult=0Ato extend the protocol.=A0 So a= TLV structure was devised to allow arbitrary=0Aheaders to be attached to a= n ipv6 packet.=A0 This seemed sensible, because=0Amost packet forwarding wa= s done in software and it was relatively easy to=0Awrite code to inspect de= ep into packets - in software.=A0 Also, for the most=0Apart, people were mo= re interested in forwarding packets than not forwarding=0Apackets.=0A=0ABut= as time moved on, more and more forwarding decisions got moved to ASICs=0A= and NPUs, and these had more limitations, particularly with regard to=0Apac= ket structures which were difficult to parse, especially on ASICs.=A0 E.g.= =0Alots of silicon today will perform a forwarding lookup based on only the= =0Afirst N octets of the header, and if your extension header falls outside= =0Athat lookup window, it will not be parsed in the forwarding path.=A0 You= r=0Aoptions are to drop regardless, to forward regardless or to punt to a s= low=0Acpu.=A0 I'm not sure which is the least broken of these options.=0A= =0AWe don't have widespread silicon which can make forwarding decisions bas= ed=0Aon arbitrary TLV structures, because that would mean inspecting ipv6= =0Apackets of pretty much arbitrary length.=A0 I'm not saying it doesn't ex= ist -=0Athere are some chipsets and NPUs out there which will do this, but = they are=0Anot the norm.=A0 Also, given that we're having trouble building = hardware to=0Ameet the demands of current forwarding requirements, I don't = think we're=0Agoing to see tlv processing on 100ge / 400ge any time soon, a= lthough no=0Adoubt it will happen at some stage.=0A=0AMany firewall stacks = have not bothered to implement proper stacked EH=0Aprocessing because it's = hard to do right.=A0 And network operators don't=0Anecessarily understand h= ow they operate either, which means that you will=0Aoften end up with misco= nfigured firewalls which block EHs to an even=0Agreater extent than firewal= l operators currently block e.g. ICMP today.=0A=0AThis leaves us in the awk= ward position that we've got this great protocol=0Awhich is too cool to act= ually work at the sorts of speed that we expect=0Afrom ipv4, and with the s= ame feature levels.=A0 Maybe it will work one day=0Awhen we get forwarding = path feature parity with ipv4 at the speeds we need.=0AUntil then, they are= a gross inconvenience which cause identifiable and=0Aserious operational p= roblems.=0A=0ANick=A0 From nalini.elkins@insidethestack.com Wed Jun 5 07:45:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E9B21F904B for ; Wed, 5 Jun 2013 07:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, 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 rQlTLXnC4us3 for ; Wed, 5 Jun 2013 07:45:23 -0700 (PDT) Received: from nm17-vm0.access.bullet.mail.sp2.yahoo.com (nm17-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.168]) by ietfa.amsl.com (Postfix) with ESMTP id 0949E21F8613 for ; Wed, 5 Jun 2013 07:45:22 -0700 (PDT) Received: from [98.139.44.101] by nm17.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 14:45:22 -0000 Received: from [98.139.44.92] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 14:45:22 -0000 Received: from [127.0.0.1] by omp1029.access.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 14:45:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 849998.19075.bm@omp1029.access.mail.sp2.yahoo.com Received: (qmail 12214 invoked by uid 60001); 5 Jun 2013 14:45:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370443522; bh=PHndkd17bRFHP/9yXTg1Q1FekBRYWxms6/3RoxXjEbo=; 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=aO7bQC3WXKlKELReSg7gd2dgPV2mVThJEir55UaCjjoLK5woG906wFWA3qzpv94frti5EhoiT9ZzP4KaQoF+/0tFuwotSwRAHLi4rwayCY92T75B4wT6cRMKIPcnM+LyhWlK5nONcedOKiNnNCbtktD2R0qEyPTKjUoDJY2Tvb4= X-YMail-OSG: gvg9sBgVM1mN6M5sUeRAwGCJKz7EM6yRNoOgpYzHwtfdixR kp_e6TclyKvWhFP4ASmOv Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 07:45:22 PDT X-Rocket-MIMEInfo: 002.001, Pj4gSVB2NCBpcyBubyBiZXR0ZXIgb2YgY291cnNlIC0gdGhlcmUgYXJlIHBsZW50eSBvZiBmZWF0dXJlcyB0aGF0IGhhdmVuJ3Qgd29ya2VkIG9uIHRoZSBJbnRlcm5ldCBmb3IgYSB2ZXJ5IGxvbmcgdGltZS4gUmVjb3JkIHJvdXRlPyBTb3VyY2Ugcm91dGluZz8gU291cmNlIHF1ZW5jaD8gTm9uLVRDUC9VRFAgcHJvdG9jb2xzPyBJbiBJUHY0LCB0aGF0IGFsbCBzdG9wcGVkIHdvcmtpbmcgYSB3aGlsZSBhZ28uCgoKVGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gYmFzaWMgZnVuY3Rpb25hbGl0eSBhbmQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> Message-ID: <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 07:45:22 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti , "Ackermann, Michael" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-437239975-1370443522=:9335" Cc: Fernando Gont , "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:45:29 -0000 --1619178251-437239975-1370443522=:9335 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> IPv4 is no better of course - there are plenty of features that haven't = worked on the Internet for a very long time. Record route? Source routing? = Source quench? Non-TCP/UDP protocols? In IPv4, that all stopped working a w= hile ago.=0A=0A=0AThere is a difference between basic functionality and rel= atively peripheral functionality. =C2=A0I would put extension headers in th= e basic category.=0A=C2=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Product= s, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______________= __________________=0A From: Lorenzo Colitti =0ATo: "Ack= ermann, Michael" =0ACc: Nalini Elkins ; Fernando Gont ; "v6ops@ietf.or= g" ; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ie= tf.org" =0ASe= nt: Tuesday, June 4, 2013 9:10 PM=0ASubject: Re: [v6ops] new draft: draft-e= lkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn Wed, Jun 5, 2013 at 3:= 01 AM, Ackermann, Michael wrote:=0A=0ABut as a gener= al practice or default, it suggests that the IPV6 architecture is flawed.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I don=E2=80=99t want to believe that.=C2=A0= =0A=0AYou're free to believe what you want, but that data came from real-wo= rld measurements. Unfortunately, there are good operational reasons (like l= ack of hardware support) for this state of affairs, so it will not be suffi= cient to tell network operators that they are misguided and wait until the = problem is fixed.=0A=0AAs for the architecture being flawed: remember that = the IPv6 protocol was finalized 1998. The Internet was a different place ba= ck then. IPv4 is no better of course - there are plenty of features that ha= ven't worked on the Internet for a very long time. Record route? Source rou= ting? Source quench? Non-TCP/UDP protocols? In IPv4, that all stopped worki= ng a while ago. --1619178251-437239975-1370443522=:9335 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
>> IPv4 is no better of course - there ar= e plenty of features that haven't worked on the Internet for a very long ti= me. Record route? Source routing? Source quench? Non-TCP/UDP protocols? In = IPv4, that all stopped working a while ago.
<= div style=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: arial, helv= etica, sans-serif; background-color: transparent; font-style: normal;">
unctionality and relatively peripheral functionality. &nbs= p;I would put extension headers in the basic category.
 
Thanks,

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

From: Lorenzo Colitti &l= t;lorenzo@google.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: Nalini Elkins <nalini.elkins@insidethes= tack.com>; Fernando Gont <fgont@si6networks.com>; "v6ops@ietf.org"= <v6ops@ietf.org>; "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tool= s.ietf.org" <draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org= >
Sent: Tuesday, J= une 4, 2013 9:10 PM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed<= br>

=0A
On Wed, Jun 5, 2013 at 3:01 AM, Ackermann, Michael = <MAckermann@bc= bsm.com> wrote:
=0A=0A
=0A=0A=0A=0A=0A=0A
=0A
=0A
But as a general practice or default= , it suggests that the IPV6 architecture is=0A flawed.   &nb= sp;  I don=E2=80=99t want to believe that. 

You're free to believe what = you want, but that data came from real-world measurements. Unfortunately, t= here are good operational reasons (like lack of hardware support) for this = state of affairs, so it will not be sufficient to tell network operators th= at they are misguided and wait until the problem is fixed.
=0A=0A

As for the architecture being flawed: = remember that the IPv6 protocol was finalized 1998. The Internet was a diff= erent place back then. IPv4 is no better of course - there are plenty of fe= atures that haven't worked on the Internet for a very long time. Record rou= te? Source routing? Source quench? Non-TCP/UDP protocols? In IPv4, that all= stopped working a while ago.
=0A=0A
=0A

--1619178251-437239975-1370443522=:9335-- From Ted.Lemon@nominum.com Wed Jun 5 07:54:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 mcr@sandelman.ca Wed Jun 5 06:52:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C963F21F9B47; Wed, 5 Jun 2013 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YT2szkZ2ol+k; Wed, 5 Jun 2013 06:52:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE021F9B48; Wed, 5 Jun 2013 06:52:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5DEDF2017F; Wed, 5 Jun 2013 10:05:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9FD1963A8C; Wed, 5 Jun 2013 09:51:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7F07B63A5E; Wed, 5 Jun 2013 09:51:37 -0400 (EDT) From: Michael Richardson To: "Rajiv Asati (rajiva)" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Wed, 05 Jun 2013 08:08:51 -0700 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:52:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "rajiva" =3D=3D rajiva writes: rajiva> In short, port range of 500 seems ok, though 1000 would be rajiva> more than enough for my home. Suffice to say, this is just a rajiva> sample representation, since the port utilization would vary rajiva> home to home, based on number of active devices, type of rajiva> applications, the degree of simultaneous device or rajiva> application usage etc.=20 You are a home of how many computers? How many active people? (I don't assume those are 1:1...) I guess you have no IPv6 running? SIP? Skype? VPN (what kind? does it terminate on a desktop, or on your "router"?)=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUa9CaIqHRg3pndX9AQKx8AQAwzO8Qpe9GP1fRz6ZxUyAKQ7hYnn8UGfv tRZv4oupP1uApQ7k3r3W+l87xhji6MeQAtrvh1XXpA7GMAdT06xt+K88rt8bmIoN BrPLh1GL33Ij5QYDt3tbOvBdv1GsYdBaMbwhgLHobA3QNRFxiEH6Ns9SWb3n4ZfA 1SoeM7iOi9o= =p17H -----END PGP SIGNATURE----- --=-=-=-- From bmanning@isi.edu Wed Jun 5 07:22:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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 X-Mailman-Approved-At: Wed, 05 Jun 2013 08:08:51 -0700 Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" , Andrew McGregor Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 nick@inex.ie Wed Jun 5 08:33:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79C521F9AA8 for ; Wed, 5 Jun 2013 08:33:45 -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 Yu9Qcd6mqbM9 for ; Wed, 5 Jun 2013 08:33:45 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5B821F9ACF for ; Wed, 5 Jun 2013 08:33:43 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from pancake.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r55FXc53036306 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 5 Jun 2013 16:33:38 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <51AF5A52.8010100@inex.ie> Date: Wed, 05 Jun 2013 16:33:38 +0100 From: Nick Hilliard 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: Nalini Elkins References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:33:46 -0000 On 05/06/2013 15:40, Nalini Elkins wrote: > I would be interested in hearing from some of the people who think IPv6 > extension headers are wonderful. (I have a feeling that I am leaning in > that direction myself!). The easiest way to figure this out would be to write a draft formally deprecating EHs and make sure to cross-post to 6man, v6ops and ietf@ietf.org. Let me know if you plan this so I can buy a huge batch of popcorn. And a bigger sofa, nomnomnom. > Are these people fools? Do they run > slow-as-molasses networks where every packet is being defaulted to being > routed in software? They're not fools: they just don't run networks. They design networking protocols and leave implementation to someone else. Do you see Ford car designers driving formula one? Probably not. FWIW, it would make my day to permanently disable ipv4 at ietf meetings so that everyone at the IETF would be forced to eat ipv6 dog food. The DHCPv6 vs RA problem would come flying into focus if this happened, and I'd be most pleased if the RA jihadis finally got their comeuppance. > What do Joint Interoperability Test Command (JITC) and National > Institute of Standards and Technology (NIST) in the US have to say about > this? No idea, and no idea why this would even be relevant to ietf standards any more than the opinions of any other regional standards bodies. > So IPv6 ESP not fine? This is going to be a surprise to many. It's just that there is plenty of hardware out there which won't handle it very well, that's all. > As far as your comments on ASICs, a few questions: > > 1. I am not getting why forwarding decisions are having to be made by > looking at anything other than the IP addresses. What am I missing > here? as Joel mentioned, ECMP on routers, or policy routing, or QoS. Other generic middleboxes will also make forwarding decisions based on arbitrary packet data. > 2. Are you talking about ASICs on large core switches, routers, > firewalls, load balancers or all the above? pretty much any device which makes forwarding decisions on the internet. > 3. It was my understanding the the ASIC size was in the range of 256 > bytes to 1K. This seems to leave plenty of room for the IPv6 main > header & quite a few extensions. it is very small on plenty of boxes, e.g. 64 bytes on c7600/rsp720. > Realistically, we are talking about the extension header that we want > implemented being available 5 - 6 years from now (or even more). We are > considering the time spent for the IETF approval process, then to get on > the development priority list for the stack software vendors, then to > get that particular release of the operating system actually out at > customer sites, etc. I hope the world will look a bit different at that > point in this regard. An alternative point of view is: extension headers are causing more problems as time goes on, not fewer. Let's fix this problem first before we define more of them and make our current / future problems worse. Nick From Ted.Lemon@nominum.com Wed Jun 5 08:42:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 warren@kumari.net Wed Jun 5 08:52:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E5A21F9AE9 for ; Wed, 5 Jun 2013 08:52:50 -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 wJAIB-lRPrGd for ; Wed, 5 Jun 2013 08:52:39 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA9B21F9488 for ; Wed, 5 Jun 2013 08:52:37 -0700 (PDT) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id 77C711B40A72; Wed, 5 Jun 2013 11:52:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <51AE60CF.6000709@inex.ie> Date: Wed, 5 Jun 2013 10:52:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:52:50 -0000 On Jun 4, 2013, at 4:49 PM, Nick Hilliard wrote: > On 04/06/2013 19:32, Nalini Elkins wrote: >> Is this IETF consensus: IPv6 extension headers should no longer be = used? >=20 > The ietf hasn't deprecated them, but as you can see from the reaction = in > this group, the operator community doesn't like them because they = cause > serious operational difficulties. =20 http://tools.ietf.org/html/draft-wkumari-long-headers-00 I should mention that we have had this almost exact set of = conversations (not the headers bit, the "I want to squish some token = somewhere in the packet" bit) a number of times before. http://www.ietf.org/mail-archive/web/v6ops/current/msg15823.html http://www.ietf.org/mail-archive/web/v6ops/current/msg15781.html http://www.ietf.org/mail-archive/web/v6ops/current/msg15126.html etc etc etc. > The IETF won't deprecate them either, > because there are as many people who think they are wonderful as think = they > are a disaster. If this discussion opened up, consensus would not be > achieved either way. There is no point going there. >=20 >> Maybe then, all the RFCs need to be updated. Let's start with = RFC2460 -- >> all extension headers are henceforth deprecated. Who is going to = take >> this on? >>=20 >> Is this what we are saying? AH and ESP too? Why not go backwards = and take >> them out in IPv4 as well? >=20 > With regard to ipv6, they are a royal pain - AH and ESP included. >=20 > As an aside, for ipv4 I would dearly love to see AH deprecated in = favour of > ESP (see draft-bhatia-ipsecme-avoiding-ah for why); alas there is a = noisy > crowd in the ipsec working group which won't are fully intent on = blocking > this sensible move. I won't bore you with the details, but you can = read > all about it on the ietf ipsec mailing list. >=20 > ESP/ipv4 is fine - it's easily handled by firewalls because you can = run a > simple bitfield comparison on the incoming packet. ESP is protocol 50 = and > this ID is located in bits 72-79 in ipv4. You can check for this = really > fast in hardware and as the packet is encrypted anyway, there is no = point > inspecting further inside the payload, which means that your = forwarding > engine can handle this very quickly. >=20 > All of which point to the core problem of extension headers: they use = TLVs. >=20 > This was one of these things that seemed like a good idea at the time, = way > back in 1995. People had realised that one of the annoying = limitations of > ipv4 was that the header used a fixed-length construct and it was = difficult > to extend the protocol. So a TLV structure was devised to allow = arbitrary > headers to be attached to an ipv6 packet. This seemed sensible, = because > most packet forwarding was done in software and it was relatively easy = to > write code to inspect deep into packets - in software. Also, for the = most > part, people were more interested in forwarding packets than not = forwarding > packets. >=20 > But as time moved on, more and more forwarding decisions got moved to = ASICs > and NPUs, and these had more limitations, particularly with regard to > packet structures which were difficult to parse, especially on ASICs. = E.g. > lots of silicon today will perform a forwarding lookup based on only = the > first N octets of the header, and if your extension header falls = outside > that lookup window, it will not be parsed in the forwarding path. = Your > options are to drop regardless, to forward regardless or to punt to a = slow > cpu. I'm not sure which is the least broken of these options. >=20 > We don't have widespread silicon which can make forwarding decisions = based > on arbitrary TLV structures, because that would mean inspecting ipv6 > packets of pretty much arbitrary length. I'm not saying it doesn't = exist - > there are some chipsets and NPUs out there which will do this, but = they are > not the norm. Also, given that we're having trouble building hardware = to > meet the demands of current forwarding requirements, I don't think = we're > going to see tlv processing on 100ge / 400ge any time soon, although = no > doubt it will happen at some stage. >=20 > Many firewall stacks have not bothered to implement proper stacked EH > processing because it's hard to do right. And network operators don't > necessarily understand how they operate either, which means that you = will > often end up with misconfigured firewalls which block EHs to an even > greater extent than firewall operators currently block e.g. ICMP = today. >=20 > This leaves us in the awkward position that we've got this great = protocol > which is too cool to actually work at the sorts of speed that we = expect > from ipv4, and with the same feature levels. Maybe it will work one = day > when we get forwarding path feature parity with ipv4 at the speeds we = need. > Until then, they are a gross inconvenience which cause identifiable = and > serious operational problems. >=20 > Nick >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- "Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead = in the water."=20 -- Tom Galvin, VeriSign's vice president for government relations. From sander@steffann.nl Wed Jun 5 09:04:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 Date: Wed, 5 Jun 2013 18:04:15 +0200 To: Ted Lemon Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 warren@kumari.net Wed Jun 5 09:10:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E276821F96B1 for ; Wed, 5 Jun 2013 09:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB0UMAbuEuWV for ; Wed, 5 Jun 2013 09:10:18 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00121F8B60 for ; Wed, 5 Jun 2013 09:10:17 -0700 (PDT) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id 3EE061B407DA; Wed, 5 Jun 2013 12:10:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <51AF5A52.8010100@inex.ie> Date: Wed, 5 Jun 2013 11:10:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:10:23 -0000 On Jun 5, 2013, at 10:33 AM, Nick Hilliard wrote: > On 05/06/2013 15:40, Nalini Elkins wrote: >> I would be interested in hearing from some of the people who think = IPv6 >> extension headers are wonderful. (I have a feeling that I am leaning = in >> that direction myself!). >=20 > The easiest way to figure this out would be to write a draft formally > deprecating EHs and make sure to cross-post to 6man, v6ops and = ietf@ietf.org. >=20 > Let me know if you plan this so I can buy a huge batch of popcorn. = And a > bigger sofa, nomnomnom. >=20 >> Are these people fools? Do they run >> slow-as-molasses networks where every packet is being defaulted to = being >> routed in software? >=20 > They're not fools: they just don't run networks. They design = networking > protocols and leave implementation to someone else. Do you see Ford = car > designers driving formula one? Probably not. >=20 > FWIW, it would make my day to permanently disable ipv4 at ietf = meetings so > that everyone at the IETF would be forced to eat ipv6 dog food. The = DHCPv6 > vs RA problem would come flying into focus if this happened, and I'd = be > most pleased if the RA jihadis finally got their comeuppance. >=20 >> What do Joint Interoperability Test Command (JITC) and National >> Institute of Standards and Technology (NIST) in the US have to say = about >> this? >=20 > No idea, and no idea why this would even be relevant to ietf standards = any > more than the opinions of any other regional standards bodies. >=20 >> So IPv6 ESP not fine? This is going to be a surprise to many. >=20 > It's just that there is plenty of hardware out there which won't = handle it > very well, that's all. >=20 >> As far as your comments on ASICs, a few questions: >>=20 >> 1. I am not getting why forwarding decisions are having to be made = by >> looking at anything other than the IP addresses. What am I missing >> here? >=20 > as Joel mentioned, ECMP on routers, or policy routing, or QoS. =20 And filtering=85 (often the same logic as forwarding). A large number of folk (including enterprises, content providers and = ISPs (for DoS mitigation)) want to be able to filter traffic, either to = only allow specific protocol / ports in, or to drop known attack = traffic. If there are extension headers your filtering logic may not be able to = see the L4 info, and (obviously) an attacker can insert extensions to = *cause* this.=20 > generic middleboxes will also make forwarding decisions based on = arbitrary > packet data. >=20 >> 2. Are you talking about ASICs on large core switches, routers, >> firewalls, load balancers or all the above? >=20 > pretty much any device which makes forwarding decisions on the = internet. Yup. >=20 >> 3. It was my understanding the the ASIC size was in the range of 256 >> bytes to 1K. This seems to leave plenty of room for the IPv6 main >> header & quite a few extensions. >=20 > it is very small on plenty of boxes, e.g. 64 bytes on c7600/rsp720. and attackers can add extension headers to force the upper-layer past = what the router can see. This makes the only safe assumption that the = traffic is bad / attack traffic and drop it. >=20 >> Realistically, we are talking about the extension header that we want >> implemented being available 5 - 6 years from now (or even more). We = are >> considering the time spent for the IETF approval process, then to get = on >> the development priority list for the stack software vendors, then to >> get that particular release of the operating system actually out at >> customer sites, etc. I hope the world will look a bit different at = that >> point in this regard. >=20 > An alternative point of view is: extension headers are causing more > problems as time goes on, not fewer. Let's fix this problem first = before we > define more of them and make our current / future problems worse. +1 W >=20 > Nick >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- What our ancestors would really be thinking, if they were alive today, = is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) From Ted.Lemon@nominum.com Wed Jun 5 09:12:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 mcr@sandelman.ca Wed Jun 5 09:24:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DE921F9BAF; Wed, 5 Jun 2013 09:24: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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=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 N6WUJ3Alrsvn; Wed, 5 Jun 2013 09:24:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 14AE721F9BA8; Wed, 5 Jun 2013 09:24:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D361E2017F; Wed, 5 Jun 2013 12:37:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7B08C63A8C; Wed, 5 Jun 2013 12:23:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D71E63A5E; Wed, 5 Jun 2013 12:23:35 -0400 (EDT) From: Michael Richardson To: "v6ops@ietf.org" , "Reinaldo Penno (repenno)" In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:24:31 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "repenno" =3D=3D repenno writes: repenno> On the other hand, as Rajiv captured,the number of repenno> UDP sessions can be much larger than the number of repenno> TCP. Because the way=20 repenno> dynamic webpages are constructed today, there are sometimes repenno> literally 100s=20 repenno> of DNS requests to download a single page. If one is doing CGN, wouldn't it be reasonable to point customers' at=20 a recursive DNS server with an interface inside the CGN? This seems to also suggest that having a *caching* recursive DNS(SEC, HOMENET+, mDNS+) server inside the customer router is also a big win. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUa9mBoqHRg3pndX9AQK2bwQAt1HNs9Z9y6Cx5YGN4gjzRbMSkOxaA83a bze577xQlPzJVeTuWpAnVshnGH3xwq1hqpwito4AxJdZEjr5ZOlpBDZlgWLV7cbC RzOhujuQpiCxnBCuajA+ydpTj0HsQVYGuef39pKJtoLiBrDBjLuxsLCh8HVa8+uG noImTMghE/A= =DWE4 -----END PGP SIGNATURE----- --=-=-=-- From nalini.elkins@insidethestack.com Wed Jun 5 09:50:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B199721F99C0 for ; Wed, 5 Jun 2013 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 eI+RsDv2bIG8 for ; Wed, 5 Jun 2013 09:50:17 -0700 (PDT) Received: from nm10-vm5.access.bullet.mail.bf1.yahoo.com (nm10-vm5.access.bullet.mail.bf1.yahoo.com [216.109.114.212]) by ietfa.amsl.com (Postfix) with ESMTP id 4471921F91B1 for ; Wed, 5 Jun 2013 09:50:16 -0700 (PDT) Received: from [66.196.81.159] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 16:50:16 -0000 Received: from [98.139.44.97] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jun 2013 16:50:16 -0000 Received: from [98.139.44.64] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 16:50:15 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 16:50:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 798824.28736.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 77531 invoked by uid 60001); 5 Jun 2013 16:50:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370451015; bh=kwpAWcBxaw7HA4pbiF2dLjKl/Z/mjXo2VKW6z9pqgzM=; 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=0d/OuH7UzAcxaod147Lk0aMkwTgpIkTTrPQpBMDi+w+L8nWfvKdT+1LJuSi+7bpJ15Ak+XvkMDyn4+dY7Y6b6YjOYc9eSJEEqHaa8FH3KernyZMcFBhISJ5KOglr5RoXOW/GPHgGQotyfMUMY/UqYKyCxS1kO9qUgkyIgR2PlhI= X-YMail-OSG: NS.rlNgVM1kbdDkNT3RgQezrZ27WkUTAahNKcwIS4GOeeNL XwlveWQKeZvlztttsYnR6x5a2Y3CpH2UO0VOWjn3UVge6ot8bm8hhcgHnt.6 JJrTaNFN7hfT6KkrwQxS1h8vYIqFIGZqfOx0Sev4C7bnn2ZCAJJsb.topL6V UaFtH2WUJ92qrxrENteHKAhO68TsiLKnp9dPoF0RBKi.q_x_gJFvFTBalmFJ ZHlXjQ3ysK0Zgrrf7V0Q9_J330y2VjRGo66XIOpJnhGyXx7ykaIP3z9ueJGw rEvcNYPXkWTIHtCpEZcNaYrHG3B1xscQZTxI3BCGyWO.hK4SiwGz3yHJhJOU 6SjF2pigFD2frqgiie9cmH_deIfFB9tgsIt0S_Vby_3kjT_ENcnvttDhtUP7 2kVoFdbCkanmv7XcCb.bLqpYVE9eLVm8c0niFpCKeb6GUJbjYb3CrA6smyLy 0D_8jrvSmCrpDgjnL6c9rmKivGXRtgroIkl2Tr4kMiG.Lj1To2xnkwLvL57s zmwPNzk0ZpOB6n7fc9.oOG8f_Sxi2.DnrrYhWvnRdfcdTXkQZNDrSTH1SKSP JHZn77x4LDn.AJbMWkcJzvvhULDEIn3KVupChDSDSOzmgQi9oOcut Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 09:50:14 PDT X-Rocket-MIMEInfo: 002.001, Pj5BbiBhbHRlcm5hdGl2ZSBwb2ludCBvZiB2aWV3IGlzOiBleHRlbnNpb24gaGVhZGVycyBhcmUgY2F1c2luZyBtb3JlCj4.cHJvYmxlbXMgYXMgdGltZSBnb2VzIG9uLCBub3QgZmV3ZXIuIExldCdzIGZpeCB0aGlzIHByb2JsZW0gZmlyc3QgYmVmb3JlIHdlCj4.ZGVmaW5lIG1vcmUgb2YgdGhlbSBhbmQgbWFrZSBvdXIgY3VycmVudCAvIGZ1dHVyZSBwcm9ibGVtcyB3b3JzZS4KCkRlZmluaXRlbHkgd2Ugc2hvdWxkIGZpeCB0aGUgcHJvYmxlbSB3aXRoIGV4dGVuc2lvbiBoZWFkZXJzLiDCoENvdWxkIG5vdCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> Message-ID: <1370451014.51100.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 09:50:14 -0700 (PDT) From: Nalini Elkins To: Nick Hilliard In-Reply-To: <51AF5A52.8010100@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:50:23 -0000 >>An alternative point of view is: extension headers are causing more=0A>>p= roblems as time goes on, not fewer. Let's fix this problem first before we= =0A>>define more of them and make our current / future problems worse.=0A= =0ADefinitely we should fix the problem with extension headers. =C2=A0Could= not agree more.=0A=0ABUT, I also think that we should proceed with our pro= posal for not a NEW extension header but an implementation of an existing h= eader. - Destination Options.=0A=0AI also asked a couple of organizations w= ho have implemented IPv6 for a while if they disable IPv6 extension headers= :=0A=0AHere is the first reply:=0A=0A"To answer your question, we don't dis= able or block IPv6 extension=C2=A0headers. I'm not sure if our routers proc= ess them (or some of them)=C2=A0in software or not, but=C2=A0 I'll try to f= ind out. Either way, we=C2=A0haven't noticed an performance issue. Although= I guess we won't=C2=A0know for sure of the impact until the volume of IPv6= traffic scales=C2=A0up significantly in our network - v6 is still only abo= ut 8% of our=C2=A0total traffic. The most common extension header observed = in our=C2=A0network is the fragment header (usually because of fragmented D= NS=C2=A0UDP response messages)."=0A=0ABTW, I know that this organization us= es DNSSec, so that is why the fragmentation of DNS.=0A=0A2nd reply:=0A=0A"I= t depends. (don=E2=80=99t you hate that kind of answer). This is what I hav= e heard. On some of the older OS=E2=80=99s and equipment, they will drop th= e extension headers because they don=E2=80=99t know what to do with them. T= hen they started running in software because they didn=E2=80=99t have chips= ets supporting IPv6. I=E2=80=99m not sure who is running IPv6 in ASIC now b= ut I have heard that some company whose name I can=E2=80=99t remember is (t= he one that competes with CISCO on the big routers). =C2=A0That being said,= all of our traffic is outward facing systems that are not really inside ou= r network. We=E2=80=99re not running v6 inside the network yet."=0A=0ANow I= think that some of the discussion and differing points of view that we are= seeing on this set of discussions has to do with the difference between op= erators who run large private networks and operators who are on the Interne= t. =C2=A0We can control our environment to a much higher degree than those = on the Internet. =C2=A0We also need diagnostics and response time data in a= way that those on the Internet do not. =C2=A0If I might use my analogy of = animals in the savanna, we are giraffes and the others are zebras. =C2=A0Ou= r needs are similar but in some ways different.=0A=0AThe header we are sugg= esting is optional. =C2=A0If people don't want to use it, then they don't h= ave to. =C2=A0We will use it in our networks & make sure that our hardware = is configured to support it properly and that our vendors support it proper= ly.=0A=0AWe are just trying to take care of our operational needs in runnin= g real networks every day.=C2=A0=0A=0A=0AThanks,=0A=0ANalini Elkins=0AInsid= e Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com From nalini.elkins@insidethestack.com Wed Jun 5 09:51:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D430B21F9BFF for ; Wed, 5 Jun 2013 09:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 L4bSXF4W3fQn for ; Wed, 5 Jun 2013 09:51:50 -0700 (PDT) Received: from nm7-vm0.access.bullet.mail.mud.yahoo.com (nm7-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7F88B21F9C01 for ; Wed, 5 Jun 2013 09:51:47 -0700 (PDT) Received: from [66.94.237.126] by nm7.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Jun 2013 16:51:47 -0000 Received: from [66.94.237.111] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Jun 2013 16:51:47 -0000 Received: from [127.0.0.1] by omp1016.access.mail.mud.yahoo.com with NNFMP; 05 Jun 2013 16:51:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 200181.79836.bm@omp1016.access.mail.mud.yahoo.com Received: (qmail 3723 invoked by uid 60001); 5 Jun 2013 16:51:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370451106; bh=csSmX2cGg1DB3sa7320ef/Tj9eBTJtfciWoxwkRbh94=; 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=Ou6l6L2pYE2mJnzW5QYFKXdzlxvF2CSA6ALbBC5GECEUGspYpdLFDravZMr4285d7MMtAbzGEeBB3k/DVyjkt7CSdZNBp1hPwkDTMNrrWljAsiSXJs18f+fgjOJZTUCCi0fSVI8CS7dgCnqgi40NDPMpCvlejhJSkNSucEE3suQ= X-YMail-OSG: Qd1ZHoUVM1lUL9h.X6S_N4DM0MfsLnOLUYIPkm8aQMcL4HW JBBzf8WhIXCxGXh9YnVlrch3OUK7RIXrSVsINzXLmao3KmwDvjf2xZAE5SzK F0dDFIhWYHG8OD4EqDR0kxJWnEMO6ltXpb8ucWhatD5W2ILaCQhBl5B3YRl. bFYnuzpIyIOBjhcU43mRjOmJIR2QJFtm8PB93Eg9KXhZYett75oCXgmf_EGB rJWRTdKg363YZvopzZjcF.0FWMMUxTXXIIC1EMme7j3sKOKoHA3b.6N9iEE5 EuinqL.mMjrqKAawpUhopF5FF0plGeSLFA8enHqVGWyeUmbaNdUYhOGbItQl Ew_mbd6cbLmYo0SI.R_HZWMrDIBCE_E5uZDaqU0yxSdJUxYEOX9P9_RyqLio zgyHWWmr3_tGzYrqQx79o9w7npT2jckHBSaS0n6E7ZHmKYHgtO9FYhjdrPyq 5Xnos87f4WzHUnG_RMpu.9xcoI9i6Hvs_AuUd1HxroxBS7MDK0P2IG1Oba3A KAmnBjIiefnZglQxnLicp0FFw5gpGv1RKUpshPGEx7xLrHVbz2kcxr3uvxS5 3mG9ggbZWBozpXWwdMxenZhZckyxYusl.te3HX2hWfEHYRU...VF55T_W_n. .UGA9_NfamuN72_s- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 09:51:46 PDT X-Rocket-MIMEInfo: 002.001, Pj4gMy7CoCBJdCB3YXMgbXkgdW5kZXJzdGFuZGluZyB0aGUgdGhlIEFTSUMgc2l6ZSB3YXMgaW4gdGhlIHJhbmdlIG9mIDI1Ngo.PiBieXRlcyB0byAxSy7CoCBUaGlzIHNlZW1zIHRvIGxlYXZlIHBsZW50eSBvZiByb29tIGZvciB0aGUgSVB2NiBtYWluCj4.IGhlYWRlciAmIHF1aXRlIGEgZmV3IGV4dGVuc2lvbnMuCj7CoAo.IGl0IGlzIHZlcnkgc21hbGwgb24gcGxlbnR5IG9mIGJveGVzLCBlLmcuIDY0IGJ5dGVzIG9uIGM3NjAwL3JzcDcyMC4KCj4.IGFuZCBhdHRhY2tlcnMgY2FuIGFkZCBleHRlbnNpb24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> Message-ID: <1370451106.2292.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 09:51:46 -0700 (PDT) From: Nalini Elkins To: Warren Kumari , Nick Hilliard In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:51:58 -0000 >> 3.=A0 It was my understanding the the ASIC size was in the range of 256= =0A>> bytes to 1K.=A0 This seems to leave plenty of room for the IPv6 main= =0A>> header & quite a few extensions.=0A>=A0=0A> it is very small on plent= y of boxes, e.g. 64 bytes on c7600/rsp720.=0A=0A>> and attackers can add ex= tension headers to force the upper-layer past what the router can see. This= makes the only safe assumption that the traffic is bad / attack traffic an= d drop it.=0A=0A=0AIf on our controlled, secure private networks, we have a= ttackers who are able to modify packets. =A0We have much bigger problems th= an packets with IPv6 extension being dropped.=0A=A0=0AThanks,=0A=0A=0ANalin= i Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com From brian@innovationslab.net Wed Jun 5 09:57:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECDC21F9C0E for ; Wed, 5 Jun 2013 09:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 mCMkrS6WzUPb for ; Wed, 5 Jun 2013 09:57:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 562E321F9C19 for ; Wed, 5 Jun 2013 09:57:03 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 42DFC88112 for ; Wed, 5 Jun 2013 09:57:03 -0700 (PDT) Received: from 102523118.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 07170130003 for ; Wed, 5 Jun 2013 09:57:02 -0700 (PDT) Message-ID: <51AF6DDF.2060307@innovationslab.net> Date: Wed, 05 Jun 2013 12:57:03 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:57:11 -0000 On 6/5/13 12:10 PM, Warren Kumari wrote: > >>> As far as your comments on ASICs, a few questions: >>> >>> 1. I am not getting why forwarding decisions are having to be made by >>> looking at anything other than the IP addresses. What am I missing >>> here? >> >> as Joel mentioned, ECMP on routers, or policy routing, or QoS. > > And filtering… (often the same logic as forwarding). > A large number of folk (including enterprises, content providers and ISPs (for DoS mitigation)) want to be able to filter traffic, either to only allow specific protocol / ports in, or to drop known attack traffic. > If there are extension headers your filtering logic may not be able to see the L4 info, and (obviously) an attacker can insert extensions to *cause* this. > Yes, this concern has been raised in the past. And my question then was : Can anyone show us a legitimate use of a long chain of extension headers? I can't recall anyone providing such evidence, so my conclusion is that it is probably reasonable to drop packets that push the L4 header that far down the chain. I would still welcome input on legitimate packets containing long header chains... Regards, Brian From kaname@nttv6.jp Wed Jun 5 11:16:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133B621F9B3F; Wed, 5 Jun 2013 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=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 DZvU-ToUZH5O; Wed, 5 Jun 2013 11:16:17 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.148]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5221F9B09; Wed, 5 Jun 2013 11:16:17 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 3F00FBDC21; Thu, 6 Jun 2013 03:15:59 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id C1D9DE1E27; Thu, 6 Jun 2013 03:15:58 +0900 (JST) Message-ID: <51AF805D.4000101@nttv6.jp> Date: Thu, 06 Jun 2013 03:15:57 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "behave@ietf.org" , Michael Richardson , "Poscic, Kristian \(Kristian\)" , "Softwires-wg list \(softwires@ietf.org\)" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:16:22 -0000 With regard to the DNS packets, shortening the time-out of NAT table is another good solution. In larger environment, we tested that when the time-out of DNS was shortened to 3sec, the impact of such DNS requests was much smaller than TCP sessions. 3 sec is sufficient round-trip time in general situation. I don't think it's necessary to place a recursive DNS server inside the CGN. Though there are differences between Home NAPT44 and CGN, it will work well in both case. That is because there are many devices in home and those seldom access the web site within a short time simultaneously. regards, -- kaname (2013/06/06 1:27), Reinaldo Penno (repenno) wrote: > > On 6/5/13 1:23 PM, "Michael Richardson" wrote: > >>>>>>> "repenno" == repenno writes: >> repenno> On the other hand, as Rajiv captured,the number of >> repenno> UDP sessions can be much larger than the number of >> repenno> TCP. Because the way >> repenno> dynamic webpages are constructed today, there are sometimes >> repenno> literally 100s >> repenno> of DNS requests to download a single page. >> >> If one is doing CGN, wouldn't it be reasonable to point customers' at >> a recursive DNS server with an interface inside the CGN? > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup correctly. > >> This seems to also suggest that having a *caching* recursive DNS(SEC, >> HOMENET+, mDNS+) server inside the customer router is also a big win. > Yes, it is. > >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails >> [ >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 From fgont@si6networks.com Wed Jun 5 11:37:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3D421F8DDD for ; Wed, 5 Jun 2013 11:37:46 -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.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCv5-AY8jvIT for ; Wed, 5 Jun 2013 11:37: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 8819821F8263 for ; Wed, 5 Jun 2013 11:37:45 -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 1UkIaU-0003lX-Li; Wed, 05 Jun 2013 20:37:35 +0200 Message-ID: <51AF5858.3020207@si6networks.com> Date: Wed, 05 Jun 2013 17:25:12 +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 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:37:46 -0000 On 06/05/2013 04:45 PM, Nalini Elkins wrote: >>> IPv4 is no better of course - there are plenty of features that haven't worked on the Internet for a very long time. Record route? Source routing? Source quench? Non-TCP/UDP protocols? In IPv4, that all stopped working a while ago. > > There is a difference between basic functionality and relatively > peripheral functionality. I would put extension headers in the basic > category. In practice, it is not. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rajiva@cisco.com Wed Jun 5 11:45:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D6621F9AA6; Wed, 5 Jun 2013 11:45:56 -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 ahPZqpGqqQ2n; Wed, 5 Jun 2013 11:45:51 -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 B9F4721F99ED; Wed, 5 Jun 2013 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3077; q=dns/txt; s=iport; t=1370457948; x=1371667548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f5rug0kOETDeusEAiTCgIlRdRwbJjquFc+mpkHtKPCs=; b=GNVp3JFSu17BhPOp4oYnlZQGowSNnvT+lYD+Ars5789HeGInYYUszqoB q+b6ClM8lAh4Oww2h1M03X4gsicaBm5tK6dTTN1TdAOzF6hIJb371GtM7 8XKR4+DxSDF4yQC6bvimxWlYq2WD0T7lBFDuLHBSHcVUzbuzG+wfc31MX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAP6Gr1GtJXG+/2dsb2JhbABaFoJzML8xfxZ0giMBAQEDAQEBATc0CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIAYd+Bgy9T456MQcGgnRhA6NfhSCDD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216261513" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 18:45:48 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55Ijlrg014015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:45:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:45:47 -0500 From: "Rajiv Asati (rajiva)" To: "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAArsfrA= Date: Wed, 5 Jun 2013 18:45:46 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:45:56 -0000 Kristian,=20 > Thanks. Can you tell us in general what applications did you use for this= ? > This heavily depends on the application type in use...p2p apps, etc. Sinc= e > some apps spawn a large number of TCP ports for example. In my home, it is 99% web applications - predominant being OTT video consum= ption (besides SSL VPN for work). Wrt p2p, we aggressively use p2p telepho= ny (e.g. vonage, skype, facetime). > So the question is to what degree do you think is your sample > representative of a general user in any region? It is quite subjective to answer, but I think that it represents a reasonab= le chunk of the home internet usage around the world. Cheers, Rajiv > -----Original Message----- > From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel-lucent.= com] > Sent: Wednesday, June 05, 2013 9:33 AM > To: Rajiv Asati (rajiva); v6ops@ietf.org; Softwires-wg list > (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: RE: Home NAPT44 - How many ports? >=20 > Thanks. Can you tell us in general what applications did you use for this= ? > This heavily depends on the application type in use...p2p apps, etc. Sinc= e > some apps spawn a large number of TCP ports for example. >=20 > So the question is to what degree do you think is your sample > representative of a general user in any region? >=20 > For example does it cover 30% of users for an ISP in NA while it covers 8= 0% > of users for another ISP in APAC for example? >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Rajiv Asati (rajiva) > Sent: Wednesday, June 05, 2013 6:14 AM > To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); behave@ietf.o= rg > Cc: Erik Kline (ek@google.com) > Subject: [BEHAVE] Home NAPT44 - How many ports? >=20 > Some of you may recall our discussion (during the last IETF) around "how > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? >=20 > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva >=20 > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. Suffice to say, this is just a sample representation, > since the port utilization would vary home to home, based on number of > active devices, type of applications, the degree of simultaneous device o= r > application usage etc. >=20 > If any of you are doing similar monitoring, then please share. >=20 > Cheers, > Rajiv >=20 > PS: Thanks to Erik Kline, who explained (with sufficient details) how to = use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. >=20 > PS: My home has 3-4 active devices. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rajiva@cisco.com Wed Jun 5 11:51:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA89521F9BCF; Wed, 5 Jun 2013 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=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 lf18YyCgu1Ji; Wed, 5 Jun 2013 11:51:45 -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 7D1B821F9BC9; Wed, 5 Jun 2013 11:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3724; q=dns/txt; s=iport; t=1370458305; x=1371667905; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tOuNyimLohr8bAWf69RssZO9QB8zWwDSRLTaDlxJPpc=; b=BMToZLHFACDLOTGjeb7ecCyb+HM/DdbicEgQdf86IlY4PZ6tSOafjIiB jR+N9IxPCEpaBJxobEueYqqpYUKyC8nnK0xbt/oPOkh6nEM/0ClSQSbjS D9zcP1ULh4sN5uf7uTKY4afj2PUMJAMaY09ufz3MTV3jeanQPX7oEf65E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAMCHr1GtJV2b/2dsb2JhbABaFoJzML8xfxZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQgBiAQMvVCNaoEQMQcGgnRhA6NfhSCDD4FpPg X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219039825" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 18:51:36 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r55Ipa5R022335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:51:36 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:51:36 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkA== Date: Wed, 5 Jun 2013 18:51:35 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:51:50 -0000 Reinaldo, I agree with you. Until I enabled DNS proxy on my router, I noticed that UD= P NAT exceeded TCP NAT entries in few occasions. Since DNS proxy got enable= d, UDP NAT entries became negligible. One interesting observation is how the lowest number of TCP NAT entries sta= yed within the range throughout the night time (when the devices were not m= anually used) based on how many apps (on the smartphones) were left running= . For ex, ~200 TCP ports on April 13-14, or ~30 TCP ports June 4. Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 11:44 AM > To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); v6ops@ietf.org; So= ftwires- > wg list (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 > Yes, there are regional differences. But even then, in general, 90% of th= e > active users can be covered by 1000 ports. I have been collecting data fo= r > many years, and actually the number of TCP ports consumed have been > going Down due to a number of factors. >=20 > On the other hand, as Rajiv captured,the number of UDP sessions can be > much larger than the number of TCP. Because the way dynamic webpages > are constructed today, there are sometimes literally 100s of DNS requests= to > download a single page. >=20 >=20 >=20 > On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" > wrote: >=20 > >Thanks. Can you tell us in general what applications did you use for thi= s? > >This heavily depends on the application type in use...p2p apps, etc. > >Since some apps spawn a large number of TCP ports for example. > > > >So the question is to what degree do you think is your sample > >representative of a general user in any region? > > > >For example does it cover 30% of users for an ISP in NA while it covers > >80% of users for another ISP in APAC for example? > > > >-----Original Message----- > >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >Behalf Of Rajiv Asati (rajiva) > >Sent: Wednesday, June 05, 2013 6:14 AM > >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > >behave@ietf.org > >Cc: Erik Kline (ek@google.com) > >Subject: [BEHAVE] Home NAPT44 - How many ports? > > > >Some of you may recall our discussion (during the last IETF) around > >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs > move > >into > >A+P paradigm. ~500, ~1000, ~3000??? > > > >Well, I started monitoring my home router and plotting the NAPT44 port > >utilization on a minute-by-minute basis. You may find it here - > >http://www.employees.org/~rajiva > > > >In short, port range of 500 seems ok, though 1000 would be more than > >enough for my home. Suffice to say, this is just a sample > >representation, since the port utilization would vary home to home, > >based on number of active devices, type of applications, the degree of > >simultaneous device or application usage etc. > > > >If any of you are doing similar monitoring, then please share. > > > >Cheers, > >Rajiv > > > >PS: Thanks to Erik Kline, who explained (with sufficient details) how > >to use google charting for my data. And thanks to Xun Wang & Shaoshuai > >Dai for helping me out significantly. > > > >PS: My home has 3-4 active devices. > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave From touch@isi.edu Wed Jun 5 11:55:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80E821F9C07 for ; Wed, 5 Jun 2013 11:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az-6lkh82aNT for ; Wed, 5 Jun 2013 11:54:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2598D21F9BCE for ; Wed, 5 Jun 2013 11:54:19 -0700 (PDT) Received: from [204.140.155.196] ([204.140.155.196]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r55Iqqtu018239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jun 2013 11:53:01 -0700 (PDT) Message-ID: <51AF8908.8060306@isi.edu> Date: Wed, 05 Jun 2013 11:52:56 -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: Fernando Gont References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51AF5858.3020207@si6networks.com> In-Reply-To: <51AF5858.3020207@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: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:55:28 -0000 That's not "practice". That's a bug. We really ought to be more careful about the difference. Joe On 6/5/2013 8:25 AM, Fernando Gont wrote: > On 06/05/2013 04:45 PM, Nalini Elkins wrote: >>>> IPv4 is no better of course - there are plenty of features that haven't worked on the Internet for a very long time. Record route? Source routing? Source quench? Non-TCP/UDP protocols? In IPv4, that all stopped working a while ago. >> >> There is a difference between basic functionality and relatively >> peripheral functionality. I would put extension headers in the basic >> category. > > In practice, it is not. > > Cheers, > From rajiva@cisco.com Wed Jun 5 11:58:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6579221F9B84; Wed, 5 Jun 2013 11:58:05 -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.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=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 l9ST4iSDB90E; Wed, 5 Jun 2013 11:58:00 -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 B179121F9C14; Wed, 5 Jun 2013 11:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1370458627; x=1371668227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z7dErHKNz1kXk0WbYia6JgrHEdbkA7ClmZ6RunDjO2M=; b=EpbTkqSyabqfOCwLsd4z/kUh0yC+nT59MPRBBiR2z7kVguusLy8YGEi4 izyHyfiiaKOvK+Hs1Yx1U7PjQHaCA5/8f3+1i2bi/BeeyaoKlsRy5FulE bIwue49tGUOADatpS0zyti4jhfR2TtIGK+hEbE78850Gitu2iv3l392n/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAO2Ir1GtJV2c/2dsb2JhbABagwkwvzF/FnSCIwEBAQQ6PwwEAgEIEQQBAQEKFBAyHQgBAQQBDQUIFodvvVqOegYrBwaCdGEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219244957" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 18:57:06 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55Iv6s0024229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:57:06 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:57:05 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA///5RqA= Date: Wed, 5 Jun 2013 18:57:05 +0000 Message-ID: References: <20115.1370449415@sandelman.ca> <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:58:05 -0000 > >If one is doing CGN, wouldn't it be reasonable to point customers' at a > >recursive DNS server with an interface inside the CGN? >=20 > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. And in some cases, it is not possible depending on where the NAT function i= s placed and where the DNS server is placed. I recently ran into this in a = large mobile network design.=20 Nonetheless, it is desired, but it is not really a big deal, since UDP NAT = usage tends to be a lot less than that TCP NAT usage (barring few exception= s). > >This seems to also suggest that having a *caching* recursive DNS(SEC, > >HOMENET+, mDNS+) server inside the customer router is also a big win. >=20 > Yes, it is. Well, DNS resolver with or without proxy is a big win, I would say.=20 Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 12:28 PM > To: Michael Richardson; v6ops@ietf.org > Cc: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); Softwires-wg list > (softwires@ietf.org); behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 >=20 > On 6/5/13 1:23 PM, "Michael Richardson" wrote: >=20 > > > >>>>>> "repenno" =3D=3D repenno writes: > > repenno> On the other hand, as Rajiv captured,the number of > > repenno> UDP sessions can be much larger than the number of > > repenno> TCP. Because the way > > repenno> dynamic webpages are constructed today, there are > sometimes > > repenno> literally 100s > > repenno> of DNS requests to download a single page. > > > >If one is doing CGN, wouldn't it be reasonable to point customers' at a > >recursive DNS server with an interface inside the CGN? >=20 > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. >=20 > > > >This seems to also suggest that having a *caching* recursive DNS(SEC, > >HOMENET+, mDNS+) server inside the customer router is also a big win. >=20 > Yes, it is. >=20 > > > >-- > >] Never tell me the odds! | ipv6 mesh > >networks [ > >] Michael Richardson, Sandelman Software Works | network > >architect [ > >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rail= s > > [ > > From nalini.elkins@insidethestack.com Wed Jun 5 11:59:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8EF21F9C2F for ; Wed, 5 Jun 2013 11:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 6nnr9LfUGqyo for ; Wed, 5 Jun 2013 11:58:59 -0700 (PDT) Received: from nm16-vm0.access.bullet.mail.mud.yahoo.com (nm16-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.19]) by ietfa.amsl.com (Postfix) with ESMTP id 41C9621F9BDC for ; Wed, 5 Jun 2013 11:58:07 -0700 (PDT) Received: from [66.94.237.199] by nm16.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Jun 2013 18:58:06 -0000 Received: from [66.94.237.104] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Jun 2013 18:58:06 -0000 Received: from [127.0.0.1] by omp1009.access.mail.mud.yahoo.com with NNFMP; 05 Jun 2013 18:58:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 828053.92102.bm@omp1009.access.mail.mud.yahoo.com Received: (qmail 64584 invoked by uid 60001); 5 Jun 2013 18:58:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370458686; bh=6Plcn95kX5BoAb+bLVjR1xV2+Ww5dVFXwdw56Rf2WOA=; 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=au74XSyjZ5CNtXMrSaS2A5CdX+9s0hVmtHJ6rUA0oCthQoefQjNcgZz6RJ/kjdnEcPzp95HKpP4aQe1QxK1wpgc8tKJE8JtISJOpAHaecw/dBxif48ok3xc5Dihhiiddq8/16N0pLz5M50L+vGgf2XSFDAycdj5j1iM4vyoC9FE= X-YMail-OSG: 8OhGWJoVM1lA9WLSx0ZIn6FOilG8WFqDq806l_UeOO2mVMY XkSw5AxEfeu8.fCTi3JYt6Hu3FcStm9hIC1j.kUL_MziHnNxnAOd2t5aBJIL YyaRpQCA4wQtSPv5grTyPqRfZksdza8mAD3_lj5gqOvR46QJRUCW1SFegvgQ zmQV7hex5Iu3MBWqsNQImfdhSWEUWBVKfrkYJeTuDb6tU2lx_moHkTRcOMph YOVN0gZye2aIgsINWGdPXpMwTlp2eblcy6QJyZIO9MLSWUVvB7j.7cNeVbJN p5ZmuvmP91WAsLC1jGRAVRAUNHzs3wvGRFCItueAUZX8eR.t.IvESneQhhRz MUNxTXQzphzT7_ZlHy8KXrYedgJF51YF..GDL7DhY0CvVL3tIDCdpdfXC3Zw qDibknCvPDv3y_kquvZ.Rn.yRGcNulnR2rxptzKqcPznM5OB8R3DEbLNmN8S 3KKaoTq4hKrCipmtNzIOY8dXfuUUv3h5Ju1nebtlDiCAHJ0P4qgqZ5RQgo8v zPz65yGigYpMbKfVOUvcnmw_dX1f5EjVFVGDhTnv9bAbJ.eARtppCblL1VzO S5wioA.0BGqJV_oec9.GtXMYyxlOTjOIWpgjQz8PZT0WlX_xTFQ1mpF87HSE Nl9TXXVuwq6ROy99TPHN7PMx4f04- Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 11:58:06 PDT X-Rocket-MIMEInfo: 002.001, Pj5JIGNhbid0IHJlY2FsbCBhbnlvbmUgcHJvdmlkaW5nIHN1Y2ggZXZpZGVuY2UsIHNvIG15IGNvbmNsdXNpb24gaXMgdGhhdMKgCj4.aXQgaXMgcHJvYmFibHkgcmVhc29uYWJsZSB0byBkcm9wIHBhY2tldHMgdGhhdCBwdXNoIHRoZSBMNCBoZWFkZXIgdGhhdMKgCj4.ZmFyIGRvd24gdGhlIGNoYWluLsKgIEkgd291bGQgc3RpbGwgd2VsY29tZSBpbnB1dCBvbiBsZWdpdGltYXRlIHBhY2tldHPCoAo.PmNvbnRhaW5pbmcgbG9uZyBoZWFkZXIgY2hhaW5zLi4uCgoKSXQgZGVwZW5kcyBvbiB3aGF0IHlvdSBhcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> Message-ID: <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 11:58:06 -0700 (PDT) From: Nalini Elkins To: Brian Haberman , "v6ops@ietf.org" In-Reply-To: <51AF6DDF.2060307@innovationslab.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1350959728-1370458686=:46843" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:59:04 -0000 --1510626085-1350959728-1370458686=:46843 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>I can't recall anyone providing such evidence, so my conclusion is that= =C2=A0=0A>>it is probably reasonable to drop packets that push the L4 heade= r that=C2=A0=0A>>far down the chain.=C2=A0 I would still welcome input on l= egitimate packets=C2=A0=0A>>containing long header chains...=0A=0A=0AIt dep= ends on what you are calling "long". =C2=A0If long =3D 256 bytes or more, t= hen OK. =C2=A0If long =3D less than 64 bytes, I would say not OK as that pr= ecludes just about everything.=0A=C2=A0=0AThanks,=0A=0A=0ANalini Elkins=0AI= nside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_= _______________________________=0A From: Brian Haberman =0ATo: v6ops@ietf.org =0ASent: Wednesday, June 5, 2013 9:57 AM=0ASub= ject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed= =0A =0A=0AOn 6/5/13 12:10 PM, Warren Kumari wrote:=0A>=0A>>> As far as your= comments on ASICs, a few questions:=0A>>>=0A>>> 1.=C2=A0 I am not getting = why forwarding decisions are having to be made by=0A>>> looking at anything= other than the IP addresses.=C2=A0 What am I missing=0A>>> here?=0A>>=0A>>= as Joel mentioned, ECMP on routers, or policy routing, or QoS.=0A>=0A> And= filtering=E2=80=A6 (often the same logic as forwarding).=0A> A large numbe= r of folk (including enterprises, content providers and ISPs (for DoS mitig= ation)) want to be able to filter traffic, either to only allow specific pr= otocol / ports in, or to drop known attack traffic.=0A> If there are extens= ion headers your filtering logic may not be able to see the L4 info, and (o= bviously) an attacker can insert extensions to *cause* this.=0A>=0A=0AYes, = this concern has been raised in the past.=C2=A0 And my question then was = =0A: Can anyone show us a legitimate use of a long chain of extension heade= rs?=0A=0AI can't recall anyone providing such evidence, so my conclusion is= that =0Ait is probably reasonable to drop packets that push the L4 header = that =0Afar down the chain.=C2=A0 I would still welcome input on legitimate= packets =0Acontaining long header chains...=0A=0ARegards,=0ABrian=0A=0A___= ____________________________________________=0Av6ops mailing list=0Av6ops@i= etf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops --1510626085-1350959728-1370458686=:46843 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
>>I can't recall= anyone providing such evidence, so my conclusion is that 
>>i= t is probably reasonable to drop packets that push the L4 header that =
>>far down the chain.  I would still welcome input on legitim= ate packets 
>>containing long header chains...<= /div>
<= span style=3D"font-family: 'times new roman', 'new york', times, serif;">
It depends on what you are calling "= long".  If long =3D 256 bytes or more, then OK.  If long =3D less= than 64 bytes, I would say not OK as that precludes just about everything.=
 
Thanks,

<= div>Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidet= hestack.com

From: Brian Haberman <brian@innovationslab.net>
To: v6ops@ietf.org
Sent: Wednesday, June 5, 2013 9:57 AM
= Subject: Re: [v6ops] new draf= t: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

=0AOn 6/5/13 12:10 PM, Warren Kumari wrote:
&= gt;
>>> As far as your comments on ASICs, a few questions:
&= gt;>>
>>> 1.  I am not getting why forwarding decisi= ons are having to be made by
>>> looking at anything other than= the IP addresses.  What am I missing
>>> here?
>>= ;
>> as Joel mentioned, ECMP on routers, or policy routing, or QoS= .
>
> And filtering=E2=80=A6 (often the same logic as forwardin= g).
> A large number of folk (including enterprises, content provider= s and ISPs (for DoS mitigation)) want to be able to filter traffic, either = to only allow specific protocol / ports in, or to drop known attack traffic= .
> If there are extension headers your filtering logic may not be ab= le to see the L4 info, and (obviously) an attacker can insert extensions to= *cause* this.
>

Yes, this concern has been raised in the past= .  And my question then was
: Can anyone show us a legitimate use of a long chain of extension= headers?

I can't recall anyone providing such evidence, so my concl= usion is that
it is probably reasonable to drop packets that push the L= 4 header that
far down the chain.  I would still welcome input on = legitimate packets
containing long header chains...

Regards,
= Brian

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

--1510626085-1350959728-1370458686=:46843-- From rajiva@cisco.com Wed Jun 5 12:05:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CB521F8F4A; Wed, 5 Jun 2013 12:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 4Z2FD7NPuYv0; Wed, 5 Jun 2013 12:05:18 -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 BBF6521F9C3D; Wed, 5 Jun 2013 12:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1754; q=dns/txt; s=iport; t=1370459010; x=1371668610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y58flFdw94Td7kMJ2B/nZ4ah0aqCovmOUxMFBxA5T+0=; b=SKZelwNloob1RIqjCrLYYIcflwuRaac7/UD1Hnw9989XP3hpIu7fMs+C mBHD0J5CVVzwkfB/3IeNLkUeSyt5RpMqrtBuYF0sg7Z33BZo5KDDf0yXa MJmm5u6I6Gvh4eu3DgQc4yeqLJQQcLL7+JBU/xW2/1Gm8+pxgZv8Vjeln k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHiKr1GtJXHB/2dsb2JhbABagwkwvzZ/FnSCIwEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAQEEDgUIiAW9Xo56BisHBoJ0YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216270443" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 19:03:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r55J3Sjw030404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:03:28 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:03:28 -0500 From: "Rajiv Asati (rajiva)" To: Michael Richardson Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAMUx6AAAA8pzA= Date: Wed, 5 Jun 2013 19:03:27 +0000 Message-ID: References: <24499.1370440297@sandelman.ca> In-Reply-To: <24499.1370440297@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:05:24 -0000 Hi Michael, Total 8 computing devices. Usually 2-4 active devices. My ISP is yet to enable IPv6 in my location, and I have purposely disabled = HE IPv6 to collect my IPv4 NAT data of this round, before enabling my HE IP= v6 to contrast the IPv4 NAT usage. Host based IPSec VPN or SSL VPN on one device.=20 A lots of Vonage & Skype & FT usage. Predominantly OTT video consumption. Cheers, Rajiv > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: Wednesday, June 05, 2013 9:52 AM > To: Rajiv Asati (rajiva) > Cc: Softwires-wg list (softwires@ietf.org); Erik Kline (ek@google.com); > v6ops@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > >>>>> "rajiva" =3D=3D rajiva writes: > rajiva> In short, port range of 500 seems ok, though 1000 would be > rajiva> more than enough for my home. Suffice to say, this is just a > rajiva> sample representation, since the port utilization would vary > rajiva> home to home, based on number of active devices, type of > rajiva> applications, the degree of simultaneous device or > rajiva> application usage etc. >=20 > You are a home of how many computers? How many active people? > (I don't assume those are 1:1...) > I guess you have no IPv6 running? > SIP? Skype? VPN (what kind? does it terminate on a desktop, or on your > "router"?) >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 From rajiva@cisco.com Wed Jun 5 12:07:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE2121F9691; Wed, 5 Jun 2013 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=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 ntWVzFDX7n0N; Wed, 5 Jun 2013 12:06:59 -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 B721121F918C; Wed, 5 Jun 2013 12:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2860; q=dns/txt; s=iport; t=1370459109; x=1371668709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2GshIMoSvnWIY4eCNh2XLvAdjstYt3mbx9PeWg9Ijk4=; b=mw7aEgHHwxtpeRgshM2GZW7Ta4GB/Yb1TbCqgU49zXpacIBfV0xPjoMm fXz4GQPgCCaQbYoD8fi4HXHaJ5AxR38YAYYCgZ6UlmgZ9R+mj5E1w0XvN 8OUm1YcsJBhRaku9KyKxii3JLZd+PgspVfPgqn5S4nk5eYE7aFvWdEWhO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFaLr1GtJXG+/2dsb2JhbABagwkwvzh/FnSCIwEBAQQBAQE3NAsMBAIBCBEBAwEBAQoUCQcnCxQDBggCBAENBQgTA4dvDL1SjnoGKwcGgnRhA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219046649" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 19:04:44 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55J4iqv030246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:04:44 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:04:44 -0500 From: "Rajiv Asati (rajiva)" To: kaname nishizuka , "Reinaldo Penno (repenno)" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwAgABQeYCAAEZ/gA== Date: Wed, 5 Jun 2013 19:04:43 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> <51AF805D.4000101@nttv6.jp> In-Reply-To: <51AF805D.4000101@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "behave@ietf.org" , Michael Richardson , "Poscic, Kristian \(Kristian\)" , "Softwires-wg list \(softwires@ietf.org\)" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:07:05 -0000 Kaname-san, That's a good suggestion, though the captured data suggests that UDP NAT ex= haustion is not a problem, but TCP NAT is. Cheers, Rajiv > -----Original Message----- > From: kaname nishizuka [mailto:kaname@nttv6.jp] > Sent: Wednesday, June 05, 2013 2:16 PM > To: Reinaldo Penno (repenno) > Cc: Michael Richardson; v6ops@ietf.org; Softwires-wg list > (softwires@ietf.org); Poscic, Kristian (Kristian); behave@ietf.org; Erik = Kline > (ek@google.com); Rajiv Asati (rajiva) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > With regard to the DNS packets, shortening the time-out of NAT table is > another good solution. >=20 > In larger environment, we tested that when the time-out of DNS was > shortened to 3sec, the impact of such DNS requests was much smaller than > TCP sessions. > 3 sec is sufficient round-trip time in general situation. > I don't think it's necessary to place a recursive DNS server inside the C= GN. >=20 > Though there are differences between Home NAPT44 and CGN, it will work > well in both case. > That is because there are many devices in home and those seldom access > the web site within a short time simultaneously. >=20 > regards, > -- > kaname >=20 > (2013/06/06 1:27), Reinaldo Penno (repenno) wrote: > > > > On 6/5/13 1:23 PM, "Michael Richardson" > wrote: > > > >>>>>>> "repenno" =3D=3D repenno writes: > >> repenno> On the other hand, as Rajiv captured,the number of > >> repenno> UDP sessions can be much larger than the number of > >> repenno> TCP. Because the way > >> repenno> dynamic webpages are constructed today, there are > sometimes > >> repenno> literally 100s > >> repenno> of DNS requests to download a single page. > >> > >> If one is doing CGN, wouldn't it be reasonable to point customers' at > >> a recursive DNS server with an interface inside the CGN? > > Yes. That's what I suggest. But some people use, say, Google's > > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. > > > >> This seems to also suggest that having a *caching* recursive DNS(SEC, > >> HOMENET+, mDNS+) server inside the customer router is also a big win. > > Yes, it is. > > > >> -- > >> ] Never tell me the odds! | ipv6 mesh > >> networks [ > >> ] Michael Richardson, Sandelman Software Works | network > >> architect [ > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on ra= ils > >> [ > >> > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 >=20 > -- > ---- > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 From fgont@si6networks.com Wed Jun 5 12:07:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC721F9C89 for ; Wed, 5 Jun 2013 12:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 tXQ6hjwfpntg for ; Wed, 5 Jun 2013 12:07:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DC8B821F8470 for ; Wed, 5 Jun 2013 12:07:10 -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 1UkJ2w-0004Vc-6v; Wed, 05 Jun 2013 21:06:59 +0200 Message-ID: <51AF8C42.4080305@si6networks.com> Date: Wed, 05 Jun 2013 21:06: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 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51AF5858.3020207@si6networks.com> <51AF8908.8060306@isi.edu> In-Reply-To: <51AF8908.8060306@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:07:42 -0000 On 06/05/2013 08:52 PM, Joe Touch wrote: > That's not "practice". That's a bug. We really ought to be more careful > about the difference. "In practce" == nothing depends nowadays on the use of IPv6 extension headers. And since they are unreliable, I doubt anyone will want to make their [whatever] depend on them. Not that I like it... but the cat seems to be out of the bag, already (earlier than expected, one might argue). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian@innovationslab.net Wed Jun 5 12:10:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4013621F9643 for ; Wed, 5 Jun 2013 12:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 fCoP641vTyfr for ; Wed, 5 Jun 2013 12:10:31 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id AA28A21F8470 for ; Wed, 5 Jun 2013 12:09:09 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4800D880F7 for ; Wed, 5 Jun 2013 12:09:09 -0700 (PDT) Received: from 102523118.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 11061130003 for ; Wed, 5 Jun 2013 12:09:08 -0700 (PDT) Message-ID: <51AF8CD5.8080802@innovationslab.net> Date: Wed, 05 Jun 2013 15:09:09 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "v6ops@ietf.org" References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:10:38 -0000 On 6/5/13 2:58 PM, Nalini Elkins wrote: >>> I can't recall anyone providing such evidence, so my conclusion is that >>> it is probably reasonable to drop packets that push the L4 header that >>> far down the chain. I would still welcome input on legitimate packets >>> containing long header chains... > > > It depends on what you are calling "long". If long = 256 bytes or more, then OK. If long = less than 64 bytes, I would say not OK as that precludes just about everything. > The question was really directed at two sets of folks and looking for two types of input. For the vendors, how far into a header chain can you reasonably parse? For operators, how many extension headers have you seen in the wild? Each has some interesting implications to this whole discussion. Regards, Brian From touch@isi.edu Wed Jun 5 12:17:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D120421F9BA3 for ; Wed, 5 Jun 2013 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd-9XzA87l+Y for ; Wed, 5 Jun 2013 12:17:12 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC721F9B8E for ; Wed, 5 Jun 2013 12:17:10 -0700 (PDT) Received: from [204.140.155.196] ([204.140.155.196]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r55JG9Z1022650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jun 2013 12:16:18 -0700 (PDT) Message-ID: <51AF8E7D.30708@isi.edu> Date: Wed, 05 Jun 2013 12:16:13 -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: Fernando Gont References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51AF5858.3020207@si6networks.com> <51AF8908.8060306@isi.edu> <51AF8C42.4080305@si6networks.com> In-Reply-To: <51AF8C42.4080305@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: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:17:19 -0000 On 6/5/2013 12:06 PM, Fernando Gont wrote: > On 06/05/2013 08:52 PM, Joe Touch wrote: >> That's not "practice". That's a bug. We really ought to be more careful >> about the difference. > > "In practce" == nothing depends nowadays on the use of IPv6 extension > headers. Including fragmentation? Since - in practice - ICMPs are blocked, how would that ever work? Joe From albert.e.manfredi@boeing.com Wed Jun 5 12:29:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 joelja@bogus.com Wed Jun 5 12:43:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6736921F9642 for ; Wed, 5 Jun 2013 12:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 qRC2SZgBW3-n for ; Wed, 5 Jun 2013 12:43:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C7CE021F9678 for ; Wed, 5 Jun 2013 12:43:26 -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 r55JhQVY027111 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 5 Jun 2013 19:43:26 GMT (envelope-from joelja@bogus.com) Message-ID: <51AF94D9.2020300@bogus.com> Date: Wed, 05 Jun 2013 12:43:21 -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: Brian Haberman , "v6ops@ietf.org" References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> In-Reply-To: <51AF8CD5.8080802@innovationslab.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]); Wed, 05 Jun 2013 19:43:26 +0000 (UTC) Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:43:28 -0000 On 6/5/13 12:09 PM, Brian Haberman wrote: > On 6/5/13 2:58 PM, Nalini Elkins wrote: >>>> I can't recall anyone providing such evidence, so my conclusion is >>>> that >>>> it is probably reasonable to drop packets that push the L4 header that >>>> far down the chain. I would still welcome input on legitimate packets >>>> containing long header chains... >> >> >> It depends on what you are calling "long". If long = 256 bytes or >> more, then OK. If long = less than 64 bytes, I would say not OK as >> that precludes just about everything. >> > > The question was really directed at two sets of folks and looking for > two types of input. For the vendors, how far into a header chain can > you reasonably parse? There are devices forwarding in the core of the internet that can only look out 53bytes (wonder how that number was picked) there are other that can do 256. there are few if any asic based forwarding engines that can do longer. > For operators, how many extension headers have you seen in the wild? > > Each has some interesting implications to this whole discussion. > > Regards, > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Wed Jun 5 13:13:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B8D21F9B09 for ; Wed, 5 Jun 2013 13:13:24 -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 pt0Z9-pxQl0f for ; Wed, 5 Jun 2013 13:13:23 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8068021F9AFE for ; Wed, 5 Jun 2013 13:12:25 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp1so521168pab.21 for ; Wed, 05 Jun 2013 13:12: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=MxP/MyF4LJMbcsMV81CqNuCQCdNTHPsQ6SmnwGmspVQ=; b=dnBohk0ZRKDnFYpOv80e1v5pHS1N6bkzbuQINW+wKtpB+KSeRvjb3JLqHsq33GdwmI 8utj/39iJN6GrAi+4ofoNHBb1Vd5SNOkA8zx64SHKCkz1OHw3KuktwvPE/PqKsODQShx tvNkAr0ewJFu7M7X7H1xV30sNZkwqfybkfSgsF1LDZT0WaVytlXmb26jbR4dQI+sHTa4 8yFugLZ3abLzxxpoVXkgGKjYkre7Q428c/WfxaQHJAu84mU0nSBJAuRS0hKEgPeO2AIf 1Dn4770ibEDHIHUauYZYEZ8M7HZDOVThAusIPjfgPSaSOq0Tna48n4O9mf46OxY7gxP3 JT7Q== X-Received: by 10.68.213.231 with SMTP id nv7mr35713556pbc.70.1370463145239; Wed, 05 Jun 2013 13:12:25 -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 de14sm22500107pac.10.2013.06.05.13.12.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 13:12:24 -0700 (PDT) Message-ID: <51AF9BA8.2030201@gmail.com> Date: Thu, 06 Jun 2013 08:12:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> In-Reply-To: <51AF94D9.2020300@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:13:25 -0000 On 06/06/2013 07:43, joel jaeggli wrote: ... > There are devices forwarding in the core of the internet that can only > look out 53bytes (wonder how that number was picked) Since I don't see a smiley, I need to say: ATM. From Ted.Lemon@nominum.com Wed Jun 5 13:15:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 brian.e.carpenter@gmail.com Wed Jun 5 13:15:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F88021F942B for ; Wed, 5 Jun 2013 13:15: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=[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 hBRxTKasjvM1 for ; Wed, 5 Jun 2013 13:15:50 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 42E5021F85BF for ; Wed, 5 Jun 2013 13:15:01 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wy17so2236308pbc.23 for ; Wed, 05 Jun 2013 13:14: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=piY9U/K+2ltVWExhKZj/dlv2afLOc1TWavjcJqP/QuA=; b=z51sFGulzT8CLHNvzuAeyBJHXBPzR+TrPsZsj7eYoT2qli246POYjo2oW1X7S/MWa0 DlglTmQjgtF+OhL452UysskiGRgXGZ3Ess1T6DVZ6QanUYqYjKs9ml5G8u8kNANi3iCa bt/vB0gv9WvPQCWIAAuUz5kFl3tIz1r7UOGYp4y7CfBAyY7OOyO0fs7Ao2OBsttIrrtb M0gWQ7sqIme2fPZKdoW1dKV+sILUvrsrWaW8ty1XC6Ht5h3rX1On0AY6qWsYNBM5bqY4 8vB23SWIg5Ps2eFYoHm1H7shceitg3j2+gvwISaxh7lzJUHIX+c+1ndXP9Y4d1kp3xux m+/w== X-Received: by 10.68.13.168 with SMTP id i8mr35282311pbc.86.1370463265000; Wed, 05 Jun 2013 13:14:25 -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 l4sm69443335pbo.6.2013.06.05.13.14.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 13:14:24 -0700 (PDT) Message-ID: <51AF9C24.3080406@gmail.com> Date: Thu, 06 Jun 2013 08:14:28 +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 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51AF5858.3020207@si6networks.com> <51AF8908.8060306@isi.edu> <51AF8C42.4080305@si6networks.com> In-Reply-To: <51AF8C42.4080305@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:15:52 -0000 On 06/06/2013 07:06, Fernando Gont wrote: > On 06/05/2013 08:52 PM, Joe Touch wrote: >> That's not "practice". That's a bug. We really ought to be more careful >> about the difference. > > "In practce" == nothing depends nowadays on the use of IPv6 extension > headers. That isn't true. But please take this up on 6man. Brian From nalini.elkins@insidethestack.com Wed Jun 5 13:18:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1496021F9B6A for ; Wed, 5 Jun 2013 13:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 0ntvy-jtkYqh for ; Wed, 5 Jun 2013 13:18:06 -0700 (PDT) Received: from nm22-vm0.access.bullet.mail.sp2.yahoo.com (nm22-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.178]) by ietfa.amsl.com (Postfix) with ESMTP id B5C7421F9298 for ; Wed, 5 Jun 2013 13:18:06 -0700 (PDT) Received: from [98.139.44.98] by nm22.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 20:18:06 -0000 Received: from [98.139.44.89] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 20:18:06 -0000 Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 20:18:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 164066.44061.bm@omp1026.access.mail.sp2.yahoo.com Received: (qmail 28672 invoked by uid 60001); 5 Jun 2013 20:18:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370463485; bh=Y/BnYPo4fokmkP91wAaWYMLiaYTKL3sBKuMKjbL723k=; 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=3O6FFmgXZd3FNTTy8cbfkyVnoYqeqPWdhENRvVh2363kaiB8VUBF+thRBn5omUH10rCtkYU6QMMSX7xI75vpSmkakJptxRsn3TmfaYDMIAzWzoC4JsE9xtVz0aE8QJsgWrUIJ/jYK2lWWXOl9+WOxgTc/TXRxvN1jSv9NWW++E0= X-YMail-OSG: vGKMdMcVM1kkBL8vARxJktquC.Rq.vfRv3tIYIdZTTjrc_D DMjrtV59OmQIWsOy7lIQu0FexFstIqTHV4RsgUJ3QBfQATK77IrF6pNkoBQd Dx2rQtAo7EIikIbTKFoT1gf4itFND9P6Bo5G3CWHjZ4Whc0yK7E9EF3ClDVI WeGxCqR7L6ILXHDr9G33Vlkg7v41eUYj_cTenSwOEfJWrEx1vkmpWHENNBKw W3vA0zM_7XkfRAGGu8NJLTIgU5JBQSWE87uNLkEpedqIHS4gJAvWJxQqR.vM rBmbyVsL4W8Yku91kCc5LejyKoxsZYweaZuTqV_sBH_U7Hllk3yGdOmYC6CN tJJFmzEC0lKDOxjks6obHJY4Q1BH52aXMpTcB7GcIKFPDPEfOF98UASyQF4S 0zwJQPnO1GLRGQRvikhtGYck37AWdnZ5Op0MFSkZrXS5YUf5HevIdLX_Eplx G4UUiNdxuwwdOxzOy8hQq.AmbM1G_6RqDzcxs6MICIIhAGPmDtF5iHWDsHTm 5Id0NGGKM9rpC5S9HrXvF9wj04WeKyhmo9gGF_n.IWaPXd2sWdzDx8YvWnIi O1ddv_87j Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 13:18:05 PDT X-Rocket-MIMEInfo: 002.001, wqAKLi4uCj4gVGhlcmUgYXJlIGRldmljZXMgZm9yd2FyZGluZyBpbiB0aGUgY29yZSBvZiB0aGUgaW50ZXJuZXQgdGhhdCBjYW4gb25seQo.IGxvb2sgb3V0IDUzYnl0ZXMgKHdvbmRlciBob3cgdGhhdCBudW1iZXIgd2FzIHBpY2tlZCnCoCAKCj4.IFNpbmNlIEkgZG9uJ3Qgc2VlIGEgc21pbGV5LCBJIG5lZWQgdG8gc2F5OiBBVE0uCgpHdXlzLCBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcsIGJ1dCBhcmUgdGhlIDUzIGJ5dGUgQVNJQ3MgZm9yIEFUTSBzd2l0Y2hlcz8gwqBJZiBzbywgdGhlbiBhcmUgdGhleSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> Message-ID: <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 13:18:05 -0700 (PDT) From: Nalini Elkins To: Brian E Carpenter , joel jaeggli In-Reply-To: <51AF9BA8.2030201@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1491437797-1370463485=:28098" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:18:12 -0000 --1510626085-1491437797-1370463485=:28098 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0=0A...=0A> There are devices forwarding in the core of the internet that= can only=0A> look out 53bytes (wonder how that number was picked)=A0 =0A= =0A>> Since I don't see a smiley, I need to say: ATM.=0A=0AGuys, correct me= if I am wrong, but are the 53 byte ASICs for ATM switches? =A0If so, then = are they even parsing IP layer stuff or just sticking to layer 2?=0A_______= ________________________________________=0Av6ops mailing list=0Av6ops@ietf.= org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops --1510626085-1491437797-1370463485=:28098 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
 
...
> There are devices forwardin= g in the core of the internet that can only
> look out 53bytes (wonde= r how that number was picked) 

>> Since I don't see a sm= iley, I need to say: ATM.

Guys, correct me if I am wrong, but are the 53 = byte ASICs for ATM switches?  If so, then are they even parsing IP lay= er stuff or just sticking to layer 2?
__________________________________= _____________
v6ops mailing list
v6ops@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/v6ops


--1510626085-1491437797-1370463485=:28098-- From warren@kumari.net Wed Jun 5 13:24:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915ED21F9642 for ; Wed, 5 Jun 2013 13:24:06 -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 KQorWaaz0nFD for ; Wed, 5 Jun 2013 13:24:02 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62BD21F91A3 for ; Wed, 5 Jun 2013 13:24:01 -0700 (PDT) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id EA2EF1B409A5; Wed, 5 Jun 2013 16:24:00 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 15:24:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com > To: Nalini Elkins X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:24:06 -0000 On Jun 5, 2013, at 3:18 PM, Nalini Elkins = wrote: > =20 > ... > > There are devices forwarding in the core of the internet that can = only > > look out 53bytes (wonder how that number was picked) =20 >=20 > >> Since I don't see a smiley, I need to say: ATM. >=20 > Guys, correct me if I am wrong, Sure. > but are the 53 byte ASICs for ATM switches? No. > If so, then are they even parsing IP layer stuff or just sticking to = layer 2? Layer3. As *an* example, Juniper Martini architecture boxes: "The Martini architecture is applied most directly in the M40, M20, M5, = and M10 routers, and is used in a scaled up form in theM160 and a scaled = down form in the Calvin architecture routers, the M7i and M10i." There are many many many deployed boxes like this (and operators who are = currently dropping all traffic that doesn't have the next-header as = TCP/UDP/ICMP). W > _______________________________________________ > 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 Eagles soar but a weasel will never get sucked into a jet engine=20 From brian.e.carpenter@gmail.com Wed Jun 5 13:44:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285FC21E804B for ; Wed, 5 Jun 2013 13:44: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=[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 PJwuuafBgkjG for ; Wed, 5 Jun 2013 13:44:10 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A050321E804E for ; Wed, 5 Jun 2013 13:43:59 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wy17so2266964pbc.23 for ; Wed, 05 Jun 2013 13:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cjnrJLtdAOWd/0FxpWFfY5hrGTapf+8xwZvdTCCDRRg=; b=G74X6jwoFvoQNNI3oCxE2IWVOyxPkfDaUNfu8fQ6QsxuibCWvFfv6YCSHnl4WX15B6 y9MlfGzLx4bLfZMwW+SInioKx7mL7TkhSf1nuTZEjSPhmjqZUcSdFr8rxFI4ryzceHEY u6CFNnj+uwO9lDAJ+rFZbhl8rFgQUhBONKyRcg+j3leKjcPR/4dU7VkBHTu9M2cgaAUB mjPn1BqlbP5t4nKuTDnrJoHaztea3EBMkGtcgP2jXJ3FLQGzKjRp9sjTuPDZ0KZtAJ4D 4gn506rPJwXxDZzsSey8sXatM0wJvS2ixUZb1m+lM7p39hpn2RZ5bbyMa+KjW/sojaHA Jftg== X-Received: by 10.66.118.79 with SMTP id kk15mr35501677pab.193.1370465039777; Wed, 05 Jun 2013 13:43:59 -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 eq4sm32246950pad.16.2013.06.05.13.43.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 13:43:59 -0700 (PDT) Message-ID: <51AFA312.50500@gmail.com> Date: Thu, 06 Jun 2013 08:44:02 +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 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com > <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> In-Reply-To: <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:44:11 -0000 On 06/06/2013 08:24, Warren Kumari wrote: > On Jun 5, 2013, at 3:18 PM, Nalini Elkins wrote: > >> >> ... >>> There are devices forwarding in the core of the internet that can only >>> look out 53bytes (wonder how that number was picked) >>>> Since I don't see a smiley, I need to say: ATM. >> Guys, correct me if I am wrong, > > Sure. > >> but are the 53 byte ASICs for ATM switches? > > No. Oh? I bet you they are reusing existing integrated circuits designed to match entire ATM cells and nothing more. >> If so, then are they even parsing IP layer stuff or just sticking to layer 2? > > Layer3. As *an* example, Juniper Martini architecture boxes: > "The Martini architecture is applied most directly in the M40, M20, M5, and M10 routers, and is used in a scaled up form in theM160 and a scaled down form in the Calvin architecture routers, the M7i and M10i." > > There are many many many deployed boxes like this (and operators who are currently dropping all traffic that doesn't have the next-header as TCP/UDP/ICMP). As long as they don't claim to support IPv6 (as standardised by RFC 2460) there's no problem with that. However, I don't think the IETF should be making excuses for them. Brian From warren@kumari.net Wed Jun 5 13:49:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7B21F9AA8 for ; Wed, 5 Jun 2013 13:49:01 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcIX-S8jikrW for ; Wed, 5 Jun 2013 13:48:56 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B1621F9A9F for ; Wed, 5 Jun 2013 13:48:47 -0700 (PDT) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id 329491B401C5; Wed, 5 Jun 2013 16:48:47 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <51AFA312.50500@gmail.com> Date: Wed, 5 Jun 2013 15:48:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com > <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@ gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:49:02 -0000 On Jun 5, 2013, at 3:44 PM, Brian E Carpenter = wrote: > On 06/06/2013 08:24, Warren Kumari wrote: >> On Jun 5, 2013, at 3:18 PM, Nalini Elkins = wrote: >>=20 >>>=20 >>> ... >>>> There are devices forwarding in the core of the internet that can = only >>>> look out 53bytes (wonder how that number was picked) =20 >>>>> Since I don't see a smiley, I need to say: ATM. >>> Guys, correct me if I am wrong, >>=20 >> Sure. >>=20 >>> but are the 53 byte ASICs for ATM switches? >>=20 >> No. >=20 > Oh? I bet you they are reusing existing integrated circuits designed = to > match entire ATM cells and nothing more. >=20 >>> If so, then are they even parsing IP layer stuff or just sticking to = layer 2? >>=20 >> Layer3. As *an* example, Juniper Martini architecture boxes: >> "The Martini architecture is applied most directly in the M40, M20, = M5, and M10 routers, and is used in a scaled up form in theM160 and a = scaled down form in the Calvin architecture routers, the M7i and M10i." >>=20 >> There are many many many deployed boxes like this (and operators who = are currently dropping all traffic that doesn't have the next-header as = TCP/UDP/ICMP). >=20 > As long as they don't claim to support IPv6 (as standardised byRFC = 2460) > there's no problem with that. However, I don't think the IETF should = be > making excuses for them. So, if the device support looking 128 bytes into the packet is it RFC = 2460 "compliant"? 256 bytes? 512bytes?=20 It sure would to be nice if *some* carrier class boxes were=85 W >=20 > Brian >=20 --=20 Militant Agnostic -- I don't know and you don't either... From nalini.elkins@insidethestack.com Wed Jun 5 13:54:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1BA21F90EF for ; Wed, 5 Jun 2013 13:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.095, 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 6dragWoIEyIY for ; Wed, 5 Jun 2013 13:54:22 -0700 (PDT) Received: from nm3-vm0.access.bullet.mail.sp2.yahoo.com (nm3-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88821F9AF9 for ; Wed, 5 Jun 2013 13:54:05 -0700 (PDT) Received: from [98.139.44.97] by nm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 20:54:01 -0000 Received: from [98.139.44.76] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 20:54:01 -0000 Received: from [127.0.0.1] by omp1013.access.mail.sp2.yahoo.com with NNFMP; 05 Jun 2013 20:54:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 243003.57118.bm@omp1013.access.mail.sp2.yahoo.com Received: (qmail 73620 invoked by uid 60001); 5 Jun 2013 20:54:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370465640; bh=FDLQ1SiqO5Cv7jdP6GScBvoQrtAwbEWfv5hhIv1EcPs=; 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=b9bnkgZI4ioWPsnGPEGdioL/qVrpqfX+7JuY3zxuMwGoIMbEaLTMMtSojoAd9mHYIsrh8/J+exhLhnF3kx4oEpgml9HlrT6heC8SXuJCenJUAJugXGi6Ja3iwhYR0R/qfjZJZGpLbF+ShKkzihgOQLJpekh1zjP4WvTe3qenfNM= X-YMail-OSG: 9AwI0zIVM1l5lnXJSFTZf4kv9YopTf61xa1KT.o4oQExi5L BRZJ.6VgwkTghF.yzyKYqqfCiJdTwU0327_Bb2a2dqoe9dEonxh1C0mYEZcy 34FrBcymRWEFYN9m0o99TK5q5cK0lKC2XY5I6A.PlImbzdFiesb9DqwQwIj3 EewI8Zq4Q1IzCaFMZ.56d96U2QFz0Jwu2ni7K0EKQrNnL9pjmdMyT0A2Z.PA Qwo3ZIwgNe_WzFj26U0F31uYbvqJBcVxT2.Xv7v5bJ7txIhBxiM0hkfCnTWu YJav7sg2P3sRrE7sav5w.KlNm7IP37LpLpC.p9UPyPm5firAitjDkcmUw_7Y bN3Gy2.HRiZ4ShzMkI2NvWV6CjluBDm_adkN6WUOXlTJX7ZeUNjipDoEtZLz ANmOcSP80QtX0jZaPL9vUUVpqyg5xMuzlovsROJf.ghVSEC_5k9CMoh6aSRO K2dRk4EBbWjSyhGslN054Ql5bDhgSSMRdkUQM2v9aut5WaCJmyFC5FJvuzis eB7sQ0hghfNpg6sg7xM9xHL49tBRjLMaPJMBjsKAVjraXnkMLs8rjswGvkAG Vu5OWIunfRg-- Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 13:54:00 PDT X-Rocket-MIMEInfo: 002.001, VGhhbmtzIGd1eXMhIMKgVmVyeSBpbGx1bWluYXRpbmcuIMKgCgpXZSB3aWxsIGNlcnRhaW5seSBiZSBvbiB0aGUgbG9va291dCBmb3IgdGhlc2Uga2luZCBvZiBib3hlcyBvbiBvdXIgbmV0d29ya3MgYXMgd2UgcHJvY2VlZC4KCgpPbiBKdW4gNSwgMjAxMywgYXQgMzo0NCBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6Cgo.IE9uIDA2LzA2LzIwMTMgMDg6MjQsIFdhcnJlbiBLdW1hcmkgd3JvdGU6Cj4.IE9uIEp1biA1LCAyMDEzLCBhdCAzOjE4IFBNLCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com > <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@ gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> Message-ID: <1370465640.73539.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 13:54:00 -0700 (PDT) From: Nalini Elkins To: Warren Kumari , Brian E Carpenter In-Reply-To: <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-1270490352-1370465640=:73539" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:54:38 -0000 ---1051860855-1270490352-1370465640=:73539 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks guys! =C2=A0Very illuminating. =C2=A0=0A=0AWe will certainly be on t= he lookout for these kind of boxes on our networks as we proceed.=0A=0A=0AO= n Jun 5, 2013, at 3:44 PM, Brian E Carpenter = wrote:=0A=0A> On 06/06/2013 08:24, Warren Kumari wrote:=0A>> On Jun 5, 2013= , at 3:18 PM, Nalini Elkins wrote:=0A>> = =0A>>> =0A>>> ...=0A>>>> There are devices forwarding in the core of the in= ternet that can only=0A>>>> look out 53bytes (wonder how that number was pi= cked)=C2=A0 =0A>>>>> Since I don't see a smiley, I need to say: ATM.=0A>>> = Guys, correct me if I am wrong,=0A>> =0A>> Sure.=0A>> =0A>>> but are the 53= byte ASICs for ATM switches?=0A>> =0A>> No.=0A> =0A> Oh? I bet you they ar= e reusing existing integrated circuits designed to=0A> match entire ATM cel= ls and nothing more.=0A> =0A>>> If so, then are they even parsing IP layer = stuff or just sticking to layer 2?=0A>> =0A>> Layer3. As *an* example, Juni= per Martini architecture boxes:=0A>> "The Martini architecture is applied m= ost directly in the M40, M20, M5, and M10 routers, and is used in a scaled = up form in theM160 and a scaled down form in the Calvin architecture router= s, the M7i and M10i."=0A>> =0A>> There are many many many deployed boxes li= ke this (and operators who are currently dropping all traffic that doesn't = have the next-header as TCP/UDP/ICMP).=0A> =0A> As long as they don't claim= to support IPv6 (as standardised byRFC 2460)=0A> there's no problem with t= hat. However, I don't think the IETF should be=0A> making excuses for them.= =0A=0ASo, if the device support looking 128 bytes into the packet is it RFC= 2460 "compliant"? 256 bytes? 512bytes? =0A=0AIt sure would to be nice if *= some* carrier class boxes were=E2=80=A6=0A=0AW=0A=0A> =0A>=C2=A0 Brian=0A>= =0A=0A-- =0AMilitant Agnostic -- I don't know and you don't either... ---1051860855-1270490352-1370465640=:73539 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks guys!  Very ill= uminating.  

We will certainly be on the lookout for = these kind of boxes on our networks as we proceed.

=0A
On Jun = 5, 2013, at 3:44 PM, Brian E Carpenter <brian.e.carpe= nter@gmail.com> wrote:

> On 06/06/2013 08:24, Warren Kumar= i wrote:
>> On Jun 5, 2013, at 3:18 PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
>= ;>
>>>
>>> ...
>>>> There are d= evices forwarding in the core of the internet that can only
>>>= > look out 53bytes (wonder how that number was picked) 
>>= ;>>> Since I don't see a smiley, I need to say: ATM.
>>&g= t; Guys, correct me if I am wrong,
>>
>> Sure.
>&g= t;
>>> but are the 53 byte ASICs for ATM switches?
>>=
>> No.
>
> Oh? I bet you they are reusing existing integrated circuits designed to
> match entire ATM cells an= d nothing more.
>
>>> If so, then are they even parsing = IP layer stuff or just sticking to layer 2?
>>
>> Layer3= . As *an* example, Juniper Martini architecture boxes:
>> "The Mar= tini architecture is applied most directly in the M40, M20, M5, and M10 rou= ters, and is used in a scaled up form in theM160 and a scaled down form in = the Calvin architecture routers, the M7i and M10i."
>>
>>= ; There are many many many deployed boxes like this (and operators who are = currently dropping all traffic that doesn't have the next-header as TCP/UDP= /ICMP).
>
> As long as they don't claim to support IPv6 (as st= andardised byRFC 2460)
> there's no problem with that. However, I don= 't think the IETF should be
> making excuses for them.

So, if = the device support looking 128 bytes into the packet is it RFC 2460 "compliant"? 256 bytes? 512bytes?

It sure would to be nice if *som= e* carrier class boxes were=E2=80=A6

W

>
>  B= rian
>

--
Militant Agnostic -- I don't know and you don't= either...





= ---1051860855-1270490352-1370465640=:73539-- From repenno@cisco.com Wed Jun 5 08:44:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AC421F9B09; Wed, 5 Jun 2013 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=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 W0LI7gt3oTY0; Wed, 5 Jun 2013 08:44:30 -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 42AE321F9AF8; Wed, 5 Jun 2013 08:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1370447068; x=1371656668; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jHCI/VUd1ESZajsS7uvW7d8rO0TeWCXku1tUS4ssbLA=; b=R/4VqVQr2yBXZvGbtaXuk/QQrKd3lbfVG8GyppDLAtBThdM40X+aHzlS 0xtGrnzhmA9WYpeBy9zLZIzAqCdZAKnUU4m8lICISBFDCVLtv9XiVYLN8 OLOC7ayQ+oUcHPmWMTmB4gHen2/LWGybEu0CFmNabTVuL4PdXT+vcWwka Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHRbr1GtJV2Z/2dsb2JhbABaFoJzML8sfRZ0giMBAQEEAQEBNzQLDAYBCBEEAQELFAkuCxQJCAEBBAENBQgBiAQMvTGOejEHBoJ0YQOjX4Uggw+CJw X-IronPort-AV: E=Sophos;i="4.87,807,1363132800"; d="scan'208";a="216150526" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 15:44:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55FiQnl029315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 15:44:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 10:44:25 -0500 From: "Reinaldo Penno (repenno)" To: "Poscic, Kristian (Kristian)" , "Rajiv Asati (rajiva)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAA= Date: Wed, 5 Jun 2013 15:44:25 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E976E5D808FB548B1EB58FDFADC5A00@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Jun 2013 14:06:02 -0700 Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:44:35 -0000 Yes, there are regional differences. But even then, in general, 90% of the active users can be covered by 1000 ports. I have been collecting data for many years, and actually the number of TCP ports consumed have been going Down due to a number of factors. On the other hand, as Rajiv captured,the number of UDP sessions can be much larger than the number of TCP. Because the way dynamic webpages are constructed today, there are sometimes literally 100s of DNS requests to download a single page. On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" wrote: >Thanks. Can you tell us in general what applications did you use for this? >This heavily depends on the application type in use...p2p apps, etc. >Since some apps spawn a large number of TCP ports for example. > >So the question is to what degree do you think is your sample >representative of a general user in any region? > >For example does it cover 30% of users for an ISP in NA while it covers >80% of users for another ISP in APAC for example? > >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >Of Rajiv Asati (rajiva) >Sent: Wednesday, June 05, 2013 6:14 AM >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >behave@ietf.org >Cc: Erik Kline (ek@google.com) >Subject: [BEHAVE] Home NAPT44 - How many ports? > >Some of you may recall our discussion (during the last IETF) around "how >many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into >A+P paradigm. ~500, ~1000, ~3000??? > >Well, I started monitoring my home router and plotting the NAPT44 port >utilization on a minute-by-minute basis. You may find it here - >http://www.employees.org/~rajiva > >In short, port range of 500 seems ok, though 1000 would be more than >enough for my home. Suffice to say, this is just a sample representation, >since the port utilization would vary home to home, based on number of >active devices, type of applications, the degree of simultaneous device >or application usage etc. > >If any of you are doing similar monitoring, then please share. > >Cheers, >Rajiv > >PS: Thanks to Erik Kline, who explained (with sufficient details) how to >use google charting for my data. And thanks to Xun Wang & Shaoshuai Dai >for helping me out significantly. > >PS: My home has 3-4 active devices. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From repenno@cisco.com Wed Jun 5 09:28:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4A821F9A87; Wed, 5 Jun 2013 09:28:06 -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.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=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 yGr-Y8p1Sl2C; Wed, 5 Jun 2013 09:28:01 -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 E5B1721F9B41; Wed, 5 Jun 2013 09:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1183; q=dns/txt; s=iport; t=1370449681; x=1371659281; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OY/eyAImJt4Tl3Iu98qKlM/W50kA4qcNe27B1L9XoPg=; b=cOsft9Jeg8eigQZG+z4vKr5sBFlP8rDoE+XyOenOT2uDRUVxYa9XHGI5 kd3f27y7UHu6IWBil68uJLbVU+dIrV1xwYfZZ/Pqjo2BOwDr4xOJrjDq/ RbFvVGpHoAlLfSZqXbe3O2PIYw6gd8PlnRznsJbEjVwOjIB0ZR+QzCN7w Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAP1fr1GtJXG+/2dsb2JhbABZgwkwvyx9FnSCJQEEOj8SAQgiFEIlAQEEAQ0FCBaHb707jnoxB4J6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,808,1363132800"; d="scan'208";a="219157721" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 16:28:00 +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 r55GS0Xb021059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 16:28:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 11:27:59 -0500 From: "Reinaldo Penno (repenno)" To: Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA Date: Wed, 5 Jun 2013 16:27:59 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <20115.1370449415@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Jun 2013 14:06:02 -0700 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:28:06 -0000 On 6/5/13 1:23 PM, "Michael Richardson" wrote: > >>>>>> "repenno" =3D=3D repenno writes: > repenno> On the other hand, as Rajiv captured,the number of > repenno> UDP sessions can be much larger than the number of > repenno> TCP. Because the way > repenno> dynamic webpages are constructed today, there are sometimes > repenno> literally 100s > repenno> of DNS requests to download a single page. > >If one is doing CGN, wouldn't it be reasonable to point customers' at >a recursive DNS server with an interface inside the CGN? Yes. That's what I suggest. But some people use, say, Google's DNS/OpenDns/etc and in some other cases the network is not setup correctly. > >This seems to also suggest that having a *caching* recursive DNS(SEC, >HOMENET+, mDNS+) server inside the customer router is also a big win. Yes, it is. > >--=20 >] Never tell me the odds! | ipv6 mesh >networks [=20 >] Michael Richardson, Sandelman Software Works | network >architect [=20 >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [=20 >=09 From repenno@cisco.com Wed Jun 5 12:25:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A581321F9AB8; Wed, 5 Jun 2013 12:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_83=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 XPoEmxseDO5A; Wed, 5 Jun 2013 12:25:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ABC1321F8808; Wed, 5 Jun 2013 12:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1370460318; x=1371669918; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b49WIL1Ep8qYdWlzth5PaJxUt/8WbzvqgibUvQOx73U=; b=dXje9RVTCeJK/Qu8GtSScltvBceLjH+GlEr1NubhVrOeu1xjEOOkVsp0 AnHsFKgTEGXU7T4CjZwRIwoxoOuv4ZYOBJpiVtaxpsdv9OuzyNk3gdVgo nw2tfIswffxaOJ7tzPVIip6/N6gadGXFJqMbWh25S2WvY8MMZmnF/qFvU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMNAHiPr1GtJV2Z/2dsb2JhbABaFoFbCIEQML8/fxZ0giMBAQEEAQEBNzQLDAYBCBEEAQEBChQJLgsUCQgBAQQBDQUIAYgEDL1SjWoPgQExBwaCdGEDo1+FIIMPgWkIFx8 X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219224168" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jun 2013 19:25:18 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55JPIEP026188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:25:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:25:17 -0500 From: "Reinaldo Penno (repenno)" To: "Rajiv Asati (rajiva)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkAAFj40A Date: Wed, 5 Jun 2013 19:25:16 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D2E7946FC55804CBDC577E1BBCD5C62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Jun 2013 14:06:02 -0700 Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:25:25 -0000 that's right. Depending on how much stuff you have running there might be long term TCP connections to mail servers, IM servers, Etc. With the 'connected home' I'm assuming this will go up. On 6/5/13 3:51 PM, "Rajiv Asati (rajiva)" wrote: >Reinaldo, > >I agree with you. Until I enabled DNS proxy on my router, I noticed that >UDP NAT exceeded TCP NAT entries in few occasions. Since DNS proxy got >enabled, UDP NAT entries became negligible. > >One interesting observation is how the lowest number of TCP NAT entries >stayed within the range throughout the night time (when the devices were >not manually used) based on how many apps (on the smartphones) were left >running. For ex, ~200 TCP ports on April 13-14, or ~30 TCP ports June 4. > >Cheers, >Rajiv > > >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Wednesday, June 05, 2013 11:44 AM >> To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); v6ops@ietf.org; >>Softwires- >> wg list (softwires@ietf.org); behave@ietf.org >> Cc: Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >> Yes, there are regional differences. But even then, in general, 90% of >>the >> active users can be covered by 1000 ports. I have been collecting data >>for >> many years, and actually the number of TCP ports consumed have been >> going Down due to a number of factors. >>=20 >> On the other hand, as Rajiv captured,the number of UDP sessions can be >> much larger than the number of TCP. Because the way dynamic webpages >> are constructed today, there are sometimes literally 100s of DNS >>requests to >> download a single page. >>=20 >>=20 >>=20 >> On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" >> wrote: >>=20 >> >Thanks. Can you tell us in general what applications did you use for >>this? >> >This heavily depends on the application type in use...p2p apps, etc. >> >Since some apps spawn a large number of TCP ports for example. >> > >> >So the question is to what degree do you think is your sample >> >representative of a general user in any region? >> > >> >For example does it cover 30% of users for an ISP in NA while it covers >> >80% of users for another ISP in APAC for example? >> > >> >-----Original Message----- >> >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> >Behalf Of Rajiv Asati (rajiva) >> >Sent: Wednesday, June 05, 2013 6:14 AM >> >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >> >behave@ietf.org >> >Cc: Erik Kline (ek@google.com) >> >Subject: [BEHAVE] Home NAPT44 - How many ports? >> > >> >Some of you may recall our discussion (during the last IETF) around >> >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs >> move >> >into >> >A+P paradigm. ~500, ~1000, ~3000??? >> > >> >Well, I started monitoring my home router and plotting the NAPT44 port >> >utilization on a minute-by-minute basis. You may find it here - >> >http://www.employees.org/~rajiva >> > >> >In short, port range of 500 seems ok, though 1000 would be more than >> >enough for my home. Suffice to say, this is just a sample >> >representation, since the port utilization would vary home to home, >> >based on number of active devices, type of applications, the degree of >> >simultaneous device or application usage etc. >> > >> >If any of you are doing similar monitoring, then please share. >> > >> >Cheers, >> >Rajiv >> > >> >PS: Thanks to Erik Kline, who explained (with sufficient details) how >> >to use google charting for my data. And thanks to Xun Wang & Shaoshuai >> >Dai for helping me out significantly. >> > >> >PS: My home has 3-4 active devices. >> >_______________________________________________ >> >Behave mailing list >> >Behave@ietf.org >> >https://www.ietf.org/mailman/listinfo/behave >> >_______________________________________________ >> >Behave mailing list >> >Behave@ietf.org >> >https://www.ietf.org/mailman/listinfo/behave > From repenno@cisco.com Wed Jun 5 12:39:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4C21F8CB5; Wed, 5 Jun 2013 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=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 jbPH-mz39LQo; Wed, 5 Jun 2013 12:39:52 -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 2E1FF21F84DF; Wed, 5 Jun 2013 12:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2825; q=dns/txt; s=iport; t=1370460459; x=1371670059; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/veQ6r28SRLWB37Ehd5E90SCc7kT+NUcWnvDVnnVIYo=; b=Tm3fL+iCeJpTlIYbkIy84+3JrGig+kKhVD6Qb6/iOmgyw5QBLrWbLO5g Bt95LtKcgQ4M9ho2nfwumZNXKlBtjsoBSiiNgRzffmsbCXW0yxrLWn5am 5z7zb0jDN/3G+Vvt7eHXvUuLusucM0KSEPhQ5uNtrpeoEuBVS+8zzkqmz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4NAPGPr1GtJV2c/2dsb2JhbABagXEIgRAwvz9/FnSCIwEBAQQ6PwwGAQgRBAEBAQoUQh0IAgQBDQUIFodvvVuOegYrBwaCdGEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216280288" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 19:27:38 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55JRcTf016095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:27:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:27:38 -0500 From: "Reinaldo Penno (repenno)" To: "Rajiv Asati (rajiva)" , Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA///5RqCAADjsgA== Date: Wed, 5 Jun 2013 19:27:38 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0BA6@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Jun 2013 14:06:02 -0700 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:39:57 -0000 There are some interesting measurements on this "background TCP radiation", i.e., how much state (and bandwidth) a home consumes even when there is no active use. On 6/5/13 3:57 PM, "Rajiv Asati (rajiva)" wrote: >> >If one is doing CGN, wouldn't it be reasonable to point customers' at a >> >recursive DNS server with an interface inside the CGN? >>=20 >> Yes. That's what I suggest. But some people use, say, Google's >> DNS/OpenDns/etc and in some other cases the network is not setup >> correctly. > >And in some cases, it is not possible depending on where the NAT function >is placed and where the DNS server is placed. I recently ran into this in >a large mobile network design. > >Nonetheless, it is desired, but it is not really a big deal, since UDP >NAT usage tends to be a lot less than that TCP NAT usage (barring few >exceptions). > >> >This seems to also suggest that having a *caching* recursive DNS(SEC, >> >HOMENET+, mDNS+) server inside the customer router is also a big win. >>=20 >> Yes, it is. > >Well, DNS resolver with or without proxy is a big win, I would say. > > >Cheers, >Rajiv > > >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Wednesday, June 05, 2013 12:28 PM >> To: Michael Richardson; v6ops@ietf.org >> Cc: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); Softwires-wg list >> (softwires@ietf.org); behave@ietf.org; Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >>=20 >>=20 >> On 6/5/13 1:23 PM, "Michael Richardson" wrote: >>=20 >> > >> >>>>>> "repenno" =3D=3D repenno writes: >> > repenno> On the other hand, as Rajiv captured,the number of >> > repenno> UDP sessions can be much larger than the number of >> > repenno> TCP. Because the way >> > repenno> dynamic webpages are constructed today, there are >> sometimes >> > repenno> literally 100s >> > repenno> of DNS requests to download a single page. >> > >> >If one is doing CGN, wouldn't it be reasonable to point customers' at a >> >recursive DNS server with an interface inside the CGN? >>=20 >> Yes. That's what I suggest. But some people use, say, Google's >> DNS/OpenDns/etc and in some other cases the network is not setup >> correctly. >>=20 >> > >> >This seems to also suggest that having a *caching* recursive DNS(SEC, >> >HOMENET+, mDNS+) server inside the customer router is also a big win. >>=20 >> Yes, it is. >>=20 >> > >> >-- >> >] Never tell me the odds! | ipv6 mesh >> >networks [ >> >] Michael Richardson, Sandelman Software Works | network >> >architect [ >> >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on >>rails >> > [ >> > > From joelja@bogus.com Wed Jun 5 15:13:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15E521F9931 for ; Wed, 5 Jun 2013 15:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 sSF7xKps4BGi for ; Wed, 5 Jun 2013 15:13:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D5ED821F990D for ; Wed, 5 Jun 2013 15:13:42 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r55MDW44028756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 5 Jun 2013 22:13:32 GMT (envelope-from joelja@bogus.com) Message-ID: <51AFB807.6020604@bogus.com> Date: Wed, 05 Jun 2013 15:13:27 -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: Brian E Carpenter , Warren Kumari References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com > <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> In-Reply-To: <51AFA312.50500@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 05 Jun 2013 22:13:32 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:13:49 -0000 On 6/5/13 1:44 PM, Brian E Carpenter wrote: > On 06/06/2013 08:24, Warren Kumari wrote: > Layer3. As *an* example, Juniper Martini architecture boxes: > "The Martini architecture is applied most directly in the M40, M20, M5, and M10 routers, and is used in a scaled up form in theM160 and a scaled down form in the Calvin architecture routers, the M7i and M10i." > > There are many many many deployed boxes like this (and operators who are currently dropping all traffic that doesn't have the next-header as TCP/UDP/ICMP). > As long as they don't claim to support IPv6 (as standardised by RFC 2460) > there's no problem with that. However, I don't think the IETF should be > making excuses for them. I don't have to make excuses for them. just forward packets across them. Asic design from 10 years ago has some compromises... eventually they'll age out of the internet. That's not the only platform will similarly low limitations , as noted there are platforms with higher limits all of them that I'm aware of have limits however. > > Brian > From owen@delong.com Wed Jun 5 15:23:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 brian.e.carpenter@gmail.com Wed Jun 5 15:52:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E38A21F971F for ; Wed, 5 Jun 2013 15:52: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=[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 Def-DkhqMfSc for ; Wed, 5 Jun 2013 15:52:17 -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 88C0721F9712 for ; Wed, 5 Jun 2013 15:52:17 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id bv13so2492243pdb.12 for ; Wed, 05 Jun 2013 15:51:49 -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=voVGQn8LRIMNUHk2r+1p7xwJ3tzV0JcWhB/Ns/u4OwI=; b=NOQgRdk22eWBfZJ3s5IQDc85WatVMcUUGb/FWdQS1Rb07S5Efazi2MJgM5R1SGwEn3 lGQ+y9UbaXucgqeOtDJKyaryZzCtidwXzubMAkKQ8MHaHLppy1fqPSIB34GoYFk6EprG 6JThWEVhYUv23GD1kf6Ci336oD0JmcrnYwLaPm802i3zZ2JFrTRDcuITHgY87g6k8vwZ 2cRuPHlm2H22ckdExaFTPZdmt8YdsOyUpePCte4y69AIV9YADJpCGew8mkUNS9dd7QJY JOea5CvkIqxyEomjpbLCyV3m7/2oBwyydNjn9e0E5IWIOdGaIrJ2Jrkr1js9wFlEJSVA UxGg== X-Received: by 10.68.13.168 with SMTP id i8mr35783754pbc.86.1370472709432; Wed, 05 Jun 2013 15:51:49 -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 ya4sm69834387pbb.24.2013.06.05.15.51.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 15:51:48 -0700 (PDT) Message-ID: <51AFC108.80701@gmail.com> Date: Thu, 06 Jun 2013 10:51:52 +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 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com > <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@ gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> In-Reply-To: <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:52:23 -0000 On 06/06/2013 08:48, Warren Kumari wrote: > On Jun 5, 2013, at 3:44 PM, Brian E Carpenter wrote: >=20 >> On 06/06/2013 08:24, Warren Kumari wrote: >>> On Jun 5, 2013, at 3:18 PM, Nalini Elkins wrote: >>> >>>> ... >>>>> There are devices forwarding in the core of the internet that can o= nly >>>>> look out 53bytes (wonder how that number was picked) =20 >>>>>> Since I don't see a smiley, I need to say: ATM. >>>> Guys, correct me if I am wrong, >>> Sure. >>> >>>> but are the 53 byte ASICs for ATM switches? >>> No. >> Oh? I bet you they are reusing existing integrated circuits designed t= o >> match entire ATM cells and nothing more. >> >>>> If so, then are they even parsing IP layer stuff or just sticking to= layer 2? >>> Layer3. As *an* example, Juniper Martini architecture boxes: >>> "The Martini architecture is applied most directly in the M40, M20, M= 5, and M10 routers, and is used in a scaled up form in theM160 and a scal= ed down form in the Calvin architecture routers, the M7i and M10i." >>> >>> There are many many many deployed boxes like this (and operators who = are currently dropping all traffic that doesn't have the next-header as T= CP/UDP/ICMP). >> As long as they don't claim to support IPv6 (as standardised byRFC 246= 0) >> there's no problem with that. However, I don't think the IETF should b= e >> making excuses for them. >=20 > So, if the device support looking 128 bytes into the packet is it RFC 2= 460 "compliant"? 256 bytes? 512bytes?=20 Well, yes, there's a problem there. The IPv6 header is a linked list of variable length. Hardware architectures that assume a consistent signature in the first 2**N bytes won't work well on a linked list. I don't know what to say since this has been the IPv6 architecture since 1996. All we can do, which a couple of active drafts in 6man are trying to do, is clarify and limit the scope of the issue. > It sure would to be nice if *some* carrier class boxes were=E2=80=A6 The design assumption was that line-speed boxes will not look beyond the first 40 bytes. As soon as they do so, you're into linked-list processing. Bian From Ted.Lemon@nominum.com Wed Jun 5 15:55:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 joelja@bogus.com Wed Jun 5 18:44:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE621F94DF for ; Wed, 5 Jun 2013 18:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyd-U84s+CkC for ; Wed, 5 Jun 2013 18:44:07 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6586021F94DC for ; Wed, 5 Jun 2013 18:44:04 -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 r561i1rk031083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 01:44:01 GMT (envelope-from joelja@bogus.com) Message-ID: <51AFE95B.2000004@bogus.com> Date: Wed, 05 Jun 2013 18:43:55 -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: Brian E Carpenter , Warren Kumari References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <1370463485.28098.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com > <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@ gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <51AFC108.80701@gmail.com> In-Reply-To: <51AFC108.80701@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]); Thu, 06 Jun 2013 01:44:02 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 01:44:08 -0000 On 6/5/13 3:51 PM, Brian E Carpenter wrote: > On 06/06/2013 08:48, Warren Kumari wrote: >> On Jun 5, 2013, at 3:44 PM, Brian E Carpenter wrote: >> >>> On 06/06/2013 08:24, Warren Kumari wrote: >>>> On Jun 5, 2013, at 3:18 PM, Nalini Elkins wrote: >>>> >>>>> ... >>>>>> There are devices forwarding in the core of the internet that can only >>>>>> look out 53bytes (wonder how that number was picked) >>>>>>> Since I don't see a smiley, I need to say: ATM. >>>>> Guys, correct me if I am wrong, >>>> Sure. >>>> >>>>> but are the 53 byte ASICs for ATM switches? >>>> No. >>> Oh? I bet you they are reusing existing integrated circuits designed to >>> match entire ATM cells and nothing more. >>> >>>>> If so, then are they even parsing IP layer stuff or just sticking to layer 2? >>>> Layer3. As *an* example, Juniper Martini architecture boxes: >>>> "The Martini architecture is applied most directly in the M40, M20, M5, and M10 routers, and is used in a scaled up form in theM160 and a scaled down form in the Calvin architecture routers, the M7i and M10i." >>>> >>>> There are many many many deployed boxes like this (and operators who are currently dropping all traffic that doesn't have the next-header as TCP/UDP/ICMP). >>> As long as they don't claim to support IPv6 (as standardised byRFC 2460) >>> there's no problem with that. However, I don't think the IETF should be >>> making excuses for them. >> So, if the device support looking 128 bytes into the packet is it RFC 2460 "compliant"? 256 bytes? 512bytes? > Well, yes, there's a problem there. The IPv6 header is a linked list > of variable length. Hardware architectures that assume a consistent > signature in the first 2**N bytes won't work well on a linked list. > > I don't know what to say since this has been the IPv6 architecture > since 1996. All we can do, which a couple of active drafts in 6man > are trying to do, is clarify and limit the scope of the issue. It is useful as a cogent jumping-off point to be able to describe things as they are rather than as we think they should be. while I think the later is important, the former is as well. If we're disappointed that Equipment Vendors (that is, some ietf participants) went off and built asics that allowed the internet to grow, businesses to be successful and incurred NRE associated with supporting protocols for which they were a decade or more away from recovering their investment on , then I don't know what to say except that I am not. The ipv6 forwarding architecture and requirements got to ride along with the ipv4 forwarding logic, if it hadn't or couldn't been that case for some reason it's entirely possible that it wouldn't exist. Their foresight and effort mean I can run my service on ipv4 and ipv6 today, with some caveats. >> It sure would to be nice if *some* carrier class boxes were… > The design assumption was that line-speed boxes will not look > beyond the first 40 bytes. Line speed in 1994 was on a general purpose cpu. A lot of assumptions about how forwarding was to be done were simply wrong. As it turns out for example we can forward on variable length headers (ipv4) as long as they're short. hop-by-hop options fall into the domain of linked list processing and they pose a similar problem. > As soon as they do so, you're into > linked-list processing. > > Bian > > From fgont@si6networks.com Wed Jun 5 18:52:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A440B21F8749 for ; Wed, 5 Jun 2013 18:52:00 -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 APUfU9+mQNmq for ; Wed, 5 Jun 2013 18:51:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECB521F8AC2 for ; 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 1UkPMk-0007Xo-Qx; Thu, 06 Jun 2013 03:51:52 +0200 Message-ID: <51AFEA1E.9050007@si6networks.com> Date: Thu, 06 Jun 2013 03:47:10 +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 References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> <8C48B86A895913448548E6D15DA7553B9008A9@xmb-rcd-x09.cisco.com> <1370100943.63117.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51AC9E8D.9060609@si6networks.com> <1370267962.59169.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A776074@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A776318@PWN401EA160.ent.corp.bcbsm.com> <1370443522.9335.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51AF5858.3020207@si6networks.com> <51AF8908.8060306@isi.edu> <51AF8C42.4080305@si6networks.com> <51AF9C24.3080406@gmail.com> In-Reply-To: <51AF9C24.3080406@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 01:52:01 -0000 On 06/05/2013 10:14 PM, Brian E Carpenter wrote: > On 06/06/2013 07:06, Fernando Gont wrote: >> On 06/05/2013 08:52 PM, Joe Touch wrote: >>> That's not "practice". That's a bug. We really ought to be more careful >>> about the difference. >> >> "In practce" == nothing depends nowadays on the use of IPv6 extension >> headers. > > That isn't true. But please take this up on 6man. Yep, I was sloppy: Certainly IPsec depends on extension headers. And fragmentation relies on the fragment header. .. I was actually thinking about Ext Headers carrying options (HBH, Gest Opt, etc.). Cheers, -- 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 Wed Jun 5 20:07:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 lorenzo@google.com Wed Jun 5 20:26:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C69821F90F4 for ; Wed, 5 Jun 2013 20:26:29 -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 f5U7j1rQFA0J for ; Wed, 5 Jun 2013 20:26:24 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id CA8E021F90FD for ; Wed, 5 Jun 2013 20:26:23 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so1571992qej.25 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=ZhxSR+Ldd+QuJiLRyoxeSBuq9m5mpcr7Gqwu9+vceRmPX377ugAPEvso0+q7wtyUuV l7Ox6xZqXmCxZX4NzN3zCsIGitwSvUQ4KpQo3aoS9wTv2Ie+H35FdN0Bc5D5Ne+y2Evs 33B3zQeaBPeUs0GrQWOKbyenRdZRxvoP4xn/pHCYHFPQR3mz+U/7fgMsWvnwHqnvgyhC K1BNs4QIJhr11FKqSVCdiC5eYRUiBCTsoTgsM7gxdH+S6PhNNFkgqPwrKPzkd2s067vm D3m9TVspIBjwRXaVsT7bz+eDHaovpS4qkWCd1fqd9LGz6e6FRejqr9WKUcGccG+uoUSy GIEQ== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf300fafb5eaa4e004de73e0d4 X-Gm-Message-State: ALoCoQlWeHtWDSWDMi7TUFFbpT7aVXa5HDU5ce+RNj4PcLmZJhe18P1Pi65S595AxsTF4ZLN3ko5HIKKtYxRLZnlEcb82hq1gqIGKxq1ouI5xo67ylQp2y+z5YbEsQTL+k6tvWt2JnCpbYww+0RCHlO3D51Z+7eCSY+z9cp+NS7T/CBWlaXfBc6hohtwFye1RopL0s8IMilR Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 03:26:29 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBAD21F9424 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 mXlXV8E2udde for ; Wed, 5 Jun 2013 20:30:56 -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 C798F21F9420 for ; Wed, 5 Jun 2013 20:30:55 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so25878qaj.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=aeljdqfDz+i38mvF7vSyznw7EtUBEnm8iIezJraV68DunMgjN1aumzk7frOcJzmx5c IgrY93bT4IevU+RYpO6LGR6jclF/SbB1qW6f7IqUuF8pj3NJH6uF73d7Cj/gt+xmU/5n o7rDK0Xa8ImNrjrv5d2d/2amMf1sAu2sZoT7rky3RBuoq+bGl24MmG/gZz7PmGJL1PrX Qc4x/5MUvN123RVSgBJuwgioVDhgjW2wAGmHEH7YEVuk0AuHn8kMjr6pjDJ1DwKjQEv0 FWK7aykKtVyeyYkCgFdIDwfigWafDOjJ7iF0y+sQyi4UKDxNRZApphUX/644aGdoMHDH smog== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bd75c5e24c65904de73f138 X-Gm-Message-State: ALoCoQnD+lPwNbfxSfp5MqbXYiuYKIm9Z1Lx77IqmhszT8FCERBOLWt/UC0z5Ooxbozv2t2Gxp9xmmhYy7srfPHIiJ3dtNjrnjzj0wXgBjl3jcWfo3Qma1GFc0jHZ8OTDoDzifzuytw+Uhz9ThA0eyyGXDaJXFzEQVYVG41a3a6F/0zdXpTzVtXb2KlhBO6Q2dHBM6lFyZoj Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 sthaug@nethelp.no Wed Jun 5 22:52:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E7421F8FA4 for ; Wed, 5 Jun 2013 22:52: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=[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 0cbh7yuMyHH5 for ; Wed, 5 Jun 2013 22:52:01 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 531C821F8AE8 for ; Wed, 5 Jun 2013 22:52:00 -0700 (PDT) Received: (qmail 77111 invoked from network); 6 Jun 2013 05:51:58 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Jun 2013 05:51:58 -0000 Date: Thu, 06 Jun 2013 07:51:58 +0200 (CEST) Message-Id: <20130606.075158.74674309.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com From: sthaug@nethelp.no In-Reply-To: <51AFC108.80701@gmail.com> References: <51AFA312.50500@ gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <51AFC108.80701@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: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 05:52:20 -0000 > > So, if the device support looking 128 bytes into the packet is it RFC 2460 "compliant"? 256 bytes? 512bytes? > > Well, yes, there's a problem there. The IPv6 header is a linked list > of variable length. Hardware architectures that assume a consistent > signature in the first 2**N bytes won't work well on a linked list. > > I don't know what to say since this has been the IPv6 architecture > since 1996. All we can do, which a couple of active drafts in 6man > are trying to do, is clarify and limit the scope of the issue. Isn't this a pretty fundamental problem/flaw? As a *user* of high speed routers, I want to know that my boxes are going to forward a packet within a certain small time - which means that the address *lookup* time must be bounded. A potentially long chain of headers which is *not* bounded doesn't give me confidence. So I will vote with my wallet and purchase boxes from the equipment vendors that bound the lookup time (and the number of bytes they look into the headers). Steinar Haug, AS 2116 From lorenzo@google.com Wed Jun 5 23:16:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F53121F957B for ; Wed, 5 Jun 2013 23:16: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 1mf48mdV4wH9 for ; Wed, 5 Jun 2013 23:16:55 -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 A512921F8EF2 for ; Wed, 5 Jun 2013 23:16:55 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so81047qab.7 for ; Wed, 05 Jun 2013 23:16: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=WJywKpCnjzLQGed8rfSEUZf9GiKTFdmal0XByl4AQww=; b=EJizCMQazsU0Swjv3yiPoLV0xG64x43n5OdZPbFA67EXaBPQMkKFAohwCunQjgxvCn zeYoPIbI8Zc0nbWCm9eGru/Ed0rSb7bOPsweJRzXlS9XucNRuwpZN6p7kXqoAxL0nf+u GBHrofl9AL9PQ+gEsCZIzxE89F7DWiLDuolU2mjXqpVO0TlGKe1PmkdZEfZdRo/qMl7/ P1vVE5SoKNL5ZdPB1b4e/vh7NgQ6F5mmAB6kQA7d9Uwf57qrXhKlpJ8wgfSmHoRHdXQ8 2ReF+dIH4UKKEc2QRzJCZRic62BzRMWEo047boLTt6lhShuKFjjQo0lhgN0bcPqp5KR6 JiyA== 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=WJywKpCnjzLQGed8rfSEUZf9GiKTFdmal0XByl4AQww=; b=HS8i4jelmKr5GN1Uzv63NGx87TbiAk+6lgtFAHhz7L8rJxP0OcK2y5pTU8X5QQVgFk tZhTh3vOTNRLgT8Z0nJiflltDtldPG1Mk0FWIoRAcdsT5XSbMf/5mxBjozWNZHo7uo87 XXEUyGdWvLL6BJboob7uFVie2ffxrhW71NDfc5vT75Wp1kDJ4iRs+MUQ7S8irdAy21E9 sZ3BGo8KNeN1RQ2WKS/8IIOukX1eAls9TKgYME4IHBoPQgrhuTSRX9CGFT1c7c1rPSWN YUtDEY3Ye3til8YpZcVDl6ZUY9ETPJXHhAwrhTGGPJXsZJNtlcJjPkZSK7bxwPgffAuu HboQ== X-Received: by 10.229.56.68 with SMTP id x4mr9439365qcg.70.1370499414968; Wed, 05 Jun 2013 23:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Wed, 5 Jun 2013 23:16:34 -0700 (PDT) In-Reply-To: <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 15:16:34 +0900 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=001a11331ce0cb6ee704de764214 X-Gm-Message-State: ALoCoQn8lwUG+IQvMs26Kc5TynPHmYhmK5ZB8U/HrROfJbanXzGBsbP8cH2TEFlfbe2XT7LW53fCig/ncStDrrYwwgXLm3n7lbVWI8mF2gEQV1Zcg3FYXqnpv+hwlvTLeCzOoeLQqyAifIkQ7L+w30172LIliJnzegfNKcgQLzsGkJgibLTlnHtPixdmK5Xsc/uGtdT69Bn5 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 06:16:56 -0000 --001a11331ce0cb6ee704de764214 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 5:48 AM, Warren Kumari wrote: > > As long as they don't claim to support IPv6 (as standardised byRFC 2460) > > there's no problem with that. However, I don't think the IETF should be > > making excuses for them. > > So, if the device support looking 128 bytes into the packet is it RFC 2460 > "compliant"? 256 bytes? 512bytes? > If you believe Nalini's argument above, to comply with RFC 2460, the router must be able to look 65575 bytes into the packet. RFC 2460 places no limits on the size of the extension header chain, the 16-bit payload length field counts up 65535, and you have to add 40 bytes for the IPv6 header. If you don't think that is realistic, then I agree with you. --001a11331ce0cb6ee704de764214 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 5:48 AM, Warren Kumari <warren@kum= ari.net> wrote:
    > As long as they don't claim to support IPv6 (as standard= ised byRFC 2460)
    > there's no problem with that. However, I don'= ;t think the IETF should be
    > making excuses for them.

    So, if the device support looking 128 bytes into the packet is it RFC= 2460 "compliant"? 256 bytes? 512bytes?

    =
    If you believe Nalini's argument above, to comply with= RFC 2460, the router must be able to look 65575 bytes into the packet. RFC= 2460 places no limits on the size of the extension header chain, the 16-bi= t payload length field counts up 65535, and you have to add 40 bytes for th= e IPv6 header.

    If you don't think that is realistic, t= hen I agree with you.
    --001a11331ce0cb6ee704de764214-- From lorenzo@google.com Wed Jun 5 23:20:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFAD21F98CC for ; Wed, 5 Jun 2013 23:20:30 -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=[AWL=-0.000, 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 Q+Cql-lZybiU for ; Wed, 5 Jun 2013 23:20:30 -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 3590421F9815 for ; Wed, 5 Jun 2013 23:20:30 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so81867qab.18 for ; Wed, 05 Jun 2013 23:20: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=0PDTDRHEdU4BvDl2/sHWaPfHyUwyH8gVAgghqN2+KGk=; b=InCbPM2xlasRj+ANozsRtvkqAfuaRFvvjAjnG1WRAoKrhA5g8CN6xyAYcI3n3T9HdP x1Rw2oRWeRKwe/GzJohYM7rkJubjPJ2XB2mXcyIVUvs9djkq7QUk+wx17Cb60L1yc5Hc 8LoqPbI9GFmO/DYHic2NloVxbc8orAviGTfC6C3lkpGsyCDDENYc9Tr77GWrBFLBI3K2 rphn1Uaq71dK8BGMre5edTci8U9PVF8IBdKgrNskA3STnar1E5VOhJPRMhKMnw0TZtN8 cUG64mbHyU2EIvxUNbtEKt7oDKIKdMpEiYvAyC1z2OjmOT8kmhthk7LiJuaFb8crVVh+ UQxg== 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=0PDTDRHEdU4BvDl2/sHWaPfHyUwyH8gVAgghqN2+KGk=; b=grz28x5emg/BCAnquYG6WgnHBbJfKcBYppHgChIHFauxDESLnFunGkAKfqrNIoyPqk DAR+6+ZAWkeepekWL8lEb8C8UmstThrBxTrtWjNbHpK7O7X0L1vBot6yhtfT0MZ7AjqQ 2HMmaaFWI4EeDjeUylkjj1uUA+aG6WLUI/YSkKLNXWxT+bv46yrVPPHPoARaa2fhHbax Uq35LWii+ZzbR6efC8dxx95waAkXRIgM179uA6rSvvUuK+w8ZD2PNqSA20Klmt0Raih0 v8VChUM4ofCyUsJ3Dpa6j24WajWFvK/XQNLLc3oDF5cTg8mB+53LzXUBAHFAwUYfppQK Jm+w== X-Received: by 10.224.182.136 with SMTP id cc8mr32925217qab.10.1370499629606; Wed, 05 Jun 2013 23:20:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Wed, 5 Jun 2013 23:20:09 -0700 (PDT) In-Reply-To: <1370451106.2292.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <1370451106.2292.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 15:20:09 +0900 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=20cf30363d3f968f7804de764ff6 X-Gm-Message-State: ALoCoQmWvndPalfoH39M9NyD6EBaykdriQVaUaTIbNzAJVq8b/nKg4bfSjbtZb5MzgH1rxi57Y3SjfS0pBlIDfN0cGHTrMav422x6IwpwBThrLxj+u0yNE+BIen9SErWzz/rXh9JQMCb2AT+ivs7ajMUqJ+/6LnLqzEtZPvRVl66YKqybLF+fyPG06XqHorl6n3KOe9hFJS0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 06:20:31 -0000 --20cf30363d3f968f7804de764ff6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 1:51 AM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > If on our controlled, secure private networks, we have attackers who are > able to modify packets. We have much bigger problems than packets with > IPv6 extension being dropped. > Wait - a while ago I thought you said that you were targeting this option for use on the general Internet and on general operating systems. Now you're saying that it only needs to be work on private networks. Which of the two is it? --20cf30363d3f968f7804de764ff6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 1:51 AM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
    If on our controlled, secure private n= etworks, we have attackers who are able to modify packets. =A0We have much = bigger problems than packets with IPv6 extension being dropped.
    =A0
    Wait - a while ago I thought you said= that you were targeting this option for use on the general Internet and on= general operating systems. Now you're saying that it only needs to be = work on private networks.

    Which of the two is it?
    --20cf30363d3f968f7804de764ff6-- From niall.oreilly@ucd.ie Thu Jun 6 02:10:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8421F96E8 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 xiLGjQSHMqPz for ; Thu, 6 Jun 2013 02:10:55 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC6521F96FC for ; Thu, 6 Jun 2013 02:10:51 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so127136wiv.17 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=ep1027dEllbVPuI99Fw+oUpcZwuxym24MGvVnM7+Lbqd1nVypRZkPlvsUB5+k0mx7O fxmOiFPfngkX4x6HByUeL3cFpyL7ysiTQI9COcsWIzGMmxxeX49x3KUywy7v1OXE+IfW K/1mD9ne24qGkYs7wcsS1vo1ftqclji+c0iCY4/kvAQjAIbHtbgwiX7Q3qsnyMZhUCk9 8hOuukKLuy6JTv2cgEqYEHP9dPZZ0BVo9T4u6y25CeJiewPkZHYr1D0LAMPyw19VaIXR xabZEjQWF3sZqwow8Mu/1aQbev4B41Y4Sj1LReHIpC/HPjyhKo7LSZ8xmqKtRsiBlBe/ m9Lw== 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) 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: ALoCoQk0ZdEOLVgTQs1nYKiFgjBrHsLuzO4yqbfKvNdeyUQ/kf/qkNRjD8/7Gle2+vV/p/xgkCDj Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 otroan@employees.org Thu Jun 6 02:22:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65F121F9815 for ; Thu, 6 Jun 2013 02: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 X1C99k1GaP8O for ; Thu, 6 Jun 2013 02:22:51 -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 4634521F9711 for ; Thu, 6 Jun 2013 02:22:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAN9TsFGQ/khN/2dsb2JhbABZgwm/c3YWdIIjAQEEAXkQC0ZXBogaBrtZjngzB4J6YQOdXYsigxE6 X-IronPort-AV: E=Sophos;i="4.87,814,1363132800"; d="scan'208";a="83154934" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Jun 2013 09:22:31 +0000 Received: from [10.147.112.161] (dhcp-lys01-vla250-10-147-112-161.cisco.com [10.147.112.161]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r569MRs4024941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 09:22:28 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: Date: Thu, 6 Jun 2013 11:22:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 09:22:58 -0000 > > As long as they don't claim to support IPv6 (as standardised byRFC = 2460) > > there's no problem with that. However, I don't think the IETF should = be > > making excuses for them. >=20 > So, if the device support looking 128 bytes into the packet is it RFC = 2460 "compliant"? 256 bytes? 512bytes? >=20 > If you believe Nalini's argument above, to comply with RFC 2460, the = router must be able to look 65575 bytes into the packet. RFC 2460 places = no limits on the size of the extension header chain, the 16-bit payload = length field counts up 65535, and you have to add 40 bytes for the IPv6 = header. a router as defined by RFC2460 does _not_ examine or process any = extension headers (with one exception). a router is RFC2460 compliant if it can parse the 40 byte IPv6 header. I'm not sure I see the need for the IETF to get involved in anything = 'deeper' than that. cheers, Ole= From lorenzo@google.com Thu Jun 6 02:40:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D2E21F96FF for ; Thu, 6 Jun 2013 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, 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 5rtD7lQZslOb for ; Thu, 6 Jun 2013 02:40:44 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2996921F96F4 for ; Thu, 6 Jun 2013 02:40:43 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so1753734qeb.3 for ; Thu, 06 Jun 2013 02:40: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=a+j6yxLgD5HYsa6da97hy7hZadkF8iN/aL99ddRY8/s=; b=STdUNUynyrRXyLJ22fMX6pQ36qPvoPk2sowwcgtrXxSnuNDqL9+S6Ml87uOLJv2dGo crTg/mfRa0kZFlZEyCeBH4Wdl040lnaf7CBU2TxJxKOHckdLhWKQBMjp/vIZHxvaGaXW 5WrwmiUAEMIgOvg4UdOz/os0f9acbWsS07zVL/IXRK80rSIBVbIN44OcVKpwXR9NXz3x qMjH5Tye37oc0PKSL9UbxQhGXtvafgzMrKC6f+LJGCkGCZzsWylF1CZM17+Xw7QPE0ko yQcvccIMbgxk03LxEckVg/BX7RvH9kyIRnWf8I1lkJetsVeIIZ0fmCqiXBrauqFKWLtz J0jA== 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=a+j6yxLgD5HYsa6da97hy7hZadkF8iN/aL99ddRY8/s=; b=JO050pAfTCWmj4bBxY5rPj+rs9Y6Bp10fJscyrq2tbb2xLaBtb79aw8R/OJEpf/ycL /QF/il7wjHbgJyBuL7eWE/a2vljUCAlx0b1ZrRkB9rUvd1Nc8RmOh+9Dpg9rGeEKaVQk rBchlmgb/ruRC9tBYyE4kYeImrkF0XYKwPJdOlDU3B2tbr6qrVqhO7oAx2kdp1cgBBG7 o/+YnnyQNfahmS8bi4ghxI0D5orp0RNTjT4sg9CNn6C/mZxwW9JZliHoM5ulFlft0kLK 64kuhNx4mS4tluvzAaXDZ1ykrAKBQdKDy2Wj7sfVzkMe6h3o6z25uSdBnCrlCIeKEBmz lvLg== X-Received: by 10.49.74.3 with SMTP id p3mr38878508qev.32.1370511643446; Thu, 06 Jun 2013 02:40:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 02:40:22 -0700 (PDT) In-Reply-To: <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 18:40:22 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=047d7b5d5b94ab2f8304de791bae X-Gm-Message-State: ALoCoQktOEAR6Y/x1+/khp7KzQswyqtxjKsQdMIBqTBLBaEx2NehK6nQsF8P42arL9xUmDg93OjPrYfmVGv2pQE30x0cc97/hy1GfXD4yIR1Keuo0ttPb9p9gLzBNM/DlpFzzjtW4jENN8tbdmwjD9kK+xeQqUqwHFpP65TnABa5zHHGfJygW/VXYmKWD1f9kj+hgLvR937O Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 09:40:49 -0000 --047d7b5d5b94ab2f8304de791bae Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 6:22 PM, Ole Troan wrote: > a router as defined by RFC2460 does _not_ examine or process any extension > headers (with one exception). > > a router is RFC2460 compliant if it can parse the 40 byte IPv6 header. > True. > I'm not sure I see the need for the IETF to get involved in anything > 'deeper' than that. > That's a fair position, but it's also not very useful if we standardize something that cannot be deployed in today's Internet. --047d7b5d5b94ab2f8304de791bae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 6:22 PM, Ole Troan <otroan@empl= oyees.org> wrote:
    a router as defined by RFC2460 does _not_ examine or process any = extension headers (with one exception).

    a router is RFC2460 compliant if it can parse the 40 byte IPv6 header.
    <= /blockquote>

    True.
    =A0
    I'm not sure I see the need for the IETF to get involved in anything &#= 39;deeper' than that.

    That= 9;s a fair position, but it's also not very useful if we standardize so= mething that cannot be deployed in today's Internet.
    --047d7b5d5b94ab2f8304de791bae-- From otroan@employees.org Thu Jun 6 02:52:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CEC21F936E for ; Thu, 6 Jun 2013 02:52:55 -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 qUMST-i3jGbC for ; Thu, 6 Jun 2013 02:52:54 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id BA27121F8F3E for ; Thu, 6 Jun 2013 02:52:54 -0700 (PDT) Received: from [10.147.112.161] (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 00B3B5E85; Thu, 6 Jun 2013 02:52:47 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: Date: Thu, 6 Jun 2013 11:52:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 09:52:55 -0000 Lorenzo, > a router as defined by RFC2460 does _not_ examine or process any = extension headers (with one exception). >=20 > a router is RFC2460 compliant if it can parse the 40 byte IPv6 header. >=20 > True. > =20 > I'm not sure I see the need for the IETF to get involved in anything = 'deeper' than that. >=20 > That's a fair position, but it's also not very useful if we = standardize something that cannot be deployed in today's Internet. true, but designing for the other extreme, for an Internet where there = are middleboxes that inspect and wants to understand every bit in a = packet is impossible. my point was that we (as in the IETF) shouldn't require any router to = have to be able to parse deeper than 40 bytes. if you need a router that can parse and twiddle every bit in a packet, = go talk to your vendor (and I'll be happy to sell you one). I'm fully with you with regards to taking the realities of the Internet = into consideration when designing new protocols and extensions though. hopefully we will be able to take a comprehensive look at that for this = problem in 6man. cheers, Ole= From lorenzo@google.com Thu Jun 6 03:05:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A1B21F990D for ; Thu, 6 Jun 2013 03:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.776 X-Spam-Level: X-Spam-Status: No, score=-3.776 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, 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 cAeNc3iLtD-6 for ; Thu, 6 Jun 2013 03:05:06 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFDE21F9704 for ; Thu, 6 Jun 2013 03:05:05 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so1719175qea.21 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=V+aG4XQcVZKsxUtvThGqON/IBphDZf3zJfe4IEbdhtJ6Cgu7j5HCoHkYKcQC7Umgav qU/EMCqzEMZsRxZvuck0W/h57QTnYO4X7Il4EEcI0Qlsz1yIUBUdqZwZdnjwpavK5+Xq LkyAf4YoIbFkUhN4u0mqTfz5uxixgu51rzm13A9uD9vK8tr+rfTo5qLre9DKUZYs4A+D VcbvCz8J9I/wDxR6AOEQZ04IqWyVT2LTWsggrKnb1jp5/sfQe2Wu4F1jBTO54DY2/abN JA6YfufgKCOTuX0NDzqZTGWnRP/llVDjDnamBtUh56IC3v1jrctSW62i1XLKvoBvC26S sQMw== 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: To: "Niall O'Reilly" Content-Type: multipart/alternative; boundary=20cf3074d9a4cf164204de79723e X-Gm-Message-State: ALoCoQkt0YGN8d2quc7lxTbkjN9bZtG6WgkQZRBLtKQFODXAjQkFdixjvULXKPc2v01eRZiIOeAw8pH/73TLwI0jk42ShBil6U5ds8abzsvoXmZfwOamJrmNwW81bl7cLXk5QGkbB12ZJiusQNKeUf/oXpfFWTSsnlj8Oa8bGgHAYSkYcpCDKB0m3vFYIIjWLZoAhUPIMeWj Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:05:11 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: Sheng Jiang To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae94739f3f42bfd04de79edec Cc: "Manfredi, Albert E" , "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 nick@inex.ie Thu Jun 6 03:59:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B28F21F9925 for ; Thu, 6 Jun 2013 03:59: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 GX8vIuz5Q-tI for ; Thu, 6 Jun 2013 03:59:52 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id D8DBA21F96E9 for ; Thu, 6 Jun 2013 03:59:51 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from pancake.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r56Axfbn041930 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 11:59:42 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <51B06B9D.7060300@inex.ie> Date: Thu, 06 Jun 2013 11:59:41 +0100 From: Nick Hilliard 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: Ole Troan References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> In-Reply-To: X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:59:52 -0000 On 06/06/2013 10:52, Ole Troan wrote: > true, but designing for the other extreme, for an Internet where there > are middleboxes that inspect and wants to understand every bit in a > packet is impossible. we're not talking about that level of extremity - we're talking about basic functionality of a router. In my books this would require e.g. the ability to handle packet filtering based on packet header characteristics using L3 port ACLs. There's nothing interesting about a box which can only forward packets and nothing else. re: > my point was that we (as in the IETF) shouldn't require any router to > have to be able to parse deeper than 40 bytes. > I'm fully with you with regards to taking the realities of the Internet > into consideration when designing new protocols and extensions though. this is giving me an uncomfortable level of cognitive dissonance. Nick From sm@resistor.net Thu Jun 6 04:05:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFA521F9959 for ; Thu, 6 Jun 2013 04:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 SJU06auslZOz for ; Thu, 6 Jun 2013 04:05:23 -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 B66A721F93E1 for ; Thu, 6 Jun 2013 04:05:23 -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 r56B5E7A021827; Thu, 6 Jun 2013 04:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1370516718; bh=RjJVsFafE7/T9cQhclIIxdWB1aZixfmWhFNG4x0teMo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0x1zwIWoI+iUR3HRFbC0qX2xeLhtpPuaGZF5QoJG2f45kfcLYepMoivv1bbtTUP/e pJc+YXmQxevnc4m7NM0tlqOq1v+9tOZhIkIS6VsxAQ82gPFpfwydvnAGi15FAV2SyB xhTCjNpyM0U4lrH7d+t63UrkGet0JW0qbCWzc7MM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1370516718; i=@resistor.net; bh=RjJVsFafE7/T9cQhclIIxdWB1aZixfmWhFNG4x0teMo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=loLSGH1ThQCAU/qWMRal+9cN2Qtmsb9U2vT7XGNzhrok3U8W78TuJc6bUtry38s+x Af3SREWfpiEsT4yu9JFz2drKNbRa1ev9Vb0PpD761LMzIusId347K5GbeFZG0vVGv7 2gMlm33a2ZBF1tKL47EybQW3DPrI+rolOKBAuSVo= Message-Id: <6.2.5.6.2.20130606034128.0d9e0bb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Jun 2013 04:03:48 -0700 To: Lorenzo Colitti From: SM In-Reply-To: References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:05:24 -0000 Hi Lorenzo, At 20:30 05-06-2013, 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. The draft could be considered as a technical recommendation, assuming it is published. The RIR policies should not be a constraint as an organization is supposed to be able to get the IPv6 address space it requests for its operations (I would like to avoid the usual controversial terms). George Michaelson commented about RIR policies a few days ago. I read that comment as "if the RIR policy is broken, fix it". I do understand that there is a lot of bureaucracy to work with. However, if the RIR policy or policies are considered as a constraint to available alternatives in this discussion, it is like discussing about the chicken and the egg. As long as the ISP does not say that it is assigning the home users a /32 it should not be a problem. We can always argue whether it is appropriate or not to assign a home user a /32. It's unlikely that there would be agreement about that. Regards, -sm From sthaug@nethelp.no Thu Jun 6 04:22:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0D21F8D16 for ; Thu, 6 Jun 2013 04:22:25 -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 7JjKkRY3jHWO for ; Thu, 6 Jun 2013 04:22:20 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id D0BA621F9079 for ; Thu, 6 Jun 2013 04:22:09 -0700 (PDT) Received: (qmail 3600 invoked from network); 6 Jun 2013 11:22:07 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Jun 2013 11:22:07 -0000 Date: Thu, 06 Jun 2013 13:22:07 +0200 (CEST) Message-Id: <20130606.132207.74666611.sthaug@nethelp.no> To: otroan@employees.org From: sthaug@nethelp.no In-Reply-To: References: <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:22:25 -0000 > > a router as defined by RFC2460 does _not_ examine or process any extension headers (with one exception). > > > > a router is RFC2460 compliant if it can parse the 40 byte IPv6 header. > > > > True. > > > > I'm not sure I see the need for the IETF to get involved in anything 'deeper' than that. > > > > That's a fair position, but it's also not very useful if we standardize something that cannot be deployed in today's Internet. > > true, but designing for the other extreme, for an Internet where there are middleboxes that inspect and wants to understand every bit in a packet is impossible. There will be middleboxes that need to look at enough of the IPv6 headers to find for instance port numbers. At my AS borders, I typically do some filtering which depends on more of the protocol header than just the IPv4/IPv6 address. Examples could be: - Allow carefully policed UDP traffic in the classical Unix traceroute range to reach my routers. - Deny DNS queries to my recursive name servers while allowing the same servers to be pinged. If you simply ignore such boxes, or label them "firewalls which we don't want to deal with", you are excluding a significant group of boxes which in reality are high speed routers that happen to have stateless firewall abilities. Steinar Haug, AS 2116 From Ted.Lemon@nominum.com Thu Jun 6 04:25:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE3421F9962 for ; Thu, 6 Jun 2013 04:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 HI7XzJD89MLX for ; Thu, 6 Jun 2013 04:27:31 -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 A253221F96F4 for ; Thu, 6 Jun 2013 04:27:31 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id z1so338836qcx.30 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=gIYASUgijGk/hOBD06cpZd6Kdiz4efsEFfdMFC0IWn95CJbduAQ56mptdHNdHZgFTB FPyit8gAneASe1hBAJ21yxfZZQGwhjfFG5tPaGJ71pvAGKFVuPRQb/V7MbWIlzjqNBIY qlCnWrm/FokeMpHJ11v1ptONBDEcFvDIGYJJ+9c96Zw+s2uioTlKVEqiBrFsrUKh5hki M4aE5M4B6Xx7NZTZyGPhYsU2a+ofRo86sonRixtL7s/hPbKUMoFTkr3tIUMoiT04MT9X w4+kbUwuCkSFfbzVarzG39kXN7gV0hOC1c9+PSbYhhedS3nl7h5fI4IX0FoeWHOSkkBm YXcg== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf30363d3f97a84d04de7a99f8 X-Gm-Message-State: ALoCoQn8WI8LcNiTnJ9voVr8nObZWrqzzWpNXqnXBUZ4k0BJ9nimONvGwIawoo1H4spQ+TIfh6T+R8fcP/9pclNDTpVBqSN3oj+PG+fHg8E7ZutaBgVFAe1k5LtEzIVnGcSVMUANujz9P89j3o1hC6HUo9cTyQGroU8TSsTzUTNv0M0LRO80IPYPyOfzPFJ880T5BZNNyYiz Cc: "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 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:27:32 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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:41:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3611F21F99FF for ; Thu, 6 Jun 2013 04:41: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 MULkVvSk3teY for ; Thu, 6 Jun 2013 04:41:24 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id AE83521F99FE for ; Thu, 6 Jun 2013 04:41:24 -0700 (PDT) Received: from [10.147.112.161] (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 BDA245F5E; Thu, 6 Jun 2013 04:41:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: <20130606.132207.74666611.sthaug@nethelp.no> Date: Thu, 6 Jun 2013 13:41:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59A47457-9A04-48E2-B7BD-8CFC14A38E0E@employees.org> References: <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <20130606.132207.74666611.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1503) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:41:25 -0000 Steinar, >>> a router as defined by RFC2460 does _not_ examine or process any = extension headers (with one exception). >>>=20 >>> a router is RFC2460 compliant if it can parse the 40 byte IPv6 = header. >>>=20 >>> True. >>>=20 >>> I'm not sure I see the need for the IETF to get involved in anything = 'deeper' than that. >>>=20 >>> That's a fair position, but it's also not very useful if we = standardize something that cannot be deployed in today's Internet. >>=20 >> true, but designing for the other extreme, for an Internet where = there are middleboxes that inspect and wants to understand every bit in = a packet is impossible. >=20 > There will be middleboxes that need to look at enough of the IPv6 > headers to find for instance port numbers. >=20 > At my AS borders, I typically do some filtering which depends on more > of the protocol header than just the IPv4/IPv6 address. Examples could > be: >=20 > - Allow carefully policed UDP traffic in the classical Unix traceroute > range to reach my routers. > - Deny DNS queries to my recursive name servers while allowing the = same > servers to be pinged. just to be clear I have no issue with this, were the hosts that you = control basically outsource filters they would have applied anyway out to the = network. > If you simply ignore such boxes, or label them "firewalls which we = don't > want to deal with", you are excluding a significant group of boxes = which > in reality are high speed routers that happen to have stateless = firewall > abilities. what do you think should be the consequence for the work we do in the = IETF? I think the IETF should be on the side of the end to end Internet and = follow the principles outlined in RFC1958. clearly there are some better design choices than others. e.g. RFC4821 = vs RFC1981, but I don't think the IETF should just give up the ida of the end to end = Internet and stop designing a new L4 header ever again. that said, I'm not in favour of making middleboxes' life harder just for = the sake of it. from that perspective extension headers are a bad idea, and I wouldn't be opposed to removing = them altogether. cheers, Ole From otroan@employees.org Thu Jun 6 04:48:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD84821F9A25 for ; Thu, 6 Jun 2013 04:49:20 -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 peTT5v5MUOq2 for ; Thu, 6 Jun 2013 04:49:20 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7BC21F9A1A for ; Thu, 6 Jun 2013 04:49:18 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id ih17so222362qab.19 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=f+0znbd2R2WRjHUs3K8rjrOOljdWYiPG6pl052diI4IsAjiyT5EcWRAD4w1x459072 j5XLfYBIOuZJHnqB3fuYhVVf/zdEn6PbrrFAc9B23I+/T12+NlPvpgDLwRLaFX8iR3rW t9WfJaK59oxicuFjPVkWQyvp+4QnEUxv4mLeTCPtx4l6mHr/oDZdVxgWvgFvdhEGL4l5 jLyaUFj05vBZkM2xLQfyFuW3ES9bAXgVXnT3I6bv6a/eK358/aEtCDEdGsRZQCMSb3kb pmD+PMLyP1Sfn82pk6NjilNZM+oDin6CA++pBVWCo9rTNCeVW9vNE4/USbpdacIhU22E iwQQ== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3074d9a479580104de7ae7e1 X-Gm-Message-State: ALoCoQlqcZm02ix6P2XzL9z9FeyrZaOvLLF+ZgVMtV29xqxidjY5JcMSveGsKOHizOH3F0ea+KvuPNwA2jMzw7qFSDK0cijv10pDcHIQ9Ol7wExcFklNvUU7BD+6YeKAG4RhDsYIMKbEHMPT5P3eSRnkM8ZdYj9SjD+/V8fh2c5ZgrXYw3HhQ3fGERPqcGv2Ny2/raGlkDdH Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4B21F9A2C for ; Thu, 6 Jun 2013 06:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 Yk6O0Tm8driC for ; Thu, 6 Jun 2013 06:35:52 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9DECA21F99F2 for ; Thu, 6 Jun 2013 06:35:52 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so1860178qej.25 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=QKRmEbi/7Oe5l2D4twR6tRFeMkZeXHoDnuH5fz0qzH0tjPMJ5Mf0JfLp7VBh7lPM9E Ix6zSRE9puZKoc4BDa5pIuRGYhfDpbaR2YC0yIVLeMxkRTqTuKUcJtrxjtNS7kzHEEv4 yA4oXDUZ+A/Gqf04wl7yZ7rfGcgo0Ez4vFpBSwrnNKDZhmUjAfxyd+zYnWY8fu65R/0M DtAgjW8kAdyavy6gLYlCsPhDHwv+WdnXmrFC73xRHKurSeo3JO/KLXyX1rH0WPIhfD3Z 3w0dv8cS2WFcm2XDNu+a3kpnpjozxXUsetn9iAMwyMmoONDm2itR/vnfvMmrVLzSmr35 qh1A== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2c6ce8378b404de7c64c5 X-Gm-Message-State: ALoCoQmcMj2MrLvdnKF1XHm5qpG1v2aUoSmku6UApknYcDh0oUHRSZQhPEE93SQF7Ko+HuKEapduE27h8w2Zlhw/baRHoXuX31gjMAryjGhDxmpbdyCXR2IpPFc+nDI/3A45WFCOt8X1pgj5ZUdb75p+ahs/hkKUWwYidlbsCbF/vthDi3T56KY87IcD3MuY+ycanWuqWdbv Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:35:58 -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 rajiva@cisco.com Thu Jun 6 06:43:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFBC21F9399; Thu, 6 Jun 2013 06:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=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 M22Q7ulKIqQf; Thu, 6 Jun 2013 06:43:44 -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 E965221F9289; Thu, 6 Jun 2013 06:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4774; q=dns/txt; s=iport; t=1370526224; x=1371735824; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I7M+/qo0hkPXbpmaFC2Uok5tewCDHiLzIZO6NTYB0nE=; b=lu7U40ikxNGjiWJ3yuEWqTeBhtl8XOdftf2Ti+K55Y4qGbQejekcK8Av h29HQu4S203EHwnGyfjuKhW1oLw8z7l6nNnjDvHf9Ia7R3MTgFnBLXulz JyhR5QmES9smx8YJtuWUZrPrJI8qphdPp9DGfjXCtYwJF5WUwMjUd0bb1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALaRsFGtJV2a/2dsb2JhbABZFoJzML9HeBZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQgBiAQMuxuNcQ+BATEHBoJ0YQOjX4Uggw+BaQgXHw X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219549165" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2013 13:43:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56DhPwW019104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 13:43:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 08:43:25 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkAAFj40AACIhOTA= Date: Thu, 6 Jun 2013 13:43:24 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:43:49 -0000 Good point. I agree.=20 And hopefully, most of the connected home would be on IPv6 (and not on IPv4= ) in the next few yrs . :) Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 3:25 PM > To: Rajiv Asati (rajiva); Poscic, Kristian (Kristian); v6ops@ietf.org; So= ftwires- > wg list (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 > that's right. >=20 > Depending on how much stuff you have running there might be long term > TCP connections to mail servers, IM servers, Etc. >=20 > With the 'connected home' I'm assuming this will go up. >=20 >=20 > On 6/5/13 3:51 PM, "Rajiv Asati (rajiva)" wrote: >=20 > >Reinaldo, > > > >I agree with you. Until I enabled DNS proxy on my router, I noticed > >that UDP NAT exceeded TCP NAT entries in few occasions. Since DNS proxy > >got enabled, UDP NAT entries became negligible. > > > >One interesting observation is how the lowest number of TCP NAT entries > >stayed within the range throughout the night time (when the devices > >were not manually used) based on how many apps (on the smartphones) > >were left running. For ex, ~200 TCP ports on April 13-14, or ~30 TCP por= ts > June 4. > > > >Cheers, > >Rajiv > > > > > >> -----Original Message----- > >> From: Reinaldo Penno (repenno) > >> Sent: Wednesday, June 05, 2013 11:44 AM > >> To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); > >>v6ops@ietf.org; > >>Softwires- > >> wg list (softwires@ietf.org); behave@ietf.org > >> Cc: Erik Kline (ek@google.com) > >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > >> > >> Yes, there are regional differences. But even then, in general, 90% > >>of the active users can be covered by 1000 ports. I have been > >>collecting data for many years, and actually the number of TCP ports > >>consumed have been going Down due to a number of factors. > >> > >> On the other hand, as Rajiv captured,the number of UDP sessions can > >>be much larger than the number of TCP. Because the way dynamic > >>webpages are constructed today, there are sometimes literally 100s of > >>DNS requests to download a single page. > >> > >> > >> > >> On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" > >> wrote: > >> > >> >Thanks. Can you tell us in general what applications did you use for > >>this? > >> >This heavily depends on the application type in use...p2p apps, etc. > >> >Since some apps spawn a large number of TCP ports for example. > >> > > >> >So the question is to what degree do you think is your sample > >> >representative of a general user in any region? > >> > > >> >For example does it cover 30% of users for an ISP in NA while it > >> >covers 80% of users for another ISP in APAC for example? > >> > > >> >-----Original Message----- > >> >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> >Behalf Of Rajiv Asati (rajiva) > >> >Sent: Wednesday, June 05, 2013 6:14 AM > >> >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > >> >behave@ietf.org > >> >Cc: Erik Kline (ek@google.com) > >> >Subject: [BEHAVE] Home NAPT44 - How many ports? > >> > > >> >Some of you may recall our discussion (during the last IETF) around > >> >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs > >> move > >> >into > >> >A+P paradigm. ~500, ~1000, ~3000??? > >> > > >> >Well, I started monitoring my home router and plotting the NAPT44 > >> >port utilization on a minute-by-minute basis. You may find it here - > >> >http://www.employees.org/~rajiva > >> > > >> >In short, port range of 500 seems ok, though 1000 would be more than > >> >enough for my home. Suffice to say, this is just a sample > >> >representation, since the port utilization would vary home to home, > >> >based on number of active devices, type of applications, the degree > >> >of simultaneous device or application usage etc. > >> > > >> >If any of you are doing similar monitoring, then please share. > >> > > >> >Cheers, > >> >Rajiv > >> > > >> >PS: Thanks to Erik Kline, who explained (with sufficient details) > >> >how to use google charting for my data. And thanks to Xun Wang & > >> >Shaoshuai Dai for helping me out significantly. > >> > > >> >PS: My home has 3-4 active devices. > >> >_______________________________________________ > >> >Behave mailing list > >> >Behave@ietf.org > >> >https://www.ietf.org/mailman/listinfo/behave > >> >_______________________________________________ > >> >Behave mailing list > >> >Behave@ietf.org > >> >https://www.ietf.org/mailman/listinfo/behave > > From Ted.Lemon@nominum.com Thu Jun 6 06:57:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B91921F99F3 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.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 SY2+WldrSoTK for ; Thu, 6 Jun 2013 07:09:44 -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 6F8FA21F9050 for ; Thu, 6 Jun 2013 07:09:44 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so321356qaj.6 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=C033bg9SFLMLX3RbLT+BKyZqrR0iptRWy0tLzpR7LKuUfKsda3j7xulB67+VvGUuoS +7eFJfogUgk4eE0dQv7SDC2cLv7QG5eKIZRKAOmb4uF1jJr+uaDIHZz2RlNbgIrkkw/G 6RM+aMhkqYMcXn9W8PZtXwg7vbd5NPL7l6t6kFLN7HtU7AQxjgW1j1yEt/Q/OkxOxOiw yxSTGgRsd+bRR9W3kOEqDnkse6m5hn7Arpa3fScEModamjeTDXyJbSE64B2H8ZxpNAwV ku5fbFaFHpyTupk5sI6pZ+tV4JdQ8/teizYBrKM4QoDxc+e/8M0Uw8veI7YnouD7hhUi Z6QA== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b6da828b61cda04de7cddcf X-Gm-Message-State: ALoCoQm42xBNSt753JW/URImNJVvcfuPVr4Q2vRuLZ9ZqIk5oVjXsNHTPIOXI+JqW2Efr6nwcJNOcoiY/MdcMvUMhYtTyOdES6QnYb0tXis7ctHTR/oh9AElsQp3Xd2aZeOCGZPv6SzyVRiLrXUMLbc5Dn5B8MH+DOtO/ZUnsWnvJ6RV/dnBKlupZzFqvpp+V1nv4UqzajxH Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 bill.jouris@insidethestack.com Thu Jun 6 07:14:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1212121F8E2C for ; Thu, 6 Jun 2013 07:14: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 P9WLYyBMjWkI for ; Thu, 6 Jun 2013 07:14:14 -0700 (PDT) Received: from nm5.access.bullet.mail.sp2.yahoo.com (nm5.access.bullet.mail.sp2.yahoo.com [98.139.44.132]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9121F8E9D for ; Thu, 6 Jun 2013 07:14:13 -0700 (PDT) Received: from [98.139.44.101] by nm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jun 2013 14:14:13 -0000 Received: from [98.139.44.69] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jun 2013 14:14:13 -0000 Received: from [127.0.0.1] by omp1006.access.mail.sp2.yahoo.com with NNFMP; 06 Jun 2013 14:14:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 479163.25653.bm@omp1006.access.mail.sp2.yahoo.com Received: (qmail 12105 invoked by uid 60001); 6 Jun 2013 14:14:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370528053; bh=f6ks2/BBb8QjOHW4c/T/t/VKlEThGbmFdDC7ZrFVGqs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ehkYVXGazCdzh/gHblRq/wwIRGxxaCHoO5DkJj+EJbAly9H+t4K73qOKKGpyPsk4SB64j9U3XIZS7GMKQGAjIRXGP9LWum7A5xgg3MBUix2kDVCY+r0htvstEfcT1FjzupTY3dDGme20QnrYHN/S/cds+UQaOdJxHbTnE2TriL8= X-YMail-OSG: bAIErEsVM1k6nXiS9sR0LTqOs_FrhA0FLTUYUyCNUQyk4x8 mSmycJwzDUK56JXMJBPD.8eAbyjW9Y.31ZpsOKbXmreG2xbDca7pJ1n2N5hz 11zIPStLM4C33iVWFscc5o8I9xF2YxPp9g4jVDQnaBXLmmkqzpDDDk_bkzFr SAWs.VDhJpTVDBjMgkZQPLENIoqTRoSbfGUkO24ZbUIJmZt0b1fVvKrdL.u6 qtXrEDdoUTjEbFnhad_oQVR_DE9NMwLJLdOISm69a4nMjZuaMMwVFTfIAklG ePWWeXBfcbvceiQVZrp0KeIPObzum1KfpE4QMxn93AbTAGfPJ5fEsCNej2an U8AtPfxfgBijabbVph4ly5P0vGud7MoYzLqHH.ubwIup5OtgfE67.XxQceE1 rtpF6EbGR9Tuj.CmZq0ZD__7sTZxWk2X8uuNkMC3uo3pHQ0cIjVWEsVTf9SZ a3xAPnQc1YOyf_g9FjkzQqv5u_vGgV16sBazML6.ObxJJq9kvTz3jOILaUwC qsTqz6uUCwCY1yFxDKi3lxl4vn8OZGCDvne8o0HIS_5ehfoiRLZMiP3ziwhk vmQolwMVfJqp2DsMdYjoDuKBLjRQIhXk.x9oxbZnkavsUyK_X4iEJLji16ig 4TvoPv3URnliXYUZxclDTxRY- Received: from [50.143.174.186] by web2803.biz.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 07:14:13 PDT X-Rocket-MIMEInfo: 002.001, PiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4.wqAgDQoKCj4gSSdtIG5vdCBzdXJlIEkgc2VlIHRoZSBuZWVkIGZvciB0aGUgSUVURiB0byBnZXQgaW52b2x2ZWQgaW4gYW55dGhpbmcgJ2RlZXBlcicgdGhhbiB0aGF0Lg0KPiANCj4gVGhhdCdzIGEgZmFpciBwb3NpdGlvbiwgYnV0IGl0J3MgYWxzbyBub3QgdmVyeSB1c2VmdWwgaWYgd2Ugc3RhbmRhcmRpemUgc29tZXRoaW5nIHRoYXQgY2Fubm90IA0KPiBiZSBkZXBsb3llZCBpbiB0b2RheSdzIEludGVybmV0LgoKCg0KQnV0IGQBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.144.546 Message-ID: <1370528053.11966.YahooMailClassic@web2803.biz.mail.ne1.yahoo.com> Date: Thu, 6 Jun 2013 07:14:13 -0700 (PDT) From: Bill Jouris To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1317970954-1370528053=:11966" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:14:20 -0000 ---1551098171-1317970954-1370528053=:11966 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > From: Lorenzo Colitti >=A0=20 =0A=0A> I'm not sure I see the need for the IETF to get involved in anythin= g 'deeper' than that. >=20 > That's a fair position, but it's also not very useful if we standardize s= omething that cannot=20 > be deployed in today's Internet.=0A=0A=0A But doesn't that amount to saying that *every* RFC must be backwards compat= able?=A0 Forever?=A0 (When IPv6 was first specified, were there ANY parts o= f the then-current Internet which could deal with its headers?)=20 I'm not saying we should just ignore current limitations.=A0 But it doesn't= seem reasonable to make them a complete bar to change either. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) ---1551098171-1317970954-1370528053=:11966 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    > From: Lorenzo Colitti <lorenzo@google= .com>
    > 
    =0A=0A> I'm not sure I see the need= for the IETF to get involved in anything 'deeper' than that.
    >
    > That's a fair position, but it'= s also not very useful if we standardize something that cannot
    > be = deployed in today's Internet.
    =0A=0A
    =0A

    But= doesn't that amount to saying that *every* RFC must be backwards compatabl= e?  Forever?  (When IPv6 was first specified, were there ANY part= s of the then-current Internet which could deal with its headers?)

    = I'm not saying we should just ignore current limitations.  But it does= n't seem reasonable to make them a complete bar to change either.

    Bill Jouris
    Inside Products, Inc.=
    www.insidethestack.com
    831-659-8360
    925-855-9512 (direct)    <= br>
    ---1551098171-1317970954-1370528053=:11966-- From nalini.elkins@insidethestack.com Thu Jun 6 07:27:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD8021F85B4 for ; Thu, 6 Jun 2013 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.303, 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 57V5epX+sToJ for ; Thu, 6 Jun 2013 07:26:55 -0700 (PDT) Received: from nm27-vm0.access.bullet.mail.sp2.yahoo.com (nm27-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.188]) by ietfa.amsl.com (Postfix) with ESMTP id 037A921F9A1B for ; Thu, 6 Jun 2013 07:26:21 -0700 (PDT) Received: from [98.139.44.102] by nm27.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jun 2013 14:26:20 -0000 Received: from [98.139.44.84] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jun 2013 14:26:20 -0000 Received: from [127.0.0.1] by omp1021.access.mail.sp2.yahoo.com with NNFMP; 06 Jun 2013 14:26:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 865053.56436.bm@omp1021.access.mail.sp2.yahoo.com Received: (qmail 15026 invoked by uid 60001); 6 Jun 2013 14:26:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370528780; bh=leQLaXfZgRWz48j+hFMFqMyiBOLS4STJwHZk2C+2Gkk=; 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=BdJjpE9WGMia23u0xsH0n9xspzhNb5R8oTFY33+7K3E6MaUTnlb1PDYguRxz0PyAks8DfJ9C7aL88xzejpKxeIjnLtpB72SaPpMhAj25wg6xR81HSaEcBHciutvI1EOAD4Um5mzNLzmadzu8CPcRmP8prHX78EFqub7PauK0+Bo= X-YMail-OSG: 1Ys.ljwVM1myHEWK4JJWUx1Vp2GOJqc2KhmHQJ9kWZvgRs6 BfL7C0AyRd07R4qLa1X56yLZX_cS2y8QwLbSqCjLPpwRxRg.emLbLGIVSrrt HHCGg1hfd0kAeGKYshEUjE6Lw9urCMjUz04o73QN1Mt_cU_EXjKIZaKfF9cF iS8t.auF0PU295ux4YDwaR0n3QyLYhTPFNCGSsStFiwVvzY.pgZ3P_KAi5_Y Sm6OH3y3htixpcg3brpQ3OHmaVsYnG1p83NE_AvYRQY7ZI8ntgfEbWQnK47H _DAyDbbybEVtlBttFlInkdq6WFWKquAyWYSFKCV5KfacFRkQ2OJY9yCkw.cI rWKmDwxByvzhyttBsKsxWgBDL.RNApRp9mfJhjtPR9kdOELdc_uhNczs9fto PxBKG9EmeKTp8kMWaQyLbpQ2Wfum2dCxuerKUzqANl9mN5xPrmV8voSFMGLn EfID5MQlPUPzzUM.NnBUv0Z6sQaYWC7npW.bpHcIN4wS1DyZvKkp9zQGGASE bwCgRnLclKAxX_XV9y0dCBTXjpwgxbAOZ9LJkRMgdHxdY7u707IQsOkkfcW. 0a7LxCb.HVPrq821CoEQ_1hqWUfqMKIfMVkx5oa1XyVc0W2J5XNK56yffSzv m0r8UBv_PoAPyRpRzpALMTjpaS8x7dg-- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 07:26:19 PDT X-Rocket-MIMEInfo: 002.001, Pj5JZiB5b3UgYmVsaWV2ZSBOYWxpbmkncyBhcmd1bWVudCBhYm92ZSwgdG8gY29tcGx5IHdpdGggUkZDIDI0NjAsIHRoZSByb3V0ZXIgbXVzdCBiZSBhYmxlIHRvIGxvb2sgNjU1NzUgYnl0ZXMgaW50byB0aGUgcGFja2V0LiBSRkMgMjQ2MCBwbGFjZXMgbm8gbGltaXRzIG9uIHRoZSBzaXplIG9mIHRoZSBleHRlbnNpb24gaGVhZGVyIGNoYWluLCB0aGUgMTYtYml0IHBheWxvYWQgbGVuZ3RoIGZpZWxkID4.Y291bnRzIHVwIDY1NTM1LCBhbmQgeW91IGhhdmUgdG8gYWRkIDQwIGJ5dGVzIGZvciB0aGUgSVB2NiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370317111.77475.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370354397.17515.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> Message-ID: <1370528779.11870.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Thu, 6 Jun 2013 07:26:19 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti , Warren Kumari In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-485119372-1370528779=:11870" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:27:00 -0000 --1619178251-485119372-1370528779=:11870 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>If you believe Nalini's argument above, to comply with RFC 2460, the rout= er must be able to look 65575 bytes into the packet. RFC 2460 places no lim= its on the size of the extension header chain, the 16-bit payload length fi= eld >>counts up 65535, and you have to add 40 bytes for the IPv6 header.=0A= =0A>>If you don't think that is realistic, then I agree with you.=0A=0AGuys= , I am not saying 65,535 bytes. =A0But, I do think 256 bytes is reasonable.= =A0Also, I do also think that a standard needs to be set and the IETF is t= he right body to set it.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Pro= ducts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A__________= ______________________=0A From: Lorenzo Colitti =0ATo: = Warren Kumari =0ACc: "v6ops@ietf.org" = =0ASent: Wednesday, June 5, 2013 11:16 PM=0ASubject: Re: [v6ops] new draft:= draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn Thu, Jun 6, 20= 13 at 5:48 AM, Warren Kumari wrote:=0A=0A> As long as t= hey don't claim to support IPv6 (as standardised byRFC 2460)=0A>=0A>> there= 's no problem with that. However, I don't think the IETF should be=0A>> mak= ing excuses for them.=0A>=0A>So, if the device support looking 128 bytes in= to the packet is it RFC 2460 "compliant"? 256 bytes? 512bytes?=0A>=0A=0AIf = you believe Nalini's argument above, to comply with RFC 2460, the router mu= st be able to look 65575 bytes into the packet. RFC 2460 places no limits o= n the size of the extension header chain, the 16-bit payload length field c= ounts up 65535, and you have to add 40 bytes for the IPv6 header.=0A=0AIf y= ou don't think that is realistic, then I agree with you.=0A________________= _______________________________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/v6ops --1619178251-485119372-1370528779=:11870 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    >>If you believe Nalini's ar= gument above, to comply with RFC 2460, the router must be able to look 6557= 5 bytes into the packet. RFC 2460 places no limits on the size of the exten= sion header chain, the 16-bit payload length field >>counts up 65535,= and you have to add 40 bytes for the IPv6 header.

    >>If you don't think that is realistic, then I a= gree with you.

    =
    Guys, I am not saying 65,535 bytes.  But, = I do think 256 bytes is reasonable.  Also, I do also think that a stan= dard needs to be set and the IETF is the right body to set it.
    =
     
    Thanks,

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

    =
    From: Lorenzo C= olitti <lorenzo@google.com>
    To: Warren Kumari <warren@kumari.net>
    Cc: "v6ops@ietf.org" <v6ops@ietf.org&= gt;
    Sent: Wednesday, = June 5, 2013 11:16 PM
    Subject: Re:= [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

    =0A
    On Thu, Jun 6, 2013 at 5:48 AM, Warren Kumari <warren@kumari.net> = wrote:
    =0A=0A
    > As long a= s they don't claim to support IPv6 (as standardised byRFC 2460)
    = =0A=0A
    =0A
    > there's no problem with = that. However, I don't think the IETF should be
    =0A> making excuses f= or them.
    =0A
    =0A
    So, if the device support looking 128 bytes int= o the packet is it RFC 2460 "compliant"? 256 bytes? 512bytes?

    If you believe Nalini's argument above, t= o comply with RFC 2460, the router must be able to look 65575 bytes into th= e packet. RFC 2460 places no limits on the size of the extension header cha= in, the 16-bit payload length field counts up 65535, and you have to add 40= bytes for the IPv6 header.
    =0A=0A

    If you don't think that is realistic, then I agree with you.
    =0A

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


    --1619178251-485119372-1370528779=:11870-- From nick@inex.ie Thu Jun 6 07:28:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761BC21F9975 for ; Thu, 6 Jun 2013 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9inmIMus72Bb for ; Thu, 6 Jun 2013 07:28:48 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8015121F91CE for ; Thu, 6 Jun 2013 07:28:42 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from pancake.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r56EScGm042944 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 15:28:38 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <51B09C96.6050108@inex.ie> Date: Thu, 06 Jun 2013 15:28:38 +0100 From: Nick Hilliard 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: Bill Jouris References: <1370528053.11966.YahooMailClassic@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1370528053.11966.YahooMailClassic@web2803.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:28:49 -0000 On 06/06/2013 15:14, Bill Jouris wrote: > (When IPv6 was first specified, were there ANY parts > of the then-current Internet which could deal with its headers?) yes and in fact much more so than now. When it was specified first in 1995 or so, most packet forwarding was done without hardware acceleration. These days, only tiny edge networks can use kit which doesn't use hardware assisted forwarding. > I'm not saying we should just ignore current limitations. But it doesn't > seem reasonable to make them a complete bar to change either. given that the problem is arguably getting worse, not better, I think the level of scepticism shown by v6ops regarding any further extension headers is by far the most prudent approach to further EHs right now. I understand that you disagree. Nick From dwing@cisco.com Thu Jun 6 08:43:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E2621F9193; Thu, 6 Jun 2013 08:43:32 -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 MHlk1C0F+5Jy; Thu, 6 Jun 2013 08:43:28 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF1921F972C; Thu, 6 Jun 2013 08:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1370533405; x=1371743005; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=txT9IPcn+l8DqfE0oZMDVqJhfJVx2BH1mJKxEvbLSIE=; b=lyygDkrAFl4bA0SQNTL6HYnUBgKEvW5ZF1FF3A5gC7sRV/dtwcpCiRgB sTNxsQTljsu5r7upKt0kagyiLZS1u8e6QHBwCcYgWPblZzVK/nSyLSeqd rHxoBMJnL0MN1Fi5UwnvWAWgiIlQjXdZ42RIGYhxf7TTm3l5QV2+SakvK 8=; X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="79874449" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 06 Jun 2013 15:43:24 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56FhNUd003338; Thu, 6 Jun 2013 15:43:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Thu, 6 Jun 2013 08:43:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1503) Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 15:43:32 -0000 On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: > Some of you may recall our discussion (during the last IETF) around = "how many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into A+P paradigm. ~500, ~1000, ~3000??? >=20 > Well, I started monitoring my home router and plotting the NAPT44 port = utilization on a minute-by-minute basis. You may find it here - = http://www.employees.org/~rajiva >=20 > In short, port range of 500 seems ok, though 1000 would be more than = enough for my home. I see several spikes in your data over 500 ports. During those times, = applications would be unable to function (unable to get a port). April = 29/30 is a long time where that occurs very visibly, but there are = shorter spikes elsewhere such as on April 17 and April 18. If you had = only 500 ports on those days, creating a new TCP mapping would have been = impossible, impacting ability to send or receive email, order books from = Amazon.com, and so on. I am surprised you conclude that "500 seems ok" = when such a limit would interfere with your network use on those days. What is the maximum number of mappings supported by your NAPT device? = Some residential-class NATs have a limit of 1024 mappings. -d > Suffice to say, this is just a sample representation, since the port = utilization would vary home to home, based on number of active devices, = type of applications, the degree of simultaneous device or application = usage etc. >=20 > If any of you are doing similar monitoring, then please share. >=20 > Cheers, > Rajiv >=20 > PS: Thanks to Erik Kline, who explained (with sufficient details) how = to use google charting for my data. And thanks to Xun Wang & Shaoshuai = Dai for helping me out significantly. >=20 > PS: My home has 3-4 active devices. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Ted.Lemon@nominum.com Thu Jun 6 09:34:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 owen@delong.com Thu Jun 6 11:23:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0D921F9988 for ; Thu, 6 Jun 2013 11:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPQ0ean9JsMo for ; Thu, 6 Jun 2013 11:23: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 E045B21F995C for ; Thu, 6 Jun 2013 11:23:08 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r56ILI8L015432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2013 11:21:19 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r56ILI8L015432 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370542879; bh=jBCVFRQu98NtXO5f1wi+G3cJsr8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f8iBAAFI7hrXpXzUiufMFpyHH2kzGWDq/NQ1mgkSlqnYFz6l3RSbgZa1Bd56aJgcS GekQq/VfcZ8DHVjUEtNwW5brg8Kry4jSJZVl/kxxapfLBIAyR4CT2m2kmWiK6L3SFE jjhYmBr4yjpCedR+z4LwqAvzHH0fnSJkd872SCsA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51B06B9D.7060300@inex.ie> Date: Thu, 6 Jun 2013 11:21:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370356742.58824.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> To: Nick Hilliard 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:21:19 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:23:10 -0000 On Jun 6, 2013, at 03:59 , Nick Hilliard wrote: > On 06/06/2013 10:52, Ole Troan wrote: >> true, but designing for the other extreme, for an Internet where there >> are middleboxes that inspect and wants to understand every bit in a >> packet is impossible. > > we're not talking about that level of extremity - we're talking about basic > functionality of a router. In my books this would require e.g. the ability > to handle packet filtering based on packet header characteristics using L3 > port ACLs. There's nothing interesting about a box which can only forward > packets and nothing else. > What is an L3 port ACL? If you are referring to TCP and UDP port numbers, then isn't that L4? Owen From touch@isi.edu Thu Jun 6 11:37:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6EF21F93E0 for ; Thu, 6 Jun 2013 11:37:22 -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 FZJDrDasCbxw for ; Thu, 6 Jun 2013 11:37:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2411911E80D5 for ; Thu, 6 Jun 2013 11:37:17 -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 r56IaUMD012609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 11:36:30 -0700 (PDT) Message-ID: <51B0D6A6.20908@isi.edu> Date: Thu, 06 Jun 2013 11:36:22 -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: "v6ops@ietf.org" References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> 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 Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:37:23 -0000 On Jun 6, 2013, at 03:59 , Nick Hilliard wrote: > On 06/06/2013 10:52, Ole Troan wrote: >> true, but designing for the other extreme, for an Internet where there >> are middleboxes that inspect and wants to understand every bit in a >> packet is impossible. > > we're not talking about that level of extremity - we're talking about basic > functionality of a router. In my books this would require e.g. the ability > to handle packet filtering based on packet header characteristics using L3 > port ACLs. There's nothing interesting about a box which can only forward > packets and nothing else. That box is called a router - see RFC 1812. Maybe that makes it uninteresting to you, but I would argue then that you are interested in firewalls, not routers. Joe From nick@inex.ie Thu Jun 6 11:39:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5AD21F9412 for ; Thu, 6 Jun 2013 11:39: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 0eLLyEdoTZ9v for ; Thu, 6 Jun 2013 11:39:33 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 17D1121F93E0 for ; Thu, 6 Jun 2013 11:39:32 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r56IdOkL044222 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 19:39:25 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51B0D75C.3070100@inex.ie> Date: Thu, 06 Jun 2013 19:39:24 +0100 From: Nick Hilliard 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: Owen DeLong References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <51AE3001.7040905@inex.ie> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:39:34 -0000 On 06/06/2013 19:21, Owen DeLong wrote: > What is an L3 port ACL? uh, an ACL on a layer 3 port. Nick From owen@delong.com Thu Jun 6 11:43:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: "Manfredi, Albert E" , "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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:48:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528AC21E80B9 for ; Thu, 6 Jun 2013 11:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Fb3pY9AyXCwc for ; Thu, 6 Jun 2013 11:48:28 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E521E80B0 for ; Thu, 6 Jun 2013 11:48:25 -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 r56IkkLK016195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2013 11:46:46 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r56IkkLK016195 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370544406; bh=A+y7fg3EDnHmla3hrksY+J0AGM8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=S1EW014lMjpk5cIWRK3l+2eNUmcV5mO05HQZu5rFD+jLv+Q7wHbe1jDKD7qMy9suX RaYBfg+9Xq1dQiPtxMK45RJ1r4JK3CJ831fkViz974jrrxYtR89p9Hj749IyzMVDs6 nplkFXXTzHOy8xqsEE3lFruQfLTvtHsnryG3KF3c= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <6.2.5.6.2.20130606034128.0d9e0bb0@resistor.net> Date: Thu, 6 Jun 2013 11:46:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <6.2.5.6.2.20130606034128.0d9e0bb0@resistor.net> To: SM 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:46:46 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:48:29 -0000 On Jun 6, 2013, at 04:03 , SM wrote: > Hi Lorenzo, > At 20:30 05-06-2013, 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 > The draft could be considered as a technical recommendation, assuming = it is published. The RIR policies should not be a constraint as an = organization is supposed to be able to get the IPv6 address space it = requests for its operations (I would like to avoid the usual = controversial terms). SM, this is not correct. An organization is supposed to be able to get = the IPv6 address space it can justify according to current RIR policies. I'm not sure what you mean by "usual controversial terms" in this = context. > George Michaelson commented about RIR policies a few days ago. I read = that comment as "if the RIR policy is broken, fix it". I do understand = that there is a lot of bureaucracy to work with. However, if the RIR = policy or policies are considered as a constraint to available = alternatives in this discussion, it is like discussing about the chicken = and the egg. Yes, RIR policies can be changed, just as RFCs can be changed. However, = since this document purports to be a statement of what can be achieved = at the time it is published as an IETF Informational RFC, we can and = should incorporate the RIR reality as it exists at that time into the = document. If you believe that RIR policy(ies) should be modified to better enable = semantic overloading of prefixes and that this document should, instead, = reflect a world where those policies have been modified, then, perhaps = by having this discussion in the IETF now, the cart has been placed = before the horse and we should table this draft until such time as the = RIR policy work has concluded to enable it. > As long as the ISP does not say that it is assigning the home users a = /32 it should not be a problem. We can always argue whether it is = appropriate or not to assign a home user a /32. It's unlikely that = there would be agreement about that. Also not true. If the ISP says that it is assigning home users /44s or = /40s or whatever, it will be a problem. I'm pretty sure that there is universal agreement that assigning a home = user something shorter than a /48 should require significant = justification if it is possible at all. I'm willing to bet that there is = near universal agreement that a home user simply shouldn't be able to = get more than a /48 per residence. (I personally think that a home user = should have the option of justifying more, but I admit even I cannot = envision a scenario where this option could be successfully exercised). Owen From owen@delong.com Thu Jun 6 11:58:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 nick@inex.ie Thu Jun 6 12:43:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE41E21F9294 for ; Thu, 6 Jun 2013 12:43: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 d7ScwuBZATBT for ; Thu, 6 Jun 2013 12:43:21 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 20DFB21F9289 for ; Thu, 6 Jun 2013 12:43:20 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r56JhGsx044521 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 6 Jun 2013 20:43:16 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51B0E654.9000403@inex.ie> Date: Thu, 06 Jun 2013 20:43:16 +0100 From: Nick Hilliard 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: v6ops@ietf.org References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370370747.32298.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> <51B0D6A6.20908@isi.edu> In-Reply-To: <51B0D6A6.20908@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:43:22 -0000 On 06/06/2013 19:36, Joe Touch wrote: > Maybe that makes it uninteresting to you, but I would argue then that you > are interested in firewalls, not routers. on the L3 infrastructures I manage, all the routers have urpf and infrastructure ACLs applied, and use lots of qos stuff to stop their respective control planes from being trashed by unwanted traffic. These boxes were definitely routers when I installed them, and unless someone has managed to sneak into a number of locked cages and done a surreptitious forklift swapout of the whole lot for firewalls, I'm willing to bet that they still are. :-) Nick From touch@isi.edu Thu Jun 6 13:18:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ED521F9975 for ; Thu, 6 Jun 2013 13:18:00 -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 b++AALstwgLZ for ; Thu, 6 Jun 2013 13:17:43 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFFE21F997E for ; Thu, 6 Jun 2013 13:17:43 -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 r56KH8v3029382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 13:17:08 -0700 (PDT) Message-ID: <51B0EE3B.4000807@isi.edu> Date: Thu, 06 Jun 2013 13:16: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: Nick Hilliard References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> <51B0D6A6.20908@isi.edu> <51B0E654.9000403@inex.ie> In-Reply-To: <51B0E654.9000403@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:18:00 -0000 They're sold as routers, but they have two distinct functions: router functions firewall functions Routers don't *need* to do anything with L4 to be called a router. That's not how router vendors market them, agreed. Joe On 6/6/2013 12:43 PM, Nick Hilliard wrote: > On 06/06/2013 19:36, Joe Touch wrote: >> Maybe that makes it uninteresting to you, but I would argue then that you >> are interested in firewalls, not routers. > > on the L3 infrastructures I manage, all the routers have urpf and > infrastructure ACLs applied, and use lots of qos stuff to stop their > respective control planes from being trashed by unwanted traffic. These > boxes were definitely routers when I installed them, and unless someone has > managed to sneak into a number of locked cages and done a surreptitious > forklift swapout of the whole lot for firewalls, I'm willing to bet that > they still are. :-) > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jcurran@istaff.org Thu Jun 6 13:34:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 nick@inex.ie Thu Jun 6 13:36:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB7621E80D4 for ; Thu, 6 Jun 2013 13:36:49 -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 FLIh3YLRF7xX for ; Thu, 6 Jun 2013 13:36:46 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 220FF21E8085 for ; Thu, 6 Jun 2013 13:36:45 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r56Kagk7044767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 21:36:42 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51B0F2DA.30300@inex.ie> Date: Thu, 06 Jun 2013 21:36:42 +0100 From: Nick Hilliard 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: Joe Touch References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <51AE60CF.6000709@inex.ie> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> <51B0D6A6.20908@isi.edu> <51B0E654.9000403@inex.ie> <51B0EE3B.4000807@isi.edu> In-Reply-To: <51B0EE3B.4000807@isi.edu> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:36:51 -0000 On 06/06/2013 21:16, Joe Touch wrote: > They're sold as routers, but they have two distinct functions: > > router functions > firewall functions > > Routers don't *need* to do anything with L4 to be called a router. That's > not how router vendors market them, agreed. Joe, they are routers. They need stateless packet filtering and various other things which require packet header inspection to survive on the internet, but that does not make them routers any the less. We can pick nits about this all day if you want, but a firewall is generally accepted to be a device which performs stateful/inspected flow forwarding, and a router is generally accepted to be a device which does stateless packet forwarding (albeit with features which allow stateless filtering). Now can we move on? Nick From brian.e.carpenter@gmail.com Thu Jun 6 13:43:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C1A21F9998 for ; Thu, 6 Jun 2013 13:43: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 c9YVMUxq9iLi for ; Thu, 6 Jun 2013 13:43:00 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9476121F998A for ; Thu, 6 Jun 2013 13:43:00 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so293615pdj.17 for ; Thu, 06 Jun 2013 13:43:00 -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=K6t40LssOdIKJzfpXUFrSfMp8ZK/zDowBMkawTHZmdY=; b=xsv1GAxGEI0fDgzWyVVi1fQl9RQ0gFU+o33REBlX+Ka1HIF96+WMwAHlzeouHQPRIi y1BRFtzG83eAEuaCJIVIhPDG/cxO/mX4911N3qt7epApYDSeX/FA8YJmmHGLjnJfGaaN eaYFLPOS6Ys9aFyUCygbce20zODfmbf10MX+GytVovvgi8wkatCoarBYBmzx76HKxd27 4CGehkkC7sDvjJpO7pmui39cG60Ns8nRkc8S93nF6XaMj7bgNxaDF28TeH0t/EMA4B2c 4ek+x8e2ycEO5x2wBv1QWFAXOHn3pYbTzQeSYfDUmjWWOBfPLJ+ZZ1NUBztswHodRAV0 fDUg== X-Received: by 10.66.122.163 with SMTP id lt3mr40840597pab.219.1370551380357; Thu, 06 Jun 2013 13:43:00 -0700 (PDT) Received: from [192.168.1.2] (77.202.252.27.dyn.cust.vf.net.nz. [27.252.202.77]) by mx.google.com with ESMTPSA id uv1sm74228467pbc.16.2013.06.06.13.42.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 13:42:59 -0700 (PDT) Message-ID: <51B0F45A.6020406@gmail.com> Date: Fri, 07 Jun 2013 08:43:06 +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 References: <51AFA312.50500@ gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <51AFC108.80701@gmail.com> <20130606.075158.74674309.sthaug@nethelp.no> In-Reply-To: <20130606.075158.74674309.sthaug@nethelp.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:43:06 -0000 On 06/06/2013 17:51, sthaug@nethelp.no wrote: >>> So, if the device support looking 128 bytes into the packet is it RFC 2460 "compliant"? 256 bytes? 512bytes? >> Well, yes, there's a problem there. The IPv6 header is a linked list >> of variable length. Hardware architectures that assume a consistent >> signature in the first 2**N bytes won't work well on a linked list. >> >> I don't know what to say since this has been the IPv6 architecture >> since 1996. All we can do, which a couple of active drafts in 6man >> are trying to do, is clarify and limit the scope of the issue. > > Isn't this a pretty fundamental problem/flaw? Yes. Designing a box that is supposed to look beyond the first 40 bytes that cannot handle the linked-list design of the IPv6 header is a fundamental flaw in the box design. I don't think it's very hard to design silicon to flip through a linked list, but it's not the same as silicon that matches a given bit pattern in the first N bits. > As a *user* of high > speed routers, I want to know that my boxes are going to forward a > packet within a certain small time - which means that the address > *lookup* time must be bounded. It is bounded. What isn't bounded is the time to look up stuff way beyond the destination address. > A potentially long chain of headers > which is *not* bounded doesn't give me confidence. So I will vote > with my wallet and purchase boxes from the equipment vendors that > bound the lookup time (and the number of bytes they look into the > headers). I do agree that a completely unbounded chain is worrisome and that could be clarified in the specs. If your parenthesis is relevant, it means they have the flaw of not handling the linked list structure in hardware. It would be good to ask them when they plan to do so, given that it was defined in 1996. Also when they plan to support RFC 6437 and 6438, which is another part of this puzzle. I realise it's no comfort for current operations, but the vendors really do need to catch up with the specs. Brian From sthaug@nethelp.no Thu Jun 6 13:48:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B908221F949F for ; Thu, 6 Jun 2013 13:48: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=[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 v88tghU0N3Wc for ; Thu, 6 Jun 2013 13:48:11 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id AA18221F9424 for ; Thu, 6 Jun 2013 13:48:01 -0700 (PDT) Received: (qmail 46368 invoked from network); 6 Jun 2013 20:47:59 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Jun 2013 20:47:59 -0000 Date: Thu, 06 Jun 2013 22:47:59 +0200 (CEST) Message-Id: <20130606.224759.74732484.sthaug@nethelp.no> To: touch@isi.edu From: sthaug@nethelp.no In-Reply-To: <51B0EE3B.4000807@isi.edu> References: <51B0D6A6.20908@isi.edu> <51B0E654.9000403@inex.ie> <51B0EE3B.4000807@isi.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:48:16 -0000 > They're sold as routers, but they have two distinct functions: > > router functions > firewall functions > > Routers don't *need* to do anything with L4 to be called a router. > That's not how router vendors market them, agreed. That's a nice distinction in theory. How much does it matter in practice? I use some rather basic, stateless, firewall functions for my routers. A router which doesn't offer these functions is simply not a relevant box in my network. I think it would be useful for router vendors to have some idea of how far into the IPv6 header they need to look, in order to be a proper IPv6 router. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From sthaug@nethelp.no Thu Jun 6 13:59:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1858621E8113 for ; Thu, 6 Jun 2013 13:59:21 -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 423drTUtS0YR for ; Thu, 6 Jun 2013 13:59:16 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 63F1F21E80FE for ; Thu, 6 Jun 2013 13:58:56 -0700 (PDT) Received: (qmail 46849 invoked from network); 6 Jun 2013 20:58:54 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Jun 2013 20:58:54 -0000 Date: Thu, 06 Jun 2013 22:58:54 +0200 (CEST) Message-Id: <20130606.225854.41650275.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com From: sthaug@nethelp.no In-Reply-To: <51B0F45A.6020406@gmail.com> References: <51AFC108.80701@gmail.com> <20130606.075158.74674309.sthaug@nethelp.no> <51B0F45A.6020406@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: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:59:21 -0000 > > As a *user* of high > > speed routers, I want to know that my boxes are going to forward a > > packet within a certain small time - which means that the address > > *lookup* time must be bounded. > > It is bounded. What isn't bounded is the time to look up stuff > way beyond the destination address. And therein lies the problem. As pointed out by Nick Hilliard and myself, we *need* those stateless firewall functions, which may need to look up stuff way beyond the destination address. I don't find a discussion of whether such functions *should* be needed in a router or not all that relevant. Steinar Haug, AS 2116 From touch@isi.edu Thu Jun 6 14:11:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DB611E8123 for ; Thu, 6 Jun 2013 14:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9pESrTmP8Uk for ; Thu, 6 Jun 2013 14:11:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1D11E8124 for ; Thu, 6 Jun 2013 14:11:06 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r56LAXcT016721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 14:10:33 -0700 (PDT) Message-ID: <51B0FACD.7040707@isi.edu> Date: Thu, 06 Jun 2013 14:10:37 -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: sthaug@nethelp.no References: <51B0D6A6.20908@isi.edu> <51B0E654.9000403@inex.ie> <51B0EE3B.4000807@isi.edu> <20130606.224759.74732484.sthaug@nethelp.no> In-Reply-To: <20130606.224759.74732484.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:11:14 -0000 On 6/6/2013 1:47 PM, sthaug@nethelp.no wrote: >> They're sold as routers, but they have two distinct functions: >> >> router functions >> firewall functions >> >> Routers don't *need* to do anything with L4 to be called a router. >> That's not how router vendors market them, agreed. > > That's a nice distinction in theory. How much does it matter in > practice? I use some rather basic, stateless, firewall functions for > my routers. A router which doesn't offer these functions is simply > not a relevant box in my network. > > I think it would be useful for router vendors to have some idea of > how far into the IPv6 header they need to look, in order to be a > proper IPv6 router. To be a *router*, they definitely need to process the HBH options header in its entirety if present. To do things beyond that, they need to look far enough into the header chain to satisfy the vendor claiming that the device performs a non-router function, such as L4 filtering, etc. I.e., if you want to be just a router, stop at HBH. If being more than a router is what you want to do - and that's fine with me - then dig in and do the work to earn it. Joe From touch@isi.edu Thu Jun 6 14:18:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EEB21E8063 for ; Thu, 6 Jun 2013 14:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.524 X-Spam-Level: X-Spam-Status: No, score=-104.524 tagged_above=-999 required=5 tests=[AWL=2.075, 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 9WGupIChifKM for ; Thu, 6 Jun 2013 14:18:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8189911E8103 for ; Thu, 6 Jun 2013 14:18:32 -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 r56LGuKo027534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 14:16:56 -0700 (PDT) Message-ID: <51B0FC4C.2020808@isi.edu> Date: Thu, 06 Jun 2013 14:17:00 -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: sthaug@nethelp.no References: <51AFC108.80701@gmail.com> <20130606.075158.74674309.sthaug@nethelp.no> <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> In-Reply-To: <20130606.225854.41650275.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:18:41 -0000 On 6/6/2013 1:58 PM, sthaug@nethelp.no wrote: >>> As a *user* of high >>> speed routers, I want to know that my boxes are going to forward a >>> packet within a certain small time - which means that the address >>> *lookup* time must be bounded. >> >> It is bounded. What isn't bounded is the time to look up stuff >> way beyond the destination address. > > And therein lies the problem. As pointed out by Nick Hilliard and > myself, we *need* those stateless firewall functions, which may > need to look up stuff way beyond the destination address. I don't > find a discussion of whether such functions *should* be needed in > a router or not all that relevant. Just as I don't find a discussion of how much the cost to implement such functions makes the life of router venders more complex. If the kitchen is too hot... Joe From he@uninett.no Thu Jun 6 14:37:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB9021F8763 for ; Thu, 6 Jun 2013 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 deNp28-ekPiH for ; Thu, 6 Jun 2013 14:37:00 -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 0287521F86F4 for ; Thu, 6 Jun 2013 14:36:59 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 702263D0B3; Thu, 6 Jun 2013 23:36:57 +0200 (CEST) Date: Thu, 06 Jun 2013 23:36:57 +0200 (CEST) Message-Id: <20130606.233657.225564173.he@uninett.no> To: touch@isi.edu From: Havard Eidnes In-Reply-To: <51B0FC4C.2020808@isi.edu> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:37:05 -0000 >> And therein lies the problem. As pointed out by Nick Hilliard and >> myself, we *need* those stateless firewall functions, which may >> need to look up stuff way beyond the destination address. I don't >> find a discussion of whether such functions *should* be needed in >> a router or not all that relevant. > > Just as I don't find a discussion of how much the cost to implement > such functions makes the life of router venders more complex. > > If the kitchen is too hot... That's one vantage point. Another would be one which talks about ivory towers and losing touch with what is practically possible now. Regards, - H=E5vard From sm@resistor.net Thu Jun 6 14:37:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EDA21F8749 for ; Thu, 6 Jun 2013 14:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 9oot8StOs+49 for ; Thu, 6 Jun 2013 14:37:22 -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 4B82D21F86BB for ; Thu, 6 Jun 2013 14:37:22 -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 r56LbCp4015483; Thu, 6 Jun 2013 14:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1370554638; bh=0CY+WliSPTtk+x58fESf/HlbehRyk/47YG/6pKUawmU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B0hmmmQz1aKmHrVMSSrwZ/GFrS3pojn8QoVHxY3mblrYyxasY6aVMZixaMHDY/PL7 Uh/KDM7cPIfbbf5HfeC9H/YoGoPA+JYHl1TzT1KdEJMprWi9bH51jHmcZuUdE6RU+I brFYlSwF2MjDPdCTn3ErikmKALSBkZr6YYsRTvNU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1370554638; i=@resistor.net; bh=0CY+WliSPTtk+x58fESf/HlbehRyk/47YG/6pKUawmU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=N+xfnU/ZNlBQ7XdyrDbdvX28R6iGgByACJyoBHiIFeOXRXej5aJJtYuHTuLwAkVxx P7cT3fw1AuU2h+OL6ERUhxGrqAupE+a/svGi9HqkXjVs4tQl5sEPa/zPbopBRHvxic r/Dp6O/wz4igw5amAaF2Yok2E2sruoSBk4ja+KVw= Message-Id: <6.2.5.6.2.20130606140756.0cb939a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Jun 2013 14:33:21 -0700 To: Owen DeLong From: SM In-Reply-To: References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <6.2.5.6.2.20130606034128.0d9e0bb0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:37:23 -0000 Hi Owen, At 11:46 06-06-2013, Owen DeLong wrote: >SM, this is not correct. An organization is supposed to be able to >get the IPv6 address space it can justify according to current RIR policies. Yes. >I'm not sure what you mean by "usual controversial terms" in this context. Let's forget about this one. :-) >Yes, RIR policies can be changed, just as RFCs can be changed. >However, since this document purports to be a statement of what can >be achieved at the time it is published as an IETF Informational >RFC, we can and should incorporate the RIR reality as it exists at >that time into the document. Mixing technical and non-technical topics make it difficult to resolve an argument. If the argument is technical, sound RIR policies shouldn't be an unsurmountable hurdle. >If you believe that RIR policy(ies) should be modified to better >enable semantic overloading of prefixes and that this document >should, instead, reflect a world where those policies have been >modified, then, perhaps by having this discussion in the IETF now, >the cart has been placed before the horse and we should table this >draft until such time as the RIR policy work has concluded to enable it. Given that the relevant draft has not been approved that discussion could be reopened. It's not a good idea in my opinion to do that. >Also not true. If the ISP says that it is assigning home users /44s >or /40s or whatever, it will be a problem. > >I'm pretty sure that there is universal agreement that assigning a >home user something shorter than a /48 should require significant >justification if it is possible at all. I'm willing to bet that >there is near universal agreement that a home user simply shouldn't >be able to get more than a /48 per residence. (I personally think >that a home user should have the option of justifying more, but I >admit even I cannot envision a scenario where this option could be >successfully exercised). I would try to convince the hostmaster that pigs can fly before I request /40 assignments for home users. :-) Regards, -sm From touch@isi.edu Thu Jun 6 14:41:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D1821F8825 for ; Thu, 6 Jun 2013 14:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=-0.340, 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 XRCbiIJaaV0a for ; Thu, 6 Jun 2013 14:41:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9C24821F8763 for ; Thu, 6 Jun 2013 14:41:40 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r56LfOXi026501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 14:41:24 -0700 (PDT) Message-ID: <51B10208.9060204@isi.edu> Date: Thu, 06 Jun 2013 14:41:28 -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: Havard Eidnes References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> In-Reply-To: <20130606.233657.225564173.he@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:41:46 -0000 On 6/6/2013 2:36 PM, Havard Eidnes wrote: >>> And therein lies the problem. As pointed out by Nick Hilliard and >>> myself, we *need* those stateless firewall functions, which may >>> need to look up stuff way beyond the destination address. I don't >>> find a discussion of whether such functions *should* be needed in >>> a router or not all that relevant. >> >> Just as I don't find a discussion of how much the cost to implement >> such functions makes the life of router venders more complex. >> >> If the kitchen is too hot... > > That's one vantage point. Another would be one which talks about > ivory towers and losing touch with what is practically possible now. If it's possible, then there's no problem. What you're all suggesting here are ways to limit IPv6 to make it more convenient for router vendors to implement various features that were never part of the design (of either the Internet architecture nor of IPv6 in specific). If you want to make sure that IP supports efficient router parsing of L4 header information, IMO you can take that up when we design IPv7, but it was never a requirement of IPv6. Assuming it now is - as you are all discussing - impractical. Joe From rajiva@cisco.com Thu Jun 6 15:41:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF59521F87B7; Thu, 6 Jun 2013 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 oTpdzmuxH9vS; Thu, 6 Jun 2013 15:41:46 -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 20D6321F938E; Thu, 6 Jun 2013 15:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3557; q=dns/txt; s=iport; t=1370558506; x=1371768106; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GcRkabjegJdyA/Ic2V/3cSpwUoMxvBhBDzHbf+ZcycY=; b=glr8BFd7oj/hLQsswcCnfytqSRbvLO6cBKUwyxjK3LPgB9E2VwwnFXKx 4Kb/JpjmfSTxupP+eOb4Q74n+3WONPVBmCa8al7e7QbB7eknffhEhan05 q+kH4HW5f/ggwGHafBzmvB1kyLkOSYEc+d9V0ZJtylYWaxiauF0BjtR0T Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOUOsVGtJV2Z/2dsb2JhbABZFoJzML5wehZ0giMBAQEDAQEBATc0CwUHBAIBCBEEAQEBChQQJwsdCAEBBA4FCAGHfgYMuz+NcAEJAYEGMQcGgnRhA5Ntj3KFIIMPgWgBCBcf X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219603490" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 22:41:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r56Mfjcd011311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:41:45 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:41:44 -0500 From: "Rajiv Asati (rajiva)" To: "Dan Wing (dwing)" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlABChP6AAALM1dA= Date: Thu, 6 Jun 2013 22:41:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:41:51 -0000 Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times =20 Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) wrote= : >=20 > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. >=20 > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. >=20 > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. >=20 > -d >=20 > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From owen@delong.com Thu Jun 6 15:57:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30CB21F99FE; Thu, 6 Jun 2013 15:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 VPiWlS0SnTV3; Thu, 6 Jun 2013 15:57:58 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B19E821F99FC; Thu, 6 Jun 2013 15:57:58 -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 r56Ms3Pv023866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2013 15:54:03 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r56Ms3Pv023866 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370559244; bh=XOC6aJPR8ro+Jbb4/SAmvP7Hdu4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SA5hoKDz17nUDDu819T+QXxURVg5vDL6MxfHNWI2gsuqSHcSGDm/wA3Bb94VfGyU8 tL5lZTfbrlcaBGAGXRjAcv5/YVd0nGFE0vlw/lzdO+B+zdlLrdU6Eh6ST6dPVsGHbD 6ZDn11/OSpdj/4GNhZuoviIC8FSIQJ5C8c1YDXrQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Thu, 6 Jun 2013 17:54:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2FB6F4EA-F632-43E1-B7ED-A13338610746@delong.com> References: To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 06 Jun 2013 15:54:04 -0700 (PDT) Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:58:00 -0000 At the point where we start calling any form of NAT "non-degraded" = service, we have already strayed so far from rational thought that it is = difficult to believe any rational conclusion can come from it. ANY NAT is a degraded service. More NAT is inherently more degraded, = even if it doesn't suffer an additional lack of available port numbers. Owen On Jun 6, 2013, at 5:41 PM, "Rajiv Asati (rajiva)" = wrote: > Hi Dan, >=20 >> and so on. I am surprised you conclude that "500 seems ok" when such = a >> limit would interfere with your network use on those days. >=20 > I based that statement ("...seems ok,") on the very fact that the = number of times the NAT utilization exceeded 500 mappings (equating to = 500 ports, in my setup) in the sample period (~2 months) was relatively = quite low. So, if the NAT device was limited to only 500 mappings, then = the experience would have been ok for 99% of the time and degraded 1% of = the time. This is an important consideration, IMO. >=20 > For ex, in the last 2 weeks, the number of times NAT mappings exceeded = 500 were: >=20 > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times >=20 > Of course, 1000 ports (resulting in 1000+ mappings) would have been = more than enough to accommodate the times when the mappings exceeded = 500, but stayed within 1000 (except once). >=20 >=20 >> What is the maximum number of mappings supported by your NAPT device? >> Some residential-class NATs have a limit of 1024 mappings. >=20 > My NAPT device seemingly can use upto 64K ports. :) >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: Dan Wing (dwing) >> Sent: Thursday, June 06, 2013 11:43 AM >> To: Rajiv Asati (rajiva) >> Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >> behave@ietf.org; Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >>=20 >> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: >>=20 >>> Some of you may recall our discussion (during the last IETF) around = "how >> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into >> A+P paradigm. ~500, ~1000, ~3000??? >>>=20 >>> Well, I started monitoring my home router and plotting the NAPT44 = port >> utilization on a minute-by-minute basis. You may find it here - >> http://www.employees.org/~rajiva >>>=20 >>> In short, port range of 500 seems ok, though 1000 would be more than >> enough for my home. >>=20 >> I see several spikes in your data over 500 ports. During those = times, >> applications would be unable to function (unable to get a port). = April 29/30 >> is a long time where that occurs very visibly, but there are shorter = spikes >> elsewhere such as on April 17 and April 18. If you had only 500 = ports on >> those days, creating a new TCP mapping would have been impossible, >> impacting ability to send or receive email, order books from = Amazon.com, >> and so on. I am surprised you conclude that "500 seems ok" when such = a >> limit would interfere with your network use on those days. >>=20 >> What is the maximum number of mappings supported by your NAPT device? >> Some residential-class NATs have a limit of 1024 mappings. >>=20 >> -d >>=20 >>> Suffice to say, this is just a sample representation, since the port >> utilization would vary home to home, based on number of active = devices, >> type of applications, the degree of simultaneous device or = application >> usage etc. >>>=20 >>> If any of you are doing similar monitoring, then please share. >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>> PS: Thanks to Erik Kline, who explained (with sufficient details) = how to use >> google charting for my data. And thanks to Xun Wang & Shaoshuai Dai = for >> helping me out significantly. >>>=20 >>> PS: My home has 3-4 active devices. >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From john.mann@monash.edu Thu Jun 6 17:03:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCB121F8F6E for ; Thu, 6 Jun 2013 17:03:08 -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 dcdAllLxft55 for ; Thu, 6 Jun 2013 17:03:01 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id DE99F21F8E37 for ; Thu, 6 Jun 2013 17:02:53 -0700 (PDT) Received: from mail-we0-f176.google.com ([74.125.82.176]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKUbEjJfrtp0Oh38iVwUdksgI1WdcuTmoT@postini.com; Thu, 06 Jun 2013 17:02:54 PDT Received: by mail-we0-f176.google.com with SMTP id t56so2600318wes.35 for ; Thu, 06 Jun 2013 17:02:44 -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=3kc58T8ylttI1qpEPU5Y+ebdfdTQ/WZquFtnPlGJLrU=; b=bBYpCEbTuJm2bAy7tiZYhvoy9VabnsGP8y47jFyiBCWIXzCCnuQsRwkVo1oCPZYQMy X1vUtTHDcKqvMDOZRKk87m4KzWahL0OmY0wWJOLCouPXablbzjbb/urG07KMmoyy+KW8 hDga//mOCKmb4S0gd4cZdn2iiL6IgsQma7vWfXiiQt0My/azKLmBZ+/efB6xBvnXXftk ic63aG0RsGfRlLHLCSuaCi7Zvy7FnjfURhB2vYn4nbrLNAKOdvlgrUUGfyDld+n3ePfr aCOxvfFtpDEfOppdNHIacFaoRGo9uXira+flB1042V4Lrw+gVBtFFvlTm7SeFV1NuvOX trOw== X-Received: by 10.180.206.176 with SMTP id lp16mr232129wic.43.1370563364443; Thu, 06 Jun 2013 17:02:44 -0700 (PDT) X-Received: by 10.180.206.176 with SMTP id lp16mr232123wic.43.1370563364344; Thu, 06 Jun 2013 17:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.112.201 with HTTP; Thu, 6 Jun 2013 17:02:24 -0700 (PDT) In-Reply-To: References: From: John Mann Date: Fri, 7 Jun 2013 10:02:24 +1000 Message-ID: To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=001a11c37be079626904de8526d7 X-Gm-Message-State: ALoCoQmZ5BzwKT2dniaYj5amAVo9flS3fVIewmw/acHkENrS5YpfHitPFxzJnTnAW3Z/knAfdvjxJ5eUCDUOXhzOoHlsUCphduJJLHEyi8HsHess9/rDLH64EbQELlgDGN/cGcPQzEOK Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 00:03:14 -0000 --001a11c37be079626904de8526d7 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) wrote: > Hi Dan, > > > and so on. I am surprised you conclude that "500 seems ok" when such a > > limit would interfere with your network use on those days. > > I based that statement ("...seems ok,") on the very fact that the number > of times the NAT utilization exceeded 500 mappings (equating to 500 ports, > in my setup) in the sample period (~2 months) was relatively quite low. So, > if the NAT device was limited to only 500 mappings, then the experience > would have been ok for 99% of the time and degraded 1% of the time. This is > an important consideration, IMO. > > For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 > were: > > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times > I think a more-interesting statistic would be "how many connection setups would have failed". But I don't think you can measure that just by polling concurrent connections at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" would be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then report that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more > than enough to accommodate the times when the mappings exceeded 500, but > stayed within 1000 (except once). > > > > What is the maximum number of mappings supported by your NAPT device? > > Some residential-class NATs have a limit of 1024 mappings. > Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) > > Cheers, > Rajiv > > > > -----Original Message----- > > From: Dan Wing (dwing) > > Sent: Thursday, June 06, 2013 11:43 AM > > To: Rajiv Asati (rajiva) > > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > > behave@ietf.org; Erik Kline (ek@google.com) > > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > > > Some of you may recall our discussion (during the last IETF) around > "how > > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > > A+P paradigm. ~500, ~1000, ~3000??? > > > > > > Well, I started monitoring my home router and plotting the NAPT44 port > > utilization on a minute-by-minute basis. You may find it here - > > http://www.employees.org/~rajiva > > > > > > In short, port range of 500 seems ok, though 1000 would be more than > > enough for my home. > > > > I see several spikes in your data over 500 ports. During those times, > > applications would be unable to function (unable to get a port). April > 29/30 > > is a long time where that occurs very visibly, but there are shorter > spikes > > elsewhere such as on April 17 and April 18. If you had only 500 ports on > > those days, creating a new TCP mapping would have been impossible, > > impacting ability to send or receive email, order books from Amazon.com, > > and so on. I am surprised you conclude that "500 seems ok" when such a > > limit would interfere with your network use on those days. > > > > What is the maximum number of mappings supported by your NAPT device? > > Some residential-class NATs have a limit of 1024 mappings. > > > > -d > > > > > Suffice to say, this is just a sample representation, since the port > > utilization would vary home to home, based on number of active devices, > > type of applications, the degree of simultaneous device or application > > usage etc. > > > > > > If any of you are doing similar monitoring, then please share. > > > > > > Cheers, > > > Rajiv > > > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how > to use > > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > > helping me out significantly. > > > > > > PS: My home has 3-4 active devices. > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c37be079626904de8526d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
    Hi Dan,

    > and so on. =A0I am surprised you conclude that "500 seems ok"= ; when such a
    > limit would interfere with your network use on those days.

    I based that statement ("...seems ok,") on the very fact th= at the number of times the NAT utilization exceeded 500 mappings (equating = to 500 ports, in my setup) in the sample period (~2 months) was relatively = quite low. So, if the NAT device was limited to only 500 mappings, then the= experience would have been ok for 99% of the time and degraded 1% of the t= ime. This is an important consideration, IMO.

    For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

    June 3 - 1 time
    May 29 - 1 time
    May 28 - 3 times
    May 26 - 1 time
    May 23 - 1 time
    May 22 - 2 times
    May 21 - 3 times

    I think a more-i= nteresting statistic would be "how many connection setups would have f= ailed".
    But I don't think you can measure that jus= t by polling concurrent connections at specific times.
    It might take e.g. netflow exporting and analysis ...

    However "number of concurrent connections t= hat couldn't have been setup" would be useful in=A0gauging=A0the i= mpact
    e.g. on May 29 there was one spike of 734 concurrent connections= , then report that as 234 potential failures.

    Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once).


    > What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.

    Is that a combined limit of TCP and UD= P and ICMP, or independent?

    My NAPT device seemingly can use upto 64K ports. :)

    Cheers,
    Rajiv


    > -----Original Message-----
    > From: Dan Wing (dwing)
    > Sent: Thursday, June 06, 2013 11:43 AM
    > To: Rajiv Asati (rajiva)
    > Cc: v= 6ops@ietf.org; Softwires-wg list (softwires@ietf.org);
    > behave@ietf.org; Erik Kline (ek@google.com)
    > Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
    >
    >
    > On Jun 5, 2013, at 6:14 = AM, Rajiv Asati (rajiva) <rajiva@cis= co.com> wrote:
    >
    > > Some of you may recall our discussion (during the last IETF) arou= nd "how
    > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
    > A+P paradigm. ~500, ~1000, ~3000???
    > >
    > > Well, I started monitoring my home router and plotting the NAPT44= port
    > utilization on a minute-by-minute basis. You may find it here -
    > http://= www.employees.org/~rajiva
    > >
    > > In short, port range of 500 seems ok, though 1000 would be more t= han
    > enough for my home.
    >
    > I see several spikes in your data over 500 ports. =A0During those time= s,
    > applications would be unable to function (unable to get a port). =A0Ap= ril 29/30
    > is a long time where that occurs very visibly, but there are shorter s= pikes
    > elsewhere such as on April 17 and April 18. =A0If you had only 500 por= ts on
    > those days, creating a new TCP mapping would have been impossible,
    > impacting ability to send or receive email, order books from Amazon.co= m,
    > and so on. =A0I am surprised you conclude that "500 seems ok"= ; when such a
    > limit would interfere with your network use on those days.
    >
    > What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
    >
    > -d
    >
    > > Suffice to say, this is just a sample representation, since the p= ort
    > utilization would vary home to home, based on number of active devices= ,
    > type of applications, the degree of simultaneous device or application=
    > usage etc.
    > >
    > > If any of you are doing similar monitoring, then please share. > >
    > > Cheers,
    > > Rajiv
    > >
    > > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
    > google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
    > helping me out significantly.
    > >
    > > PS: My home has 3-4 active devices.
    > > _______________________________________________
    > > Behave mailing list
    > > Behave@ietf.org
    > > https://www.ietf.org/mailman/listinfo/behave

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

    --001a11c37be079626904de8526d7-- From dwing@cisco.com Thu Jun 6 17:19:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2D921F9330; Thu, 6 Jun 2013 17:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytJ6g-ZpnowZ; Thu, 6 Jun 2013 17:19:03 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F821F92E3; Thu, 6 Jun 2013 17:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12207; q=dns/txt; s=iport; t=1370564343; x=1371773943; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=85pyCK9m8qD2ywdUW+y5g6sX9+TFQ3DBCPnrzptH+SU=; b=A8AUfDdHRFKbm29heChSR/niteStnSa17JVZyXjAXz5H4EsPjsGOaqTh B1yV5Pa9KqVFgfdwWvulzgyhO84kdLs2+Sp3k6BWWQOfe7xXdbG1yiW4d PxpkDHAX9ofYnbNVkjVM8CQYroht7Odrk5hecPb8rZtwZt9Lu6fPbxNWU 4=; X-IronPort-AV: E=Sophos;i="4.87,818,1363132800"; d="scan'208,217";a="82926751" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 07 Jun 2013 00:19:02 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r570J1WU006938; Fri, 7 Jun 2013 00:19:01 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Thu, 6 Jun 2013 17:19:01 -0700 Message-Id: References: To: John Mann X-Mailer: Apple Mail (2.1503) Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 00:19:07 -0000 --Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 6, 2013, at 5:02 PM, John Mann wrote: > Hi, >=20 > On 7 June 2013 08:41, Rajiv Asati (rajiva) wrote: > Hi Dan, >=20 > > and so on. I am surprised you conclude that "500 seems ok" when = such a > > limit would interfere with your network use on those days. >=20 > I based that statement ("...seems ok,") on the very fact that the = number of times the NAT utilization exceeded 500 mappings (equating to = 500 ports, in my setup) in the sample period (~2 months) was relatively = quite low. So, if the NAT device was limited to only 500 mappings, then = the experience would have been ok for 99% of the time and degraded 1% of = the time. This is an important consideration, IMO. >=20 > For ex, in the last 2 weeks, the number of times NAT mappings exceeded = 500 were: >=20 > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times >=20 > I think a more-interesting statistic would be "how many connection = setups would have failed". > But I don't think you can measure that just by polling concurrent = connections at specific times. > It might take e.g. netflow exporting and analysis ... >=20 > However "number of concurrent connections that couldn't have been = setup" would be useful in gauging the impact > e.g. on May 29 there was one spike of 734 concurrent connections, then = report that as 234 potential failures. >=20 > Of course, 1000 ports (resulting in 1000+ mappings) would have been = more than enough to accommodate the times when the mappings exceeded = 500, but stayed within 1000 (except once). >=20 >=20 > > What is the maximum number of mappings supported by your NAPT = device? > > Some residential-class NATs have a limit of 1024 mappings. >=20 > Is that a combined limit of TCP and UDP and ICMP, or independent? The study at http://eggert.org/papers/2010-imc-hgw-study.pdf only = analyzed TCP bindings. -d >=20 > My NAPT device seemingly can use upto 64K ports. :) >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: Dan Wing (dwing) > > Sent: Thursday, June 06, 2013 11:43 AM > > To: Rajiv Asati (rajiva) > > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > > behave@ietf.org; Erik Kline (ek@google.com) > > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: > > > > > Some of you may recall our discussion (during the last IETF) = around "how > > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into > > A+P paradigm. ~500, ~1000, ~3000??? > > > > > > Well, I started monitoring my home router and plotting the NAPT44 = port > > utilization on a minute-by-minute basis. You may find it here - > > http://www.employees.org/~rajiva > > > > > > In short, port range of 500 seems ok, though 1000 would be more = than > > enough for my home. > > > > I see several spikes in your data over 500 ports. During those = times, > > applications would be unable to function (unable to get a port). = April 29/30 > > is a long time where that occurs very visibly, but there are shorter = spikes > > elsewhere such as on April 17 and April 18. If you had only 500 = ports on > > those days, creating a new TCP mapping would have been impossible, > > impacting ability to send or receive email, order books from = Amazon.com, > > and so on. I am surprised you conclude that "500 seems ok" when = such a > > limit would interfere with your network use on those days. > > > > What is the maximum number of mappings supported by your NAPT = device? > > Some residential-class NATs have a limit of 1024 mappings. > > > > -d > > > > > Suffice to say, this is just a sample representation, since the = port > > utilization would vary home to home, based on number of active = devices, > > type of applications, the degree of simultaneous device or = application > > usage etc. > > > > > > If any of you are doing similar monitoring, then please share. > > > > > > Cheers, > > > Rajiv > > > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) = how to use > > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai = for > > helping me out significantly. > > > > > > PS: My home has 3-4 active devices. > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
    On Jun 6, 2013, at 5:02 PM, John Mann <john.mann@monash.edu> wrote:

    Hi,

    On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
    Hi Dan,

    > and so on.  I am surprised you conclude that "500 seems ok" when such a
    > limit would interfere with your network use on those days.

    I based that statement ("...seems ok,") on the very fact that the number of times the NAT utilization exceeded 500 mappings (equating to 500 ports, in my setup) in the sample period (~2 months) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok for 99% of the time and degraded 1% of the time. This is an important consideration, IMO.

    For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 were:

    June 3 - 1 time
    May 29 - 1 time
    May 28 - 3 times
    May 26 - 1 time
    May 23 - 1 time
    May 22 - 2 times
    May 21 - 3 times

    I think a more-interesting statistic would be "how many connection setups would have failed".
    But I don't think you can measure that just by polling concurrent connections at specific times.
    It might take e.g. netflow exporting and analysis ...

    However "number of concurrent connections that couldn't have been setup" would be useful in gauging the impact
    e.g. on May 29 there was one spike of 734 concurrent connections, then report that as 234 potential failures.

    Of course, 1000 ports (resulting in 1000+ mappings) would have been more than enough to accommodate the times when the mappings exceeded 500, but stayed within 1000 (except once).


    > What is the maximum number of mappings supported by your NAPT device?
    > Some residential-class NATs have a limit of 1024 mappings.

    Is that a combined limit of TCP and UDP and ICMP, or independent?

    The study at http://eggert.org/papers/2010-imc-hgw-study.pdf only analyzed TCP bindings.

    -d



    My NAPT device seemingly can use upto 64K ports. :)

    Cheers,
    Rajiv


    > -----Original Message-----
    > From: Dan Wing (dwing)
    > Sent: Thursday, June 06, 2013 11:43 AM
    > To: Rajiv Asati (rajiva)
    > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org);
    > behave@ietf.org; Erik Kline (ek@google.com)
    > Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
    >
    >
    > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
    >
    > > Some of you may recall our discussion (during the last IETF) around "how
    > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into
    > A+P paradigm. ~500, ~1000, ~3000???
    > >
    > > Well, I started monitoring my home router and plotting the NAPT44 port
    > utilization on a minute-by-minute basis. You may find it here -
    > http://www.employees.org/~rajiva
    > >
    > > In short, port range of 500 seems ok, though 1000 would be more than
    > enough for my home.
    >
    > I see several spikes in your data over 500 ports.  During those times,
    > applications would be unable to function (unable to get a port).  April 29/30
    > is a long time where that occurs very visibly, but there are shorter spikes
    > elsewhere such as on April 17 and April 18.  If you had only 500 ports on
    > those days, creating a new TCP mapping would have been impossible,
    > impacting ability to send or receive email, order books from Amazon.com,
    > and so on.  I am surprised you conclude that "500 seems ok" when such a
    > limit would interfere with your network use on those days.
    >
    > What is the maximum number of mappings supported by your NAPT device?
    > Some residential-class NATs have a limit of 1024 mappings.
    >
    > -d
    >
    > > Suffice to say, this is just a sample representation, since the port
    > utilization would vary home to home, based on number of active devices,
    > type of applications, the degree of simultaneous device or application
    > usage etc.
    > >
    > > If any of you are doing similar monitoring, then please share.
    > >
    > > Cheers,
    > > Rajiv
    > >
    > > PS: Thanks to Erik Kline, who explained (with sufficient details) how to use
    > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for
    > helping me out significantly.
    > >
    > > PS: My home has 3-4 active devices.
    > > _______________________________________________
    > > Behave mailing list
    > > Behave@ietf.org
    > > https://www.ietf.org/mailman/listinfo/behave

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


    --Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2-- From Ted.Lemon@nominum.com Thu Jun 6 18:27:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59BE21F93E1 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.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 kpJCFvJS6WMn for ; Thu, 6 Jun 2013 18:38:51 -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 DEDA321F93D4 for ; Thu, 6 Jun 2013 18:38:50 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n20so753174qaj.13 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=oe1aV53lSRydWQqXZgxemQjyQD8cpp08yaDPB9E9Mw9yl8bbqMo9B4LDWs2MOzRGE4 Ua6qGvWHwWllD0qc41jM6Mf4JXizPBye11FWyVl9hL4rGO8PBqYrMF3H7ZqRJWSmZMWH +otRsXcGudticvOjFvRBNuGEirXerh3wtyCmR7ubMhlyn3pGo9ZZYzACufvtuiLCici8 cZOJk8PqCrUWRMxjooXvlsRh02ys20NJKoMNsuya1hwUpdOgFKdv0v7T84hJqYBfWxiQ kE/F+eUuRm5RT3iH9+jtEH5SRyIqYo4+h72RivTppL2K01ePkjf5mkh2fOvC7XGOx+Ep YI3g== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2c6ce2472e804de867ed4 X-Gm-Message-State: ALoCoQnR9RrM83vZXElSgaIp0QyVMdxO/jX4AGlNHK54wKYrLWibJdSkytxNW1P1zM7nuGqe7bWkT5Fv6zTl7SgQvSpcJgVQHRxxR9XKQxWpv9GTvHDOQ/aMPK1Cd9YEMTL+3w89kXZcchv02AjRTd7iW8XpQ5BdZ0gjiXc6x6oS5wNEKTnI18MFUleDLdM/6CsnsB3eAkPJ Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Ted.Lemon@nominum.com Thu Jun 6 18:54:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 jmh@joelhalpern.com Thu Jun 6 19:05:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC05E21F9408 for ; Thu, 6 Jun 2013 19:05:09 -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 PPv46t8YRL9T for ; Thu, 6 Jun 2013 19:05:04 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7AD21F93F8 for ; Thu, 6 Jun 2013 19:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 26B73163D6F; Thu, 6 Jun 2013 19:05:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-247.clppva.east.verizon.net [70.106.135.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7E353163D6E; Thu, 6 Jun 2013 19:05:02 -0700 (PDT) Message-ID: <51B13FCB.60107@joelhalpern.com> Date: Thu, 06 Jun 2013 22:04:59 -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: Joe Touch References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> In-Reply-To: <51B10208.9060204@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 02:05:09 -0000 In a formal sense Joe, you are correct. There is no formal requirement in IPv6 for Layer 4 visibility to routers. And one can argue that firewalling should be done in specialized boxes. I tend to disagree, but that is not the point. Even without firewalls, there is a current, real world, operational need for almost all routes to be able to find layer 4 information. Operators depend upon effective ECMP (and at layer 2, LAG) operation. While I would like things to work better (for example, by putting the needed information into the flow label), current deployments can not depend upon such an unspecified and undeployed host behavior. As such, real world deployed routers depend upon being able to find L4 information. Some devices can chase all the header chains, so that requiring L4 be in the packet is sufficient. Many routers have limits on what they can chase. Claiming that the reasonable and effective limitations people have had to put in place are "wrong" and vendors should stop doing that, requires that there be an answer to the issue. Yours, Joel PS: This seems largely orthogonal to Ms. Elkins original topic. On 6/6/2013 5:41 PM, Joe Touch wrote: > > > On 6/6/2013 2:36 PM, Havard Eidnes wrote: >>>> And therein lies the problem. As pointed out by Nick Hilliard and >>>> myself, we *need* those stateless firewall functions, which may >>>> need to look up stuff way beyond the destination address. I don't >>>> find a discussion of whether such functions *should* be needed in >>>> a router or not all that relevant. >>> >>> Just as I don't find a discussion of how much the cost to implement >>> such functions makes the life of router venders more complex. >>> >>> If the kitchen is too hot... >> >> That's one vantage point. Another would be one which talks about >> ivory towers and losing touch with what is practically possible now. > > If it's possible, then there's no problem. > > What you're all suggesting here are ways to limit IPv6 to make it more > convenient for router vendors to implement various features that were > never part of the design (of either the Internet architecture nor of > IPv6 in specific). > > If you want to make sure that IP supports efficient router parsing of L4 > header information, IMO you can take that up when we design IPv7, but it > was never a requirement of IPv6. Assuming it now is - as you are all > discussing - impractical. > > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Thu Jun 6 19:41:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F354621F91B1 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: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 j-o1885M0WLF for ; Thu, 6 Jun 2013 19:41:10 -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 779FF21F91AB for ; Thu, 6 Jun 2013 19:41:05 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so640454qak.14 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=PFP8/P/weEIbuVJdwKd1iK6lrRwyD8VZQziAQUxkCIVtGJRs9Xz+JO3tXOyTYTkarq 3CJvH3Y54nO8ywuiUVRw0gz8ysxOG2J+R0P/MLFrZrSAIhydTmsZDM205nQFou5LpYEL YLNFlX+saaF4R7eijUc5VinOy1vurKdbLfe6dnp0E3rCVE1myh7rX0t1PZuYVw1AyTlc A0Fsuo/WnO0Guu18K+YQfZJdtlDONth7Lu8xZ3O0w0WF1lLhl5SEDyC65G+nBftveBrz /kymJ+AiftZtQZ+W4JKeNVPhSWlKnjcTSokMeo5d2hiwP5keEHLfnFw6RsbeA+xt+zG6 iKAA== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3074d9a470fdeb04de875c1c X-Gm-Message-State: ALoCoQk0kKPju7od5qu9lORzg1NXK2yS8yt21OJdqLVu5f7aWXp62H4eGiFy8HnGHM4Uw0dTxoXZbWctUAJglX+GSxM77WGtN79aMcJQwpB3+YRf6mypRJpRiLXb6KBKhI5nQ0chN3EOaefAIbpa1Mf0vlYW1HEhgjy8ApsaSrSqdOfHY/4XV31JOq0LCIILsSdsvt8XcbMt Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 02:41:11 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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: "Manfredi, Albert E" , "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 nalini.elkins@insidethestack.com Thu Jun 6 21:23:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E135E21F8ECB for ; Thu, 6 Jun 2013 21:23:16 -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 GuQL9CO5Pgfl for ; Thu, 6 Jun 2013 21:23:11 -0700 (PDT) Received: from nm1.access.bullet.mail.sp2.yahoo.com (nm1.access.bullet.mail.sp2.yahoo.com [98.139.44.128]) by ietfa.amsl.com (Postfix) with ESMTP id BE6BC21F8EC3 for ; Thu, 6 Jun 2013 21:23:11 -0700 (PDT) Received: from [98.139.44.107] by nm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 04:23:11 -0000 Received: from [98.139.44.72] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 04:23:11 -0000 Received: from [127.0.0.1] by omp1009.access.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 04:23:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 520728.74783.bm@omp1009.access.mail.sp2.yahoo.com Received: (qmail 31609 invoked by uid 60001); 7 Jun 2013 04:23:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370578991; bh=nnkFMteFICGtM4krURmXJAOLRZwc6TIi+O7XdM5OgqQ=; 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=rCJH3shy/xjT+kRYOjBf1H+yGM0+wVRRTRqI9Ak5b6pyOzk11TLh8NQTSZMZ38IvcUw8r7p5ZYtD3J5efont1Fn4YXJI3QUwpLJAojON4vG22e6LlDI1TiknKyh+nv1rdcZpmE3k8lhI8HDdxOjx5Qx5uF21DhWOnIxoMVCdsE0= X-YMail-OSG: 30fOK0MVM1kBUgNdsvKffkw0sR5Oq0Fcr7Y9z_MHV5mUakL 4T1_G8..2NZaLNl8ASXonPgkLQNdg3Sk0ucDxA2nBWGVp3YSLV9gOa6zwUjs VfXq3Cee8.zrqjzyxEHfSrgbpHQZU5RcgVZeFGVmF2eZg1xvGCbfawiTanF4 dSZQSeHxuVZ9ynlWJl6vUNwbQbtr47yhH108iTpxj9jwixpdF0pqwDOdhd37 PnC40xxDNEW7wKMtgrc01jyxMxzNuWPnxGLfMJ0P8JHYVe9aqmIohtx4KJ65 INBkFdbwpsqe.jeZ6AJ4NLyFzPqkmOJAMBn5dVjp.PdbNU.gSJnOqg1PnTGr WBUP3zLtr05RjrDI2TJXo92WVsj8Gb8Bg3j6IqHWDwjBCm22_Qf6yxltlzL4 3NrchDxfES.Vtg9eWN4aSbcUtQiqmPznmntDsiojsdgJe16Cus3v8D04mW16 2BbsWiCFYdHNl7NkkafrZxm2AkKtbM_L.JbumaorcDZbrdVgTyNFS8tKMJE1 iBcYoDra3Mi1acW8JFyyyCItBGm097TBIkmgOVb_rfU7KYHVmTGYFn7kDmaO POJkpeTAJyqy5YpysWVfaXpJ0j54TYpkj00YPOj1tMfWNZF6bS.rlFHtZL13 z3Mo9yxCEw32OL7rnwKwcQRHLcck0 Received: from [50.131.220.245] by web2803.biz.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 21:23:11 PDT X-Rocket-MIMEInfo: 002.001, U3BlYWtpbmcgb2YgTXMuIEVsa2lucyBvcmlnaW5hbCB0b3BpYywgc29tZSBvZiB1cyBpbiB0aGUgcmVhbCB3b3JsZCBoYXZlIHVzZWQgdGhlIG9sZCBJUElEIGZpZWxkIGluIElQdjQgYXMgYSBwYWNrZXQgc2VxdWVuY2UgbnVtYmVyIHRvIGRvIGRpYWdub3N0aWNzIG1vcmUgcXVpY2tseSBldmVuIHRob3VnaCBpdCB3YXMgbm90IGludGVuZGVkIGFzIHN1Y2guIMKgIEluIHRoZSByZWFsIHdvcmxkLCB5b3UgZG8gd2hhdCB5b3UgaGF2ZSB0byB0byBrZWVwIHlvdXIgbmV0d29yayBydW5uaW5nIGFuZCBzb2x2ZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> Message-ID: <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Thu, 6 Jun 2013 21:23:11 -0700 (PDT) From: Nalini Elkins To: "Joel M. Halpern" , Joe Touch In-Reply-To: <51B13FCB.60107@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 04:23:17 -0000 Speaking of Ms. Elkins original topic, some of us in the real world have us= ed the old IPID field in IPv4 as a packet sequence number to do diagnostics= more quickly even though it was not intended as such. =A0 In the real worl= d, you do what you have to to keep your network running and solve problems.= =A0Theory goes out the window when real users are involved.=0A=0AThis is w= hy we want the new implementation of the destination options header that we= have defined. =A0=A0=0A=0AIf I might, I seem to sense that some of the peo= ple on this list possibly may not really understand or may not have much sy= mpathy for the kind of pressure we are under to solve problems quickly and = to meet service level requirements for performance. =A0If you can think of = the type of networks our team runs - the health care networks, the banking = sector, the stock markets, you can see that we diagnosticians have a lot of= pressure on us.=0A=0AI understand that there are a number of issues with I= Pv6 extension headers, no real RFCs for middle boxes, and the ASIC issue. = =A0And, tomorrow (or Saturday) when I can get away from actual work, I will= respond on the very good discussion on the 6man list on=A0draft-ietf-6man-= ext-transmit-01.txt. =A0 Definitely, these are very critical points. =A0And= , if we can help in any way to help in creating standards to address these = issues, we stand ready and willing to help in any way possible. =A0I feel s= ure that these problems will be solved in the future.=0A=0AWe would really = appreciate support for what we are asking for which is a way for us to solv= e our chronic operational problems which we are afraid will get worse with = IPv6.=0A=0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8= 360=0Awww.insidethestack.com=0A=0A=0A=0A________________________________=0A= From: Joel M. Halpern =0ATo: Joe Touch = =0ACc: v6ops@ietf.org =0ASent: Thursday, June 6, 2013 7:04 PM=0ASubject: R= e: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A=0A=0A= In a formal sense Joe, you are correct.=A0 There is no formal requirement i= n IPv6 for Layer 4 visibility to routers.=0A=0AAnd one can argue that firew= alling should be done in specialized boxes.=A0 I tend to disagree, but that= is not the point.=0A=0AEven without firewalls, there is a current, real wo= rld, operational need for almost all routes to be able to find layer 4 info= rmation.=A0 Operators depend upon effective ECMP (and at layer 2, LAG) oper= ation.=0A=0AWhile I would like things to work better (for example, by putti= ng the needed information into the flow label), current deployments can not= depend upon such an unspecified and undeployed host behavior.=0A=0AAs such= , real world deployed routers depend upon being able to find L4 information= .=A0 Some devices can chase all the header chains, so that requiring L4 be = in the packet is sufficient.=A0 Many routers have limits on what they can c= hase.=0A=0AClaiming that the reasonable and effective limitations people ha= ve had to put in place are "wrong" and vendors should stop doing that, requ= ires that there be an answer to the issue.=0A=0AYours,=0AJoel=0A=0APS: This= seems largely orthogonal to Ms. Elkins original topic.=0A=0AOn 6/6/2013 5:= 41 PM, Joe Touch wrote:=0A> =0A> =0A> On 6/6/2013 2:36 PM, Havard Eidnes wr= ote:=0A>>>> And therein lies the problem. As pointed out by Nick Hilliard a= nd=0A>>>> myself, we *need* those stateless firewall functions, which may= =0A>>>> need to look up stuff way beyond the destination address. I don't= =0A>>>> find a discussion of whether such functions *should* be needed in= =0A>>>> a router or not all that relevant.=0A>>> =0A>>> Just as I don't fin= d a discussion of how much the cost to implement=0A>>> such functions makes= the life of router venders more complex.=0A>>> =0A>>> If the kitchen is to= o hot...=0A>> =0A>> That's one vantage point.=A0 Another would be one which= talks about=0A>> ivory towers and losing touch with what is practically po= ssible now.=0A> =0A> If it's possible, then there's no problem.=0A> =0A> Wh= at you're all suggesting here are ways to limit IPv6 to make it more=0A> co= nvenient for router vendors to implement various features that were=0A> nev= er part of the design (of either the Internet architecture nor of=0A> IPv6 = in specific).=0A> =0A> If you want to make sure that IP supports efficient = router parsing of L4=0A> header information, IMO you can take that up when = we design IPv7, but it=0A> was never a requirement of IPv6. Assuming it now= is - as you are all=0A> discussing - impractical.=0A> =0A> Joe=0A> _______= ________________________________________=0A> v6ops mailing list=0A> v6ops@i= etf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> =0A____________= ___________________________________=0Av6ops mailing list=0Av6ops@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/v6ops From jcurran@istaff.org Thu Jun 6 21:57:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 lorenzo@google.com Thu Jun 6 22:59:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61DD21F8FEB for ; Thu, 6 Jun 2013 22:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 lmpOCcTLrDM4 for ; Thu, 6 Jun 2013 22:59:19 -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 4DB0A21F8FA3 for ; Thu, 6 Jun 2013 22:59:19 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id f11so841968qae.17 for ; Thu, 06 Jun 2013 22:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8xPyDxzVQ6ZqQbgk8A2ECUtScWBsntI4P3AKrYvF7Hc=; b=nCOvc/gzguEDk4h3LcFuwUnlb/ofhpF0Ujh5m/yeIOmoUrr0YZEd0F+Eqs3gaVAbfP bVAjDS+IYWmpvQpYje1FG3B/nqvwZ2AT7IEzwPb7fuLoct9pmcnnr0gAhyV09mBgFzab /DFUd0XkwuJxwNl0tnQ1e2/dfbxsfUmHqhAzLyQG+WpIK/atKDb3l+6rWSjdpOGjwKbj HlFKjq893w9pXLlAd3db8k7k3fjE+FmV5p5G7ORYYiFlspLS6ozxGXY9BK3M29ltrYWN WbYFBruGghfGuwKxw4+jKVDj2sbLxBte939ieXhwhkZ8vGrOwFgrqJdFXw4RnBiitH08 xvBw== 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=8xPyDxzVQ6ZqQbgk8A2ECUtScWBsntI4P3AKrYvF7Hc=; b=VVQJILJmKu4G4ZolRRCEu0asssQSlThRzE8uNEPQxMb2i6klGysvf7prw7X/+biYPK 15nktcfJJn82Ot8j0YieNjnA7RI7NjsIimzmqcxvlw6CrKx7UfwvqE/fYwrVDee64bW6 fwJFrbD4Yp2kQ+MmgVhoGB5Y5yk6IpVtYacoU8awdICmDgmSTzvaL2zarh5Mcpe7N7J6 2rxom1Gd7mVnCPOB5cQY4fKV5Kn0/HIjBcy34mGJz36Q9KtEw+cdrJaiyl9kFdziKbnY DNhjvYGNAbOkHzohwaqvzt6Xad+r+JZekRywE64+Npxkvl0mVSB6SjeAYug4GeZwDx7k fJ0A== X-Received: by 10.229.71.134 with SMTP id h6mr1702073qcj.131.1370584758547; Thu, 06 Jun 2013 22:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 22:58:57 -0700 (PDT) In-Reply-To: <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> From: Lorenzo Colitti Date: Fri, 7 Jun 2013 14:58:57 +0900 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=089e01628446ab1fb704de8a21da X-Gm-Message-State: ALoCoQmOnBTHQBkt9kwSkPu3Zq6+Ndt2CIj3/ulGP7TWR1AqjXDToyBKLlZyqqYtRQS9Dnin/0CeSWYmnfdwlI15Xprz1+rtaKo2A2HrfzpeHV2c3TJS/3bGYHcdHLNWIxGbXFj2OgNBV/ENiik9tO0DXEzM8Zr3egFRXriLBCPRp8jrsZFzKdPd6EOImaLElugDF4N05Z+5 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 05:59:20 -0000 --089e01628446ab1fb704de8a21da Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 1:23 PM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > If I might, I seem to sense that some of the people on this list possibly > may not really understand or may not have much sympathy for the kind of > pressure we are under to solve problems quickly and to meet service level > requirements for performance. If you can think of the type of networks our > team runs - the health care networks, the banking sector, the stock > markets, you can see that we diagnosticians have a lot of pressure on us. > Agreed. But all those networks are highly specialized, highly closed, and highly integrated, and the solutions that are appropriate for them might not be appropriate for the general Internet. Also, if you want to solve this problem quickly, then... well, an extension header is not a good idea, because it has to be implemented at the lowest level possible (the host operating system). If you need a quick solution, then what you want is the sequence number field in the GRE header. --089e01628446ab1fb704de8a21da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Fri, Jun 7, 2013 at 1:23 PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
    If I might, I see= m to sense that some of the people on this list possibly may not really und= erstand or may not have much sympathy for the kind of pressure we are under= to solve problems quickly and to meet service level requirements for perfo= rmance. =A0If you can think of the type of networks our team runs - the hea= lth care networks, the banking sector, the stock markets, you can see that = we diagnosticians have a lot of pressure on us.

    Agreed. But all those networks are h= ighly specialized, highly closed, and highly integrated, and the solutions = that are appropriate for them might not be appropriate for the general Inte= rnet.

    Also, if you want to solve this problem qui= ckly, then... well, an extension header is not a good idea, because it has = to be implemented at the lowest level possible (the host operating system).= If you need a quick solution, then what you want is the sequence number fi= eld in the GRE header.
    --089e01628446ab1fb704de8a21da-- From richih.mailinglist@gmail.com Thu Jun 6 23:03:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 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 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 v6ops@globis.net Thu Jun 6 23:42:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C5F21F885A for ; Thu, 6 Jun 2013 23:42:18 -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 i4rJ6SojQiJ6 for ; Thu, 6 Jun 2013 23:42: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 ABBFB21F85EF for ; Thu, 6 Jun 2013 23:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8A9608700E3; Fri, 7 Jun 2013 08:42:01 +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 G1pyuufAIkQH; Fri, 7 Jun 2013 08:42:01 +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 58E078700DF; Fri, 7 Jun 2013 08:42:01 +0200 (CEST) Message-ID: <51B180B3.2090106@globis.net> Date: Fri, 07 Jun 2013 08:41:55 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Joe Touch References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> In-Reply-To: <51B10208.9060204@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:42:18 -0000 Joe Touch wrote: > > > On 6/6/2013 2:36 PM, Havard Eidnes wrote: >>>> And therein lies the problem. As pointed out by Nick Hilliard and >>>> myself, we *need* those stateless firewall functions, which may >>>> need to look up stuff way beyond the destination address. I don't >>>> find a discussion of whether such functions *should* be needed in >>>> a router or not all that relevant. >>> >>> Just as I don't find a discussion of how much the cost to implement >>> such functions makes the life of router venders more complex. >>> >>> If the kitchen is too hot... >> >> That's one vantage point. Another would be one which talks about >> ivory towers and losing touch with what is practically possible now. > > If it's possible, then there's no problem. > > What you're all suggesting here are ways to limit IPv6 to make it more > convenient for router vendors to implement various features that were > never part of the design (of either the Internet architecture nor of > IPv6 in specific). > > If you want to make sure that IP supports efficient router parsing of > L4 header information, IMO you can take that up when we design IPv7, > but it was never a requirement of IPv6. Assuming it now is - as you > are all discussing - impractical. > > Joe > Why do you think it's impractical to make IPv6 more convenient for middle-box and router vendors to parse without going back to the drawing board? What if there were a bunch of informational RFC's that said "if you want your packet switched on the fast past in hardware make sure it ..... blah" Where blah is something like: has (a maximum of) n MPLS labels in the the stack has (a maximum of) n QinQ tags ..... the hop by hop header may or may not be present, but if present it should always contain exactly these TLV hop-by-hop options in exactly this transmission order. Wouldn't that ensure that it's in everyones' best interests to adhere to these informational RFCs, without having to completely redo standards track RFCs? (Other packets confirming to standard track RFCs should still be properly switched, but on a slightly slower, or very much slower path) At the moment, "blah" would seem to be "make sure your packet does not contain any extension headers, or else it will likely be dropped" and we've currently got the wrong optimization of flexibility and length efficiency versus switching speed. best regards, RayH From he@uninett.no Fri Jun 7 00:06:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF4E21F9420 for ; Fri, 7 Jun 2013 00: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=[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 Akk21skbXbFL for ; Fri, 7 Jun 2013 00:06:28 -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 7734321F92E3 for ; Fri, 7 Jun 2013 00:06:26 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 856A13D0B3; Fri, 7 Jun 2013 09:06:24 +0200 (CEST) Date: Fri, 07 Jun 2013 09:06:24 +0200 (CEST) Message-Id: <20130607.090624.19791724.he@uninett.no> To: v6ops@globis.net From: Havard Eidnes In-Reply-To: <51B180B3.2090106@globis.net> References: <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B180B3.2090106@globis.net> 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 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:06:33 -0000 > What if there were a bunch of informational RFC's that said "if > you want your packet switched on the fast past in hardware make > sure it ..... blah" That way of implementing things has issues. I"m explaining below. > (Other packets confirming to standard track RFCs should still > be properly switched, but on a slightly slower, or very much > slower path) If one isn't very careful when implementing such a scheme, it is easy to create a DoS vector. For some reason that's not very popular in certain circles (imagine that!). Regards, - H=E5vard From v6ops@globis.net Fri Jun 7 00:25:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9C021F9402 for ; Fri, 7 Jun 2013 00:25:12 -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 3WmzJAFeMJTC for ; Fri, 7 Jun 2013 00:25: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 D35D921F93F8 for ; Fri, 7 Jun 2013 00:25:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 136678700E3; Fri, 7 Jun 2013 09:24: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 VWgIVsMt-m4N; Fri, 7 Jun 2013 09:24:55 +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 7EB8E8700D7; Fri, 7 Jun 2013 09:24:55 +0200 (CEST) Message-ID: <51B18AC1.5070403@globis.net> Date: Fri, 07 Jun 2013 09:24:49 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Havard Eidnes References: <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B180B3.2090106@globis.net> <20130607.090624.19791724.he@uninett.no> In-Reply-To: <20130607.090624.19791724.he@uninett.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:25:12 -0000 > Havard Eidnes > 7 June 2013 09:06 >> What if there were a bunch of informational RFC's that said "if >> you want your packet switched on the fast past in hardware make >> sure it ..... blah" > > That way of implementing things has issues. I"m explaining below. > >> (Other packets confirming to standard track RFCs should still >> be properly switched, but on a slightly slower, or very much >> slower path) > > If one isn't very careful when implementing such a scheme, it is > easy to create a DoS vector. For some reason that's not very > popular in certain circles (imagine that!). > > Regards, > > - Håvard > So those operators with DoS concerns will continue to ignore the IETF standards and drop soft-switched packets that don't conform to the informational RFC for a strict-structured hop-by-hop header optimized for hardware forwarding. How's that worse than today, where people are apparently dropping all packets containing any extension headers (because they're all soft switched)? The basic idea being that we can optimize/facilitate hardware parsing further and further along the header chain by publishing additional informational RFCs, and at some point in the future we'll get enough extension headers supported together with hardware forwarding that they become useful. I'd certainly like to be able to buy a firewall with ASIC optimized forwarding of IPv6 (including extension headers). The alternative would seem to be a stalemate of continual shouting from the ivory tower that hardware vendors just need to learn to live with arbitrary packet complexity, whilst operational people drop everything containing an extension header so there's no market demand for the hardware vendors to do anything. regards, RayH From Branimir.Rajtar@t.ht.hr Fri Jun 7 00:31:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35E921F9619; Fri, 7 Jun 2013 00:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 FJ-9C7XsGGY0; Fri, 7 Jun 2013 00:31:36 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id EBB9A21F944C; Fri, 7 Jun 2013 00:31:34 -0700 (PDT) Received: from no.name.available by mx01.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Fri, 7 Jun 2013 08:59:25 +0200 Received: from (unknown [172.17.66.76]) by scmg1.t.ht.hr with smtp id 5a79_411d_46d8ffac_cf44_11e2_850b_00221951415f; Fri, 07 Jun 2013 09:31:32 +0200 Received: (private information removed) Fri, 7 Jun 2013 09:31:32 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Fri, 7 Jun 2013 09:31:32 +0200 From: Branimir Rajtar To: Dan Wing , John Mann Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOYxSmFlmur/cKQ0iajTdwC2BYP5kp2xNQ Date: Fri, 7 Jun 2013 07:31:32 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01464D5F@S2010EXCH1.ad.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.14] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2013 07:31:32.0737 (UTC) FILETIME=[088E5710:01CE6351] Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:31:42 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGkgYWxsLAoKSSd2ZSBiZWVuIHdvcmtpbmcgcXVpdGUgc29tZSB0aW1lIHdpdGggSG9tZSBHYXRl d2F5cyBhbmQgaW4gbXkgZXhwZXJpZW5jZSB0aGUgb2xkZXIgbW9kZWxzICgzKyB5ZWFycykgdHlw aWNhbGx5IHN1cHBvcnQgMTAwMC0yMDAwIHNpbXVsdGFuZW91cyBzZXNzaW9ucywgd2hpbGUgdGhl IG5ld2VyIG9uZXMgZ28gdXAgdG8gNDAwMCwgc29tZSBldmVuIHVwIHRvIDkwMDAuCgpCcmFuaW1p cgoKRnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbiBXaW5nClNlbnQ6IEZyaWRheSwgSnVuZSAwNywgMjAx MyAyOjE5IEFNClRvOiBKb2huIE1hbm4KQ2M6IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0d2lyZXNA aWV0Zi5vcmcpOyB2Nm9wc0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBSYWppdiBBc2F0aSAo cmFqaXZhKQpTdWJqZWN0OiBSZTogW0JFSEFWRV0gW3Y2b3BzXSBIb21lIE5BUFQ0NCAtIEhvdyBt YW55IHBvcnRzPwoKCk9uIEp1biA2LCAyMDEzLCBhdCA1OjAyIFBNLCBKb2huIE1hbm4gPGpvaG4u bWFubkBtb25hc2guZWR1PG1haWx0bzpqb2huLm1hbm5AbW9uYXNoLmVkdT4+IHdyb3RlOgoKCkhp LAoKT24gNyBKdW5lIDIwMTMgMDg6NDEsIFJhaml2IEFzYXRpIChyYWppdmEpIDxyYWppdmFAY2lz Y28uY29tPG1haWx0bzpyYWppdmFAY2lzY28uY29tPj4gd3JvdGU6CkhpIERhbiwKCj4gYW5kIHNv IG9uLiAgSSBhbSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgIjUwMCBzZWVtcyBvayIgd2hl biBzdWNoIGEKPiBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdvcmsgdXNlIG9u IHRob3NlIGRheXMuCkkgYmFzZWQgdGhhdCBzdGF0ZW1lbnQgKCIuLi5zZWVtcyBvaywiKSBvbiB0 aGUgdmVyeSBmYWN0IHRoYXQgdGhlIG51bWJlciBvZiB0aW1lcyB0aGUgTkFUIHV0aWxpemF0aW9u IGV4Y2VlZGVkIDUwMCBtYXBwaW5ncyAoZXF1YXRpbmcgdG8gNTAwIHBvcnRzLCBpbiBteSBzZXR1 cCkgaW4gdGhlIHNhbXBsZSBwZXJpb2QgKH4yIG1vbnRocykgd2FzIHJlbGF0aXZlbHkgcXVpdGUg bG93LiBTbywgaWYgdGhlIE5BVCBkZXZpY2Ugd2FzIGxpbWl0ZWQgdG8gb25seSA1MDAgbWFwcGlu Z3MsIHRoZW4gdGhlIGV4cGVyaWVuY2Ugd291bGQgaGF2ZSBiZWVuIG9rIGZvciA5OSUgb2YgdGhl IHRpbWUgYW5kIGRlZ3JhZGVkIDElIG9mIHRoZSB0aW1lLiBUaGlzIGlzIGFuIGltcG9ydGFudCBj b25zaWRlcmF0aW9uLCBJTU8uCgpGb3IgZXgsIGluIHRoZSBsYXN0IDIgd2Vla3MsIHRoZSBudW1i ZXIgb2YgdGltZXMgTkFUIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCB3ZXJlOgoKSnVuZSAzIC0gMSB0 aW1lCk1heSAyOSAtIDEgdGltZQpNYXkgMjggLSAzIHRpbWVzCk1heSAyNiAtIDEgdGltZQpNYXkg MjMgLSAxIHRpbWUKTWF5IDIyIC0gMiB0aW1lcwpNYXkgMjEgLSAzIHRpbWVzCgpJIHRoaW5rIGEg bW9yZS1pbnRlcmVzdGluZyBzdGF0aXN0aWMgd291bGQgYmUgImhvdyBtYW55IGNvbm5lY3Rpb24g c2V0dXBzIHdvdWxkIGhhdmUgZmFpbGVkIi4KQnV0IEkgZG9uJ3QgdGhpbmsgeW91IGNhbiBtZWFz dXJlIHRoYXQganVzdCBieSBwb2xsaW5nIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMgYXQgc3BlY2lm aWMgdGltZXMuCkl0IG1pZ2h0IHRha2UgZS5nLiBuZXRmbG93IGV4cG9ydGluZyBhbmQgYW5hbHlz aXMgLi4uCgpIb3dldmVyICJudW1iZXIgb2YgY29uY3VycmVudCBjb25uZWN0aW9ucyB0aGF0IGNv dWxkbid0IGhhdmUgYmVlbiBzZXR1cCIgd291bGQgYmUgdXNlZnVsIGluIGdhdWdpbmcgdGhlIGlt cGFjdAplLmcuIG9uIE1heSAyOSB0aGVyZSB3YXMgb25lIHNwaWtlIG9mIDczNCBjb25jdXJyZW50 IGNvbm5lY3Rpb25zLCB0aGVuIHJlcG9ydCB0aGF0IGFzIDIzNCBwb3RlbnRpYWwgZmFpbHVyZXMu CgpPZiBjb3Vyc2UsIDEwMDAgcG9ydHMgKHJlc3VsdGluZyBpbiAxMDAwKyBtYXBwaW5ncykgd291 bGQgaGF2ZSBiZWVuIG1vcmUgdGhhbiBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHRpbWVzIHdo ZW4gdGhlIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCwgYnV0IHN0YXllZCB3aXRoaW4gMTAwMCAoZXhj ZXB0IG9uY2UpLgoKCj4gV2hhdCBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgbWFwcGluZ3Mgc3Vw cG9ydGVkIGJ5IHlvdXIgTkFQVCBkZXZpY2U/Cj4gU29tZSByZXNpZGVudGlhbC1jbGFzcyBOQVRz IGhhdmUgYSBsaW1pdCBvZiAxMDI0IG1hcHBpbmdzLgoKSXMgdGhhdCBhIGNvbWJpbmVkIGxpbWl0 IG9mIFRDUCBhbmQgVURQIGFuZCBJQ01QLCBvciBpbmRlcGVuZGVudD8KClRoZSBzdHVkeSBhdCBo dHRwOi8vZWdnZXJ0Lm9yZy9wYXBlcnMvMjAxMC1pbWMtaGd3LXN0dWR5LnBkZiBvbmx5IGFuYWx5 emVkIFRDUCBiaW5kaW5ncy4KCi1kCgoKCgpNeSBOQVBUIGRldmljZSBzZWVtaW5nbHkgY2FuIHVz ZSB1cHRvIDY0SyBwb3J0cy4gOikKCkNoZWVycywKUmFqaXYKCgo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tCj4gRnJvbTogRGFuIFdpbmcgKGR3aW5nKQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5l IDA2LCAyMDEzIDExOjQzIEFNCj4gVG86IFJhaml2IEFzYXRpIChyYWppdmEpCj4gQ2M6IHY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz47IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0 d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZz4pOwo+IGJlaGF2ZUBpZXRm Lm9yZzxtYWlsdG86YmVoYXZlQGlldGYub3JnPjsgRXJpayBLbGluZSAoZWtAZ29vZ2xlLmNvbTxt YWlsdG86ZWtAZ29vZ2xlLmNvbT4pCj4gU3ViamVjdDogUmU6IFtCRUhBVkVdIEhvbWUgTkFQVDQ0 IC0gSG93IG1hbnkgcG9ydHM/Cj4KPgo+IE9uIEp1biA1LCAyMDEzLCBhdCA2OjE0IEFNLCBSYWpp diBBc2F0aSAocmFqaXZhKSA8cmFqaXZhQGNpc2NvLmNvbTxtYWlsdG86cmFqaXZhQGNpc2NvLmNv bT4+IHdyb3RlOgo+Cj4gPiBTb21lIG9mIHlvdSBtYXkgcmVjYWxsIG91ciBkaXNjdXNzaW9uIChk dXJpbmcgdGhlIGxhc3QgSUVURikgYXJvdW5kICJob3cKPiBtYW55IFRDUC9VRFAgcG9ydHMgYXJl IGVub3VnaCB3aXRoIE5BUFQ0NCIgcGVyIGhvbWUsIGFzIElTUHMgbW92ZSBpbnRvCj4gQStQIHBh cmFkaWdtLiB+NTAwLCB+MTAwMCwgfjMwMDA/Pz8KPiA+Cj4gPiBXZWxsLCBJIHN0YXJ0ZWQgbW9u aXRvcmluZyBteSBob21lIHJvdXRlciBhbmQgcGxvdHRpbmcgdGhlIE5BUFQ0NCBwb3J0Cj4gdXRp bGl6YXRpb24gb24gYSBtaW51dGUtYnktbWludXRlIGJhc2lzLiBZb3UgbWF5IGZpbmQgaXQgaGVy ZSAtCj4gaHR0cDovL3d3dy5lbXBsb3llZXMub3JnL35yYWppdmEKPiA+Cj4gPiBJbiBzaG9ydCwg cG9ydCByYW5nZSBvZiA1MDAgc2VlbXMgb2ssIHRob3VnaCAxMDAwIHdvdWxkIGJlIG1vcmUgdGhh bgo+IGVub3VnaCBmb3IgbXkgaG9tZS4KPgo+IEkgc2VlIHNldmVyYWwgc3Bpa2VzIGluIHlvdXIg ZGF0YSBvdmVyIDUwMCBwb3J0cy4gIER1cmluZyB0aG9zZSB0aW1lcywKPiBhcHBsaWNhdGlvbnMg d291bGQgYmUgdW5hYmxlIHRvIGZ1bmN0aW9uICh1bmFibGUgdG8gZ2V0IGEgcG9ydCkuICBBcHJp bCAyOS8zMAo+IGlzIGEgbG9uZyB0aW1lIHdoZXJlIHRoYXQgb2NjdXJzIHZlcnkgdmlzaWJseSwg YnV0IHRoZXJlIGFyZSBzaG9ydGVyIHNwaWtlcwo+IGVsc2V3aGVyZSBzdWNoIGFzIG9uIEFwcmls IDE3IGFuZCBBcHJpbCAxOC4gIElmIHlvdSBoYWQgb25seSA1MDAgcG9ydHMgb24KPiB0aG9zZSBk YXlzLCBjcmVhdGluZyBhIG5ldyBUQ1AgbWFwcGluZyB3b3VsZCBoYXZlIGJlZW4gaW1wb3NzaWJs ZSwKPiBpbXBhY3RpbmcgYWJpbGl0eSB0byBzZW5kIG9yIHJlY2VpdmUgZW1haWwsIG9yZGVyIGJv b2tzIGZyb20gQW1hem9uLmNvbTxodHRwOi8vQW1hem9uLmNvbT4sCj4gYW5kIHNvIG9uLiAgSSBh bSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgIjUwMCBzZWVtcyBvayIgd2hlbiBzdWNoIGEK PiBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdvcmsgdXNlIG9uIHRob3NlIGRh eXMuCj4KPiBXaGF0IGlzIHRoZSBtYXhpbXVtIG51bWJlciBvZiBtYXBwaW5ncyBzdXBwb3J0ZWQg YnkgeW91ciBOQVBUIGRldmljZT8KPiBTb21lIHJlc2lkZW50aWFsLWNsYXNzIE5BVHMgaGF2ZSBh IGxpbWl0IG9mIDEwMjQgbWFwcGluZ3MuCj4KPiAtZAo+Cj4gPiBTdWZmaWNlIHRvIHNheSwgdGhp cyBpcyBqdXN0IGEgc2FtcGxlIHJlcHJlc2VudGF0aW9uLCBzaW5jZSB0aGUgcG9ydAo+IHV0aWxp emF0aW9uIHdvdWxkIHZhcnkgaG9tZSB0byBob21lLCBiYXNlZCBvbiBudW1iZXIgb2YgYWN0aXZl IGRldmljZXMsCj4gdHlwZSBvZiBhcHBsaWNhdGlvbnMsIHRoZSBkZWdyZWUgb2Ygc2ltdWx0YW5l b3VzIGRldmljZSBvciBhcHBsaWNhdGlvbgo+IHVzYWdlIGV0Yy4KPiA+Cj4gPiBJZiBhbnkgb2Yg eW91IGFyZSBkb2luZyBzaW1pbGFyIG1vbml0b3JpbmcsIHRoZW4gcGxlYXNlIHNoYXJlLgo+ID4K PiA+IENoZWVycywKPiA+IFJhaml2Cj4gPgo+ID4gUFM6IFRoYW5rcyB0byBFcmlrIEtsaW5lLCB3 aG8gZXhwbGFpbmVkICh3aXRoIHN1ZmZpY2llbnQgZGV0YWlscykgaG93IHRvIHVzZQo+IGdvb2ds ZSBjaGFydGluZyBmb3IgbXkgZGF0YS4gQW5kIHRoYW5rcyB0byBYdW4gV2FuZyAmIFNoYW9zaHVh aSBEYWkgZm9yCj4gaGVscGluZyBtZSBvdXQgc2lnbmlmaWNhbnRseS4KPiA+Cj4gPiBQUzogTXkg aG9tZSBoYXMgMy00IGFjdGl2ZSBkZXZpY2VzLgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiA+IEJlaGF2ZSBtYWlsaW5nIGxpc3QKPiA+IEJlaGF2 ZUBpZXRmLm9yZzxtYWlsdG86QmVoYXZlQGlldGYub3JnPgo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCnY2b3BzIG1haWxpbmcgbGlzdAp2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMKCgoKCjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+ DQoNCklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92ZSBwb3J1a2Ug aSBldmVudHVhbG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYgaSBuYW1pamVu amVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVkZW5pIHUgYWRy ZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1vbGltbyBWYXMs IG9iYXZpamVzdGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVuZSBwcml2aXRr ZSBvZG1haCwgYmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5hbGEuIEJpbG8g a2Frdm8gcHJlbm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGluZm9ybWFjaWph IHNhZHLFvmFuaWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtb8W+ ZSBiaXRpIHpha29uc2tpIGthxb5uaml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBtacWhbGplbmph IGl6bmVzZW5pIHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudcW+bm8g c3Rhdm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQgbmUgcHJpaHZh xIdhIG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFzdGFsdSBwcmlt aXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4NCg0KPC9GT05U PjwvUD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQogRElTQ0xB SU1FUjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBhdHRh Y2hlZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGluZGl2 aWR1YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0dGFj aGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBk aXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVy ZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5l Y2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFuIFRl bGVjb20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9y IGFueSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVzIGF0 dGFjaGVkIHRvIGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4KPGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ CjxzdHlsZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOwoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBmb250 LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6VGFob21hOwoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLwpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBjbTsKCW1hcmdpbi1ib3R0b206LjAwMDFw dDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsK CWNvbG9yOmJsdWU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6cHVy cGxlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CnNwYW4uRW1haWxTdHlsZTE3Cgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOwoJY29sb3I6IzFGNDk3RDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7Cglmb250LXNpemU6MTAuMHB0O30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4KPGJvZHkgbGFu Zz0iSFIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2UiPgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkndmUgYmVlbiB3 b3JraW5nIHF1aXRlIHNvbWUgdGltZSB3aXRoIEhvbWUgR2F0ZXdheXMgYW5kIGluIG15IGV4cGVy aWVuY2UgdGhlIG9sZGVyIG1vZGVscyAoMyYjNDM7IHllYXJzKSB0eXBpY2FsbHkgc3VwcG9ydCAx MDAwLTIwMDAgc2ltdWx0YW5lb3VzCiBzZXNzaW9ucywgd2hpbGUgdGhlIG5ld2VyIG9uZXMgZ28g dXAgdG8gNDAwMCwgc29tZSBldmVuIHVwIHRvIDkwMDAuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QnJhbmltaXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4KPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2Vz QGlldGYub3JnXQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbiBXaW5nPGJyPgo8Yj5TZW50OjwvYj4g RnJpZGF5LCBKdW5lIDA3LCAyMDEzIDI6MTkgQU08YnI+CjxiPlRvOjwvYj4gSm9obiBNYW5uPGJy Pgo8Yj5DYzo8L2I+IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0d2lyZXNAaWV0Zi5vcmcpOyB2Nm9w c0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBSYWppdiBBc2F0aSAocmFqaXZhKTxicj4KPGI+ U3ViamVjdDo8L2I+IFJlOiBbQkVIQVZFXSBbdjZvcHNdIEhvbWUgTkFQVDQ0IC0gSG93IG1hbnkg cG9ydHM/PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5PbiBKdW4gNiwgMjAxMywgYXQgNTowMiBQTSwgSm9obiBNYW5uICZsdDs8YSBocmVmPSJt YWlsdG86am9obi5tYW5uQG1vbmFzaC5lZHUiPmpvaG4ubWFubkBtb25hc2guZWR1PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiA3IEp1bmUgMjAxMyAwODo0MSwgUmFqaXYgQXNhdGkgKHJhaml2 YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ cmFqaXZhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIERhbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KJmd0OyBhbmQgc28gb24uICZuYnNwO0kg YW0gc3VycHJpc2VkIHlvdSBjb25jbHVkZSB0aGF0ICZxdW90OzUwMCBzZWVtcyBvayZxdW90OyB3 aGVuIHN1Y2ggYTxicj4KJmd0OyBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdv cmsgdXNlIG9uIHRob3NlIGRheXMuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYmFzZWQgdGhhdCBzdGF0ZW1lbnQg KCZxdW90Oy4uLnNlZW1zIG9rLCZxdW90Oykgb24gdGhlIHZlcnkgZmFjdCB0aGF0IHRoZSBudW1i ZXIgb2YgdGltZXMgdGhlIE5BVCB1dGlsaXphdGlvbiBleGNlZWRlZCA1MDAgbWFwcGluZ3MgKGVx dWF0aW5nIHRvIDUwMCBwb3J0cywgaW4gbXkgc2V0dXApIGluIHRoZSBzYW1wbGUgcGVyaW9kICh+ MiBtb250aHMpIHdhcyByZWxhdGl2ZWx5IHF1aXRlIGxvdy4KIFNvLCBpZiB0aGUgTkFUIGRldmlj ZSB3YXMgbGltaXRlZCB0byBvbmx5IDUwMCBtYXBwaW5ncywgdGhlbiB0aGUgZXhwZXJpZW5jZSB3 b3VsZCBoYXZlIGJlZW4gb2sgZm9yIDk5JSBvZiB0aGUgdGltZSBhbmQgZGVncmFkZWQgMSUgb2Yg dGhlIHRpbWUuIFRoaXMgaXMgYW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24sIElNTy48YnI+Cjxi cj4KRm9yIGV4LCBpbiB0aGUgbGFzdCAyIHdlZWtzLCB0aGUgbnVtYmVyIG9mIHRpbWVzIE5BVCBt YXBwaW5ncyBleGNlZWRlZCA1MDAgd2VyZTo8YnI+Cjxicj4KSnVuZSAzIC0gMSB0aW1lPGJyPgpN YXkgMjkgLSAxIHRpbWU8YnI+Ck1heSAyOCAtIDMgdGltZXM8YnI+Ck1heSAyNiAtIDEgdGltZTxi cj4KTWF5IDIzIC0gMSB0aW1lPGJyPgpNYXkgMjIgLSAyIHRpbWVzPGJyPgpNYXkgMjEgLSAzIHRp bWVzPG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgYSBtb3JlLWlu dGVyZXN0aW5nIHN0YXRpc3RpYyB3b3VsZCBiZSAmcXVvdDtob3cgbWFueSBjb25uZWN0aW9uIHNl dHVwcyB3b3VsZCBoYXZlIGZhaWxlZCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IEkgZG9u J3QgdGhpbmsgeW91IGNhbiBtZWFzdXJlIHRoYXQganVzdCBieSBwb2xsaW5nIGNvbmN1cnJlbnQg Y29ubmVjdGlvbnMgYXQgc3BlY2lmaWMgdGltZXMuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rp dj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IG1pZ2h0 IHRha2UgZS5nLiBuZXRmbG93IGV4cG9ydGluZyBhbmQgYW5hbHlzaXMgLi4uPG86cD48L286cD48 L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3dldmVyICZxdW90O251bWJlciBvZiBj b25jdXJyZW50IGNvbm5lY3Rpb25zIHRoYXQgY291bGRuJ3QgaGF2ZSBiZWVuIHNldHVwJnF1b3Q7 IHdvdWxkIGJlIHVzZWZ1bCBpbiZuYnNwO2dhdWdpbmcmbmJzcDt0aGUgaW1wYWN0PG86cD48L286 cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPmUuZy4gb24gTWF5IDI5IHRoZXJlIHdhcyBvbmUgc3Bpa2Ugb2YgNzM0IGNvbmN1 cnJlbnQgY29ubmVjdGlvbnMsIHRoZW4gcmVwb3J0IHRoYXQgYXMgMjM0IHBvdGVudGlhbCBmYWls dXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rp dj4KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9m IGNvdXJzZSwgMTAwMCBwb3J0cyAocmVzdWx0aW5nIGluIDEwMDAmIzQzOyBtYXBwaW5ncykgd291 bGQgaGF2ZSBiZWVuIG1vcmUgdGhhbiBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHRpbWVzIHdo ZW4gdGhlIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCwgYnV0IHN0YXllZCB3aXRoaW4gMTAwMCAoZXhj ZXB0IG9uY2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgomZ3Q7IFdoYXQgaXMgdGhlIG1heGltdW0g bnVtYmVyIG9mIG1hcHBpbmdzIHN1cHBvcnRlZCBieSB5b3VyIE5BUFQgZGV2aWNlPzxicj4KJmd0 OyBTb21lIHJlc2lkZW50aWFsLWNsYXNzIE5BVHMgaGF2ZSBhIGxpbWl0IG9mIDEwMjQgbWFwcGlu Z3MuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPklzIHRoYXQgYSBjb21iaW5lZCBsaW1pdCBvZiBUQ1AgYW5kIFVEUCBhbmQgSUNNUCwgb3Ig aW5kZXBlbmRlbnQ/PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8 L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgc3R1ZHkgYXQmbmJzcDs8YSBocmVmPSJodHRwOi8vZWdn ZXJ0Lm9yZy9wYXBlcnMvMjAxMC1pbWMtaGd3LXN0dWR5LnBkZiI+aHR0cDovL2VnZ2VydC5vcmcv cGFwZXJzLzIwMTAtaW1jLWhndy1zdHVkeS5wZGY8L2E+IG9ubHkgYW5hbHl6ZWQgVENQIGJpbmRp bmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxkaXY+CjxkaXY+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgTkFQVCBkZXZp Y2Ugc2VlbWluZ2x5IGNhbiB1c2UgdXB0byA2NEsgcG9ydHMuIDopPGJyPgo8YnI+CkNoZWVycyw8 YnI+ClJhaml2PG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPgo8YnI+CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+CiZndDsgRnJvbTogRGFuIFdpbmcgKGR3aW5nKTxicj4KJmd0OyBTZW50OiBUaHVy c2RheSwgSnVuZSAwNiwgMjAxMyAxMTo0MyBBTTxicj4KJmd0OyBUbzogUmFqaXYgQXNhdGkgKHJh aml2YSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT47IFNvZnR3aXJlcy13ZyBsaXN0ICg8YSBocmVmPSJt YWlsdG86c29mdHdpcmVzQGlldGYub3JnIj5zb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+KTs8YnI+CiZn dDsgPGEgaHJlZj0ibWFpbHRvOmJlaGF2ZUBpZXRmLm9yZyI+YmVoYXZlQGlldGYub3JnPC9hPjsg RXJpayBLbGluZSAoPGEgaHJlZj0ibWFpbHRvOmVrQGdvb2dsZS5jb20iPmVrQGdvb2dsZS5jb208 L2E+KTxicj4KJmd0OyBTdWJqZWN0OiBSZTogW0JFSEFWRV0gSG9tZSBOQVBUNDQgLSBIb3cgbWFu eSBwb3J0cz88YnI+CiZndDs8YnI+CiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8 ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBP biBKdW4gNSwgMjAxMywgYXQgNjoxNCBBTSwgUmFqaXYgQXNhdGkgKHJhaml2YSkgJmx0OzxhIGhy ZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIj5yYWppdmFAY2lzY28uY29tPC9hPiZndDsgd3Jv dGU6PGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsgU29tZSBvZiB5b3UgbWF5IHJlY2FsbCBvdXIgZGlz Y3Vzc2lvbiAoZHVyaW5nIHRoZSBsYXN0IElFVEYpIGFyb3VuZCAmcXVvdDtob3c8YnI+CiZndDsg bWFueSBUQ1AvVURQIHBvcnRzIGFyZSBlbm91Z2ggd2l0aCBOQVBUNDQmcXVvdDsgcGVyIGhvbWUs IGFzIElTUHMgbW92ZSBpbnRvPGJyPgomZ3Q7IEEmIzQzO1AgcGFyYWRpZ20uIH41MDAsIH4xMDAw LCB+MzAwMD8/Pzxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7ICZndDsgV2VsbCwgSSBzdGFydGVkIG1v bml0b3JpbmcgbXkgaG9tZSByb3V0ZXIgYW5kIHBsb3R0aW5nIHRoZSBOQVBUNDQgcG9ydDxicj4K Jmd0OyB1dGlsaXphdGlvbiBvbiBhIG1pbnV0ZS1ieS1taW51dGUgYmFzaXMuIFlvdSBtYXkgZmlu ZCBpdCBoZXJlIC08YnI+CiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5lbXBsb3llZXMub3JnL35y YWppdmEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmVtcGxveWVlcy5vcmcvfnJhaml2YTwv YT48YnI+CiZndDsgJmd0Ozxicj4KJmd0OyAmZ3Q7IEluIHNob3J0LCBwb3J0IHJhbmdlIG9mIDUw MCBzZWVtcyBvaywgdGhvdWdoIDEwMDAgd291bGQgYmUgbW9yZSB0aGFuPGJyPgomZ3Q7IGVub3Vn aCBmb3IgbXkgaG9tZS48YnI+CiZndDs8YnI+CiZndDsgSSBzZWUgc2V2ZXJhbCBzcGlrZXMgaW4g eW91ciBkYXRhIG92ZXIgNTAwIHBvcnRzLiAmbmJzcDtEdXJpbmcgdGhvc2UgdGltZXMsPGJyPgom Z3Q7IGFwcGxpY2F0aW9ucyB3b3VsZCBiZSB1bmFibGUgdG8gZnVuY3Rpb24gKHVuYWJsZSB0byBn ZXQgYSBwb3J0KS4gJm5ic3A7QXByaWwgMjkvMzA8YnI+CiZndDsgaXMgYSBsb25nIHRpbWUgd2hl cmUgdGhhdCBvY2N1cnMgdmVyeSB2aXNpYmx5LCBidXQgdGhlcmUgYXJlIHNob3J0ZXIgc3Bpa2Vz PGJyPgomZ3Q7IGVsc2V3aGVyZSBzdWNoIGFzIG9uIEFwcmlsIDE3IGFuZCBBcHJpbCAxOC4gJm5i c3A7SWYgeW91IGhhZCBvbmx5IDUwMCBwb3J0cyBvbjxicj4KJmd0OyB0aG9zZSBkYXlzLCBjcmVh dGluZyBhIG5ldyBUQ1AgbWFwcGluZyB3b3VsZCBoYXZlIGJlZW4gaW1wb3NzaWJsZSw8YnI+CiZn dDsgaW1wYWN0aW5nIGFiaWxpdHkgdG8gc2VuZCBvciByZWNlaXZlIGVtYWlsLCBvcmRlciBib29r cyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly9BbWF6b24uY29tIj4KQW1hem9uLmNvbTwvYT4sPGJyPgom Z3Q7IGFuZCBzbyBvbi4gJm5ic3A7SSBhbSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgJnF1 b3Q7NTAwIHNlZW1zIG9rJnF1b3Q7IHdoZW4gc3VjaCBhPGJyPgomZ3Q7IGxpbWl0IHdvdWxkIGlu dGVyZmVyZSB3aXRoIHlvdXIgbmV0d29yayB1c2Ugb24gdGhvc2UgZGF5cy48YnI+CiZndDs8YnI+ CiZndDsgV2hhdCBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgbWFwcGluZ3Mgc3VwcG9ydGVkIGJ5 IHlvdXIgTkFQVCBkZXZpY2U/PGJyPgomZ3Q7IFNvbWUgcmVzaWRlbnRpYWwtY2xhc3MgTkFUcyBo YXZlIGEgbGltaXQgb2YgMTAyNCBtYXBwaW5ncy48YnI+CiZndDs8YnI+CiZndDsgLWQ8YnI+CiZn dDs8YnI+CiZndDsgJmd0OyBTdWZmaWNlIHRvIHNheSwgdGhpcyBpcyBqdXN0IGEgc2FtcGxlIHJl cHJlc2VudGF0aW9uLCBzaW5jZSB0aGUgcG9ydDxicj4KJmd0OyB1dGlsaXphdGlvbiB3b3VsZCB2 YXJ5IGhvbWUgdG8gaG9tZSwgYmFzZWQgb24gbnVtYmVyIG9mIGFjdGl2ZSBkZXZpY2VzLDxicj4K Jmd0OyB0eXBlIG9mIGFwcGxpY2F0aW9ucywgdGhlIGRlZ3JlZSBvZiBzaW11bHRhbmVvdXMgZGV2 aWNlIG9yIGFwcGxpY2F0aW9uPGJyPgomZ3Q7IHVzYWdlIGV0Yy48YnI+CiZndDsgJmd0Ozxicj4K Jmd0OyAmZ3Q7IElmIGFueSBvZiB5b3UgYXJlIGRvaW5nIHNpbWlsYXIgbW9uaXRvcmluZywgdGhl biBwbGVhc2Ugc2hhcmUuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBDaGVlcnMsPGJyPgom Z3Q7ICZndDsgUmFqaXY8YnI+CiZndDsgJmd0Ozxicj4KJmd0OyAmZ3Q7IFBTOiBUaGFua3MgdG8g RXJpayBLbGluZSwgd2hvIGV4cGxhaW5lZCAod2l0aCBzdWZmaWNpZW50IGRldGFpbHMpIGhvdyB0 byB1c2U8YnI+CiZndDsgZ29vZ2xlIGNoYXJ0aW5nIGZvciBteSBkYXRhLiBBbmQgdGhhbmtzIHRv IFh1biBXYW5nICZhbXA7IFNoYW9zaHVhaSBEYWkgZm9yPGJyPgomZ3Q7IGhlbHBpbmcgbWUgb3V0 IHNpZ25pZmljYW50bHkuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBQUzogTXkgaG9tZSBo YXMgMy00IGFjdGl2ZSBkZXZpY2VzLjxicj4KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgomZ3Q7ICZndDsgQmVoYXZlIG1haWxpbmcg bGlzdDxicj4KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpCZWhhdmVAaWV0Zi5vcmciPkJlaGF2 ZUBpZXRmLm9yZzwvYT48YnI+CiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlPC9hPjxicj4KPGJyPgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KdjZvcHMgbWFpbGluZyBsaXN0 PGJyPgo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxi cj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxvY2txdW90ZT4K PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 PgoKPERJVj48UD48SFI+CjxQPjxGT05UIGNvbG9yPSM5OTk5OTkgc2l6ZT0xIGZhY2U9QXJpYWw+ SVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkciYjMzgyO2FqIG92ZSBwb3J1a2Ug aSBldmVudHVhbG5vIHByaWxvJiMzODI7ZW5paCBkYXRvdGVrYSBqZSBwb3ZqZXJsaml2IGkgbmFt aWplbmplbiBqZSBzYW1vIG9zb2JhbWEgaWxpIHN1Ympla3RpbWEga29qaSBzdSBuYXZlZGVuaSB1 IGFkcmVzaS4gVWtvbGlrbyBzdGUgcHJpbWlsaSBvdnUgcG9ydWt1IGdyZSYjMzUzO2tvbSwgbW9s aW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvJiMzNTM7aWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBu amVuZSBwcml2aXRrZSBvZG1haCwgYmV6ICYjMjY5O2l0YW5qYSwgdHJham5vIHVrbG9uaXRlIHMg cmEmIzI2OTt1bmFsYS4gQmlsbyBrYWt2byBwcmVubyYjMzUzO2VuamUsIGtvcGlyYW5qZSBpbGkg ZGlzdHJpYnVjaWphIGluZm9ybWFjaWphIHNhZHImIzM4MjthbmloIHUgcG9ydWNpIHRyZSYjMjYz O2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vJiMzODI7ZSBiaXRpIHpha29uc2tpIGthJiMz ODI7bmppdm8uIFNhZHImIzM4Mjthaiwgc3Rhdm92aSBpIG1pJiMzNTM7bGplbmphIGl6bmVzZW5p IHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudSYjMzgyO25vIHN0YXZv dmUgSFQgLSBIcnZhdHNrb2cgVGVsZWtvbWEgZC5kLiBIVCBuZSBwcmlodmEmIzI2MzthIG5pa2Fr dnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSAmIzM1Mzt0ZXR1IG5hc3RhbHUgcHJpbWl0a29t IG92ZSBwb3J1a2UgaSBwcmlsb2dhIHNhZHImIzM4MjthbmloIHUgcG9ydWNpLiA8L0ZPTlQ+PC9Q Pg0KPFA+PEZPTlQgY29sb3I9Izk5OTk5OSBzaXplPTEgZmFjZT1BcmlhbD5ESVNDTEFJTUVSOlRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRv IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMg b3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmls ZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1 dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8g b3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBs ZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJp bHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJ bmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBv dGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQg dG8gaXQuIDwvRk9OVD48L1A+CjwvUD48L0RJVj4KPC9ib2R5Pgo8L2h0bWw+Cg== --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_-- From sthaug@nethelp.no Fri Jun 7 00:50:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B38521F93E0 for ; Fri, 7 Jun 2013 00:50:43 -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 eROpxUhjTPx3 for ; Fri, 7 Jun 2013 00:50:36 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 5701421F9017 for ; Fri, 7 Jun 2013 00:50:34 -0700 (PDT) Received: (qmail 81414 invoked from network); 7 Jun 2013 07:50:33 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 Jun 2013 07:50:33 -0000 Date: Fri, 07 Jun 2013 09:50:33 +0200 (CEST) Message-Id: <20130607.095033.74669945.sthaug@nethelp.no> To: v6ops@globis.net From: sthaug@nethelp.no In-Reply-To: <51B18AC1.5070403@globis.net> References: <51B180B3.2090106@globis.net> <20130607.090624.19791724.he@uninett.no> <51B18AC1.5070403@globis.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:50:43 -0000 > How's that worse than today, where people are apparently dropping all > packets containing any extension headers (because they're all soft > switched)? Also, remember there is plenty of hardware out there that doesn't *do* soft switching at all. If a packet cannot be forwarded in hardware, it is dropped. > The basic idea being that we can optimize/facilitate hardware parsing > further and further along the header chain by publishing additional > informational RFCs, and at some point in the future we'll get enough > extension headers supported together with hardware forwarding that they > become useful. I'd certainly like to be able to buy a firewall with ASIC > optimized forwarding of IPv6 (including extension headers). I definitely think this is worth pursuing, as long as the point of not creating a DoS vector is kept in mind. > The alternative would seem to be a stalemate of continual shouting from > the ivory tower that hardware vendors just need to learn to live with > arbitrary packet complexity, whilst operational people drop everything > containing an extension header so there's no market demand for the > hardware vendors to do anything. Or operational people voting with their wallets, and buying the box that kan "only" look 256 bytes into the header, because it is N% less expensive than the box that can look a full 64 kByte into the header. Steinar Haug, AS 2116 From prvs=1870fa6dff=scott.mansfield@ericsson.com Fri Jun 7 05:00:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6714121F9017 for ; Fri, 7 Jun 2013 05:00: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=[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 azlHzJyH5jIQ for ; Fri, 7 Jun 2013 05:00:18 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B81FE21F93C4 for ; Fri, 7 Jun 2013 05:00:16 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-9d-51b1cb4ffb2c Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A1.27.05617.F4BC1B15; Fri, 7 Jun 2013 14:00:15 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 08:00:14 -0400 From: Scott Mansfield To: "v6ops@ietf.org" Thread-Topic: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: Ac5jYIPck0d+2CUNT3Sp/Yo0Bb4r3gAFgdfA Date: Fri, 7 Jun 2013 12:00:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E245586411523724eusaamb102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyuXSPn67/6Y2BBme3qlicPraX2YHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3Blbvh9jLZisWbH+9FbmBsYXyl2MnBwSAiYS83YsYYOwxSQu 3FsPZgsJHGWUuDuZo4uRC8hexihxuG8XC0iCDahh667pjCC2iICqxOmnl5lBbGGBRImTvzax Q8QTJc69amOBsI0krrfcAIpzcLAIqEis3ecPEuYV8JVY03kSrJURaO/3U2uYQGxmAXGJW0/m M0HcIyCxZM95ZghbVOLl43+sELayxJIn+1kg6vMlpk44yAwxU1Di5MwnLBMYhWYhGTULSdks JGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66keEmRmDgH5Ngc9zBuOCT 5SFGaQ4WJXFeHd7FgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4QQSXVAOj6RoW2zaFWaWFzVs+ fOHffkpo6SfXTVnJK8py/i65nvvhY3Lnodbwm5vYdnwslJvf7bkoJV7eadZ7g5blk+7NXfOG d9bhuFMTF2Tv69p7usg3UZthlvf+20dyltevu9NdZCohfzRY6FFvscm3tj0r7ut+McwJ0orb 3eOfbyiSqKxiqxSYrTpDiaU4I9FQi7moOBEAYrUaBk8CAAA= X-Mailman-Approved-At: Fri, 07 Jun 2013 05:13:46 -0700 Subject: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:00:23 -0000 --_000_EF35EE4B92789843B1DECBC0E245586411523724eusaamb102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Scott Mansfield Sent: Friday, June 07, 2013 5:22 AM To: 'saag@ietf.org' Subject: ITU-T Recommendation ITU-T X.1037, Technical security guideline on= deploying IPv6 https://datatracker.ietf.org/liaison/1255/ Further information on this document. X.1037 is in an ITU approval process= called AAP. The deadline for comments on the document is 12 June 2013. T= here are a number of comments on the document already submitted by an ITU s= ector member, so the document will have to be reviewed and modified before = it can move forward. The next step in the process would be something call = additional review. In additional review, comments are accepted only on the= parts of the document that were modified, no new substantive comments on t= he rest of the document are accepted. So, if there are comments anyone wou= ld like to make on the document, please send them to be before 12 June. Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_EF35EE4B92789843B1DECBC0E245586411523724eusaamb102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     

     

    From: Scott Ma= nsfield
    Sent: Friday, June 07, 2013 5:22 AM
    To: 'saag@ietf.org'
    Subject: ITU-T Recommendation ITU-T X.1037, Technical security guide= line on deploying IPv6

     

    https://datatracker.ietf.org/liaison/1255/

     

    Further information on this document.  X.1037 i= s in an ITU approval process called AAP.  The deadline for comments on= the document is 12 June 2013.  There are a number of comments on the = document already submitted by an ITU sector member, so the document will have to be reviewed and modified before it can move f= orward.  The next step in the process would be something call addition= al review.  In additional review, comments are accepted only on the pa= rts of the document that were modified, no new substantive comments on the rest of the document are accepted.  S= o, if there are comments anyone would like to make on the document, please = send them to be before 12 June.

     

    Regards,

    -scott.

     

    Scott Mansfield

    Ericsson Inc.

    +1 724 931 9316

     

    --_000_EF35EE4B92789843B1DECBC0E245586411523724eusaamb102erics_-- From nalini.elkins@insidethestack.com Fri Jun 7 05:54:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6079321F8B04 for ; Fri, 7 Jun 2013 05:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ogXNac-xMu3W for ; Fri, 7 Jun 2013 05:54:08 -0700 (PDT) Received: from nm20-vm0.access.bullet.mail.mud.yahoo.com (nm20-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.29]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1B21F8B07 for ; Fri, 7 Jun 2013 05:54:05 -0700 (PDT) Received: from [66.94.237.200] by nm20.access.bullet.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 12:54:05 -0000 Received: from [66.94.237.115] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 12:54:05 -0000 Received: from [127.0.0.1] by omp1020.access.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 12:54:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 192190.54951.bm@omp1020.access.mail.mud.yahoo.com Received: (qmail 76052 invoked by uid 60001); 7 Jun 2013 12:54:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370609644; bh=dDB9BvBgTIPq5H5LAeQ1BshH0TM+L/cD+ZefHodiBEU=; 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=dpWq1P5k5xh119YzvFynAdbf/tyaxFOO/2N7fpDeJFKCVUJsplUKVF7EJDShmnNihmU8f53X7Z213/pTroI9DFea68RERby1+T7EytWnyfKafb/4EfmB7GA7YYHM3VcSy8yXpx0ur9/FJONkZAafRURKvb8iyMey4n+3IcvMBfU= X-YMail-OSG: HcUERZ8VM1mTqS8jOLhbydMIKpUQCzxDEB6YrsWoF1kNSuA HqbvRYIC1FjAdMDsc4HPdKp4g_QdlQl89jrTI260lfAOzpJSltvXlRMFXrKq rIiZM_G3OPiB7h6wIHqqfh55J9gdVbk06axsU6y22Lylc0cD.GbFW8MJcw4w 3FfN7uUkiJ_6nm6MpXh351SZYwkVy6N38ZZ6pCC.0mK0Zkjo4q4W8qL2uMhw rFUqN_iCFyRCRN2ezeWIspL4XHm9wYXQ_bGRMbGE6ja2hF5Lu45wsGnlperR 3Bw7tXq9.S0DpZEqBqtQP6nzcr.Hw2f0ewosIZ1Sgy07aHM0nR4cpaN8X4YU fEAPJmgtshcRzk2VZgGX3ibZzzsoLgbw9Vq3GavLilH3VEsGmd5IYIiOXFfY WfgqxtvP4qUtjJqTtLIlLSnmtHrjtCYN8QBL09XY6LssiCWTBlRM4tMk2PX. gMM_gfTngGceOr4FHsXVZLKrSH0ILMZ1Sxm2deDwyudLOmgvU6RiUABL3PYT a4svbsSTlWwxslDkIfBCtsTscDHb02kLUYizjhFSbO1PLLlkI9EcVuuyYCKw - Received: from [50.131.220.245] by web2806.biz.mail.ne1.yahoo.com via HTTP; Fri, 07 Jun 2013 05:54:04 PDT X-Rocket-MIMEInfo: 002.001, CgoKCk9uIEZyaSwgSnVuIDcsIDIwMTMgYXQgMToyMyBQTSwgTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20.IHdyb3RlOgoKSWYgSSBtaWdodCwgSSBzZWVtIHRvIHNlbnNlIHRoYXQgc29tZSBvZiB0aGUgcGVvcGxlIG9uIHRoaXMgbGlzdCBwb3NzaWJseSBtYXkgbm90IHJlYWxseSB1bmRlcnN0YW5kIG9yIG1heSBub3QgaGF2ZSBtdWNoIHN5bXBhdGh5IGZvciB0aGUga2luZCBvZiBwcmVzc3VyZSB3ZSBhcmUgdW5kZXIgdG8gc29sdmUgcHJvYmxlbXMgcXVpY2tseSBhbmQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Message-ID: <1370609644.50793.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 05:54:04 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-666606087-1370609644=:50793" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:54:15 -0000 --1510626085-666606087-1370609644=:50793 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0AOn Fri, Jun 7, 2013 at 1:23 PM, Nalini Elkins wrote:=0A=0AIf I might, I seem to sense that some of the = people on this list possibly may not really understand or may not have much= sympathy for the kind of pressure we are under to solve problems quickly a= nd to meet service level requirements for performance. =A0If you can think = of the type of networks our team runs - the health care networks, the banki= ng sector, the stock markets, you can see that we diagnosticians have a lot= of pressure on us.=0A>=0A=0A>>Agreed. But all those networks are highly sp= ecialized, highly closed, and highly integrated, and the solutions that are= appropriate for them might not be appropriate for the general Internet.=0A= =0AWell, the problem is that we all have to live together. =A0 That is, I w= ish we had a set of rules for us and a set of rules for the Internet. =A0Bu= t, what has happened is that we have to live with the rules for the general= Internet, and sometimes that doesn't work for us. =A0 You are actually poi= nting out the fundamental problem. =A0 RFCs defined for the general Interne= t are having to be used on Intranets! =A0So, as Ole puts it, maybe sometime= s, we have to say, this is for 'consenting adults' only? =A0I don't know. = =A0What do you think? =A0=0A=0A>>=A0Also, if you want to solve this problem= quickly, then... well, an extension header is not a good idea, because it = has to be implemented at the lowest level possible (the host operating >>sy= stem). If you need a quick solution, then what you want is the sequence num= ber field in the GRE header.=0A=0AOur networks don't always use GRE & I don= 't know that we want to change everything to encapsulate everything everywh= ere in GRE. --1510626085-666606087-1370609644=:50793 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


    =0A
    On Fri, Jun 7, 2013 at 1:23 PM, Nalini E= lkins <nalini.elkins@insidethestack.com> wrote:
    =
    =0A=0A
    If I might, I seem to = sense that some of the people on this list possibly may not really understa= nd or may not have much sympathy for the kind of pressure we are under to s= olve problems quickly and to meet service level requirements for performanc= e.  If you can think of the type of networks our team runs - the healt= h care networks, the banking sector, the stock markets, you can see that we= diagnosticians have a lot of pressure on us.
    =0A=0A
    >>Agreed. But all those networks are highly s= pecialized, highly closed, and highly integrated, and the solutions that ar= e appropriate for them might not be appropriate for the general Internet.

    Well, the problem is that we = all have to live together.   That is, I wish we had a set of rules for= us and a set of rules for the Internet.  But, what has happened is th= at we have to live with the rules for the general Internet, and sometimes t= hat doesn't work for us.   You are actually pointing out the fundament= al problem.   RFCs defined for the general Internet are having to be u= sed on Intranets!  So, as Ole puts it, maybe sometimes, we have to say= , this is for 'consenting adults' only?  I don't know.  What do y= ou think?  

    >>&nb= sp;Also, if you want to solve this problem quickly, then... well, an extension header is not a goo= d idea, because it has to be implemented at the lowest level possible (the = host operating >>system). If you need a quick solution, then what you= want is the sequence number field in the GRE header.

    Ou= r networks don't always use GRE & I don't know that we want to change e= verything to encapsulate everything everywhere in GRE.
    =0A=0A
    =0A


    --1510626085-666606087-1370609644=:50793-- From Ted.Lemon@nominum.com Fri Jun 7 06:23:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 touch@isi.edu Fri Jun 7 07:45:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4074121F9619 for ; Fri, 7 Jun 2013 07:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8pAOb18adtS for ; Fri, 7 Jun 2013 07:44:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3621F9476 for ; Fri, 7 Jun 2013 07:44:59 -0700 (PDT) Received: from [192.168.1.92] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r57EhGeH018124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 07:43:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 07:43:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> To: Nalini Elkins X-Mailer: Apple Mail (2.1503) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:45:11 -0000 On Jun 6, 2013, at 9:23 PM, Nalini Elkins = wrote: > Speaking of Ms. Elkins original topic, some of us in the real world = have used the old IPID field in IPv4 as a packet sequence number to do = diagnostics more quickly even though it was not intended as such. In = the real world, you do what you have to to keep your network running and = solve problems. Theory goes out the window when real users are = involved. >=20 > This is why we want the new implementation of the destination options = header that we have defined.=20 The old IPv4 ID field never did support diagnostics correctly, because: - they were never intended for diagnostics at all - vendors decided it was too much work to generate unique IDs = correctly: - endpoints that want to go faster than a few Mbps - NATs that want less state - cellphones that want even less state So basically the device vendors decided they should make more money, at = the expense of the diagnostics vendors. A similar tension happened when IPv6 was being designed, and the = compromise was to put everything a router needed in either the main = header or the HBH header. Putting more there - a hostID, packetID, or a copy of the transport = ports - is the same tension between those who want to build "cheaper = than chasing a chain" routers vs. those who want endpoints that run = fast, can be implemented cheaply, or are secure (against DOS attacks, or = just implement privacy). So, correct me if I'm wrong, but isn't this discussion then about=20 what do you propose to put in the HBH header,=20 and is it safe and worth the cost? But ignoring packets that use the chained headers that follow is a = non-starter for IPv6. Joe= From shane@castlepoint.net Fri Jun 7 07:46:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B4521F8E93 for ; Fri, 7 Jun 2013 07:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 d1qSHT7iW3Do for ; Fri, 7 Jun 2013 07:46:50 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id B87B021F86D3 for ; Fri, 7 Jun 2013 07:46:50 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 544AC300028 for ; Fri, 7 Jun 2013 14:46:50 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B0B24300025; Fri, 7 Jun 2013 08:46:49 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <51B180B3.2090106@globis.net> Date: Fri, 7 Jun 2013 08:46:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2C3E993B-7C75-47D2-B215-838F99DD9670@castlepoint.net> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B180B3.2090106@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Jun 7 08:46:50 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 51b1f25a42079416818295 X-DSPAM-Factors: 27, 2013+at, 0.40000, but+on, 0.40000, up+#+we, 0.40000, to+#+#+#+convenient, 0.40000, to+#+#+#+convenient, 0.40000, Mime-Version*Mail+6.3, 0.40000, it's+#+#+#+interests, 0.40000, exactly+this, 0.40000, standard+#+RFCs, 0.40000, talks+#+#+towers, 0.40000, we+#+#+#+for, 0.40000, the+#+stack, 0.40000, grained+#+#+of, 0.40000, forwarding+#+#+#+for, 0.40000, IETF+draft, 0.40000, dropped+#+#+currently, 0.40000, cover+#+aspects, 0.40000, informational+RFCs, 0.40000, blah+#+seem, 0.40000, IP+#+#+#+parsing, 0.40000, all+#+here, 0.40000, in+#+this, 0.40000, and+#+#+#+the, 0.40000, the+#+#+nor, 0.40000, it+#+you, 0.40000, MPLS+From, 0.40000, MPLS+network, 0.40000 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:46:55 -0000 Hi Ray, Joe, others, Please see below. On Jun 7, 2013, at 12:41 AM, Ray Hunter wrote: > Joe Touch wrote: >>=20 >>=20 >> On 6/6/2013 2:36 PM, Havard Eidnes wrote: >>>>> And therein lies the problem. As pointed out by Nick Hilliard and >>>>> myself, we *need* those stateless firewall functions, which may >>>>> need to look up stuff way beyond the destination address. I don't >>>>> find a discussion of whether such functions *should* be needed in >>>>> a router or not all that relevant. >>>>=20 >>>> Just as I don't find a discussion of how much the cost to implement >>>> such functions makes the life of router venders more complex. >>>>=20 >>>> If the kitchen is too hot... >>>=20 >>> That's one vantage point. Another would be one which talks about >>> ivory towers and losing touch with what is practically possible now. >>=20 >> If it's possible, then there's no problem. >>=20 >> What you're all suggesting here are ways to limit IPv6 to make it = more >> convenient for router vendors to implement various features that were >> never part of the design (of either the Internet architecture nor of >> IPv6 in specific). >>=20 >> If you want to make sure that IP supports efficient router parsing of >> L4 header information, IMO you can take that up when we design IPv7, >> but it was never a requirement of IPv6. Assuming it now is - as you >> are all discussing - impractical. >>=20 >> Joe >>=20 > Why do you think it's impractical to make IPv6 more convenient for > middle-box and router vendors to parse without going back to the = drawing > board? >=20 >=20 > What if there were a bunch of informational RFC's that said "if you = want > your packet switched on the fast past in hardware make sure it ..... = blah" >=20 > Where blah is something like: > has (a maximum of) n MPLS labels in the the stack > has (a maximum of) n QinQ tags > ..... > the hop by hop header may or may not be present, but if present it > should always contain exactly these TLV hop-by-hop options in exactly > this transmission order. >=20 > Wouldn't that ensure that it's in everyones' best interests to adhere = to > these informational RFCs, without having to completely redo standards > track RFCs? (Other packets confirming to standard track RFCs should > still be properly switched, but on a slightly slower, or very much > slower path) >=20 > At the moment, "blah" would seem to be "make sure your packet does not > contain any extension headers, or else it will likely be dropped" and > we've currently got the wrong optimization of flexibility and length > efficiency versus switching speed. I would like to point out the following effort, initiated by Curtis = Villamizar and to which I and others have contributed, in the MPLS WG to = do what you're describing above specific to _MPLS_: http://tools.ietf.org/html/draft-ietf-mpls-forwarding-00 =46rom the Abstract of the above IETF draft: ---snip--- This document provides guidelines for implementors regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementors might potentially overlook practical requirements which are unstated or underemphasized or are optional for conformance to RFCs. ---snip--- Note first that the above document is _Informational_. Second, the = above document is intended to address MPLS _forwarding_. To my = knowledge, we have *not* stated anything specific to length/number of = IPv6 extension headers, nor do I think we should. However, we have = stated that, for practical reasons, if a forwarding HW and/or ASIC = vendor wants to be successful, then they SHOULD allow for inspection of = IPv4 and IPv6 header information, including src_port + dst_port, to = support fine-grained load-balancing of IP/MPLS traffic over LAG or ECMP = paths in the core of a MPLS network. IMHO, if anyone attempts to = specify new IPv6 Extension Headers or other proposals that increase the = length of IPv6 Extension Header chains that would *inhibit* extraction = of Layer-4 information for the purposes of load-balancing or stateless = FW filtering in routers, then operators (and, vendors they buy from) are = not going to support it. If you have any comments specific to this document, then please take = them to the MPLS WG mailing list. -shane= From joelja@bogus.com Fri Jun 7 08:26:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" Subject: [v6ops] Moderate: Re: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 mackermann@bcbsm.com Fri Jun 7 09:36:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA05921F96B1 for ; Fri, 7 Jun 2013 09:36:50 -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 4bZgs3k7ABNL for ; Fri, 7 Jun 2013 09:36:46 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4733121F961B for ; Fri, 7 Jun 2013 09:36:45 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 82BA02FF6DC for ; Fri, 7 Jun 2013 11:36:44 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id E1DA430750B; Fri, 7 Jun 2013 11:36:43 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id BF2774F805A; Fri, 7 Jun 2013 12:32:12 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id B132B4F8059; Fri, 7 Jun 2013 12:32:12 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0438.000; Fri, 7 Jun 2013 12:36:43 -0400 From: "Ackermann, Michael" To: Joe Touch , Nalini Elkins Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOYG4EHn4XBQzX90KTpobgByNivpklDR0AgAAfDICAABbVAIAAlsuAgAAI24CAAAIRAIAAPfeAgAADQICAADbugIABGoaAgAAO6wCAAAo8AIAADRKAgAAh0gCAAAMXgIAACY6AgAAIHgCAAAGWgIAAAacAgAAFmQCAAAFTAIAAImUAgAB1XwCAAPj7AIAABGoAgAAFDwCAAAWTgIAAAUMAgABJoICAACadgIAArVaA///KkUA= Date: Fri, 7 Jun 2013 16:36:40 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A779B2F@PWN401EA160.ent.corp.bcbsm.com> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:36:51 -0000 Agree strongly that ignoring packets that have chained headers (which an = intrinsic part of the protocol), will be a HUGE detriment to IPV6 = deployment in the real world. =20 And regarding the comment about theory going out the window when it = conflicts with reality. Unfortunately TRUE DAT=21 But I am hopeful = that we are not too late to get theory to somewhat match reality here and = encourage (rather than discourage) IPV6 deployments. =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Joe Touch Sent: Friday, June 07, 2013 10:44 AM To: Nalini Elkins Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On Jun 6, 2013, at 9:23 PM, Nalini Elkins = wrote: > Speaking of Ms. Elkins original topic, some of us in the real world have = used the old IPID field in IPv4 as a packet sequence number to do = diagnostics more quickly even though it was not intended as such. In the = real world, you do what you have to to keep your network running and solve = problems. Theory goes out the window when real users are involved. >=20 > This is why we want the new implementation of the destination options = header that we have defined.=20 The old IPv4 ID field never did support diagnostics correctly, because: =09- they were never intended for diagnostics at all =09- vendors decided it was too much work to generate unique IDs correctly: =09=09- endpoints that want to go faster than a few Mbps =09=09- NATs that want less state =09=09- cellphones that want even less state So basically the device vendors decided they should make more money, at = the expense of the diagnostics vendors. A similar tension happened when IPv6 was being designed, and the = compromise was to put everything a router needed in either the main header = or the HBH header. Putting more there - a hostID, packetID, or a copy of the transport ports = - is the same tension between those who want to build =22cheaper than = chasing a chain=22 routers vs. those who want endpoints that run fast, can = be implemented cheaply, or are secure (against DOS attacks, or just = implement privacy). So, correct me if I'm wrong, but isn't this discussion then about=20 =09what do you propose to put in the HBH header,=20 =09and is it safe and worth the cost? But ignoring packets that use the chained headers that follow is a = non-starter for IPv6. Joe _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From mackermann@bcbsm.com Fri Jun 7 09:36:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9954621F96DF for ; Fri, 7 Jun 2013 09:36:54 -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 ttlWoKT6uYJ4 for ; Fri, 7 Jun 2013 09:36:50 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2425E21F9638 for ; Fri, 7 Jun 2013 09:36:50 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id DFB532FF6E1 for ; Fri, 7 Jun 2013 11:36:49 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id C286030750B; Fri, 7 Jun 2013 11:36:48 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id DE51B2F005E; Fri, 7 Jun 2013 12:32:09 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id D470F2F005B; Fri, 7 Jun 2013 12:32:09 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 7 Jun 2013 12:36:48 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%11]) with mapi id 14.01.0438.000; Fri, 7 Jun 2013 12:36:47 -0400 From: "Ackermann, Michael" To: Nalini Elkins , "Joel M. Halpern" , Joe Touch Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOYG4EHn4XBQzX90KTpobgByNivpklDR0AgAAfDICAABbVAIAAlsuAgAAI24CAAAIRAIAAPfeAgAADQICAADbugIABGoaAgAAO6wCAAAo8AIAADRKAgAAh0gCAAAMXgIAACY6AgAAIHgCAAAGWgIAAAacAgAAFmQCAAAFTAIAAImUAgAB1XwCAAPj7AIAABGoAgAAFDwCAAAWTgIAAAUMAgABJoICAACadgIAAenOQ Date: Fri, 7 Jun 2013 16:36:47 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A779B72@PWN401EA160.ent.corp.bcbsm.com> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:36:54 -0000 A big ECHO from Blue Cross and the Health Industry in general, on the = comments below=21=21=21 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Nalini Elkins Sent: Friday, June 07, 2013 12:23 AM To: Joel M. Halpern; Joe Touch Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed Speaking of Ms. Elkins original topic, some of us in the real world have = used the old IPID field in IPv4 as a packet sequence number to do = diagnostics more quickly even though it was not intended as such. =A0 In = the real world, you do what you have to to keep your network running and = solve problems. =A0Theory goes out the window when real users are involved. This is why we want the new implementation of the destination options = header that we have defined. =A0=A0 If I might, I seem to sense that some of the people on this list possibly = may not really understand or may not have much sympathy for the kind of = pressure we are under to solve problems quickly and to meet service level = requirements for performance. =A0If you can think of the type of networks = our team runs - the health care networks, the banking sector, the stock = markets, you can see that we diagnosticians have a lot of pressure on us. I understand that there are a number of issues with IPv6 extension = headers, no real RFCs for middle boxes, and the ASIC issue. =A0And, = tomorrow (or Saturday) when I can get away from actual work, I will = respond on the very good discussion on the 6man list = on=A0draft-ietf-6man-ext-transmit-01.txt. =A0 Definitely, these are very = critical points. =A0And, if we can help in any way to help in creating = standards to address these issues, we stand ready and willing to help in = any way possible. =A0I feel sure that these problems will be solved in the = future. We would really appreciate support for what we are asking for which is a = way for us to solve our chronic operational problems which we are afraid = will get worse with IPv6. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: Joel M. Halpern To: Joe Touch Cc: v6ops=40ietf.org Sent: Thursday, June 6, 2013 7:04 PM Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed In a formal sense Joe, you are correct.=A0 There is no formal requirement = in IPv6 for Layer 4 visibility to routers. And one can argue that firewalling should be done in specialized boxes.=A0 = I tend to disagree, but that is not the point. Even without firewalls, there is a current, real world, operational need = for almost all routes to be able to find layer 4 information.=A0 Operators = depend upon effective ECMP (and at layer 2, LAG) operation. While I would like things to work better (for example, by putting the = needed information into the flow label), current deployments can not = depend upon such an unspecified and undeployed host behavior. As such, real world deployed routers depend upon being able to find L4 = information.=A0 Some devices can chase all the header chains, so that = requiring L4 be in the packet is sufficient.=A0 Many routers have limits = on what they can chase. Claiming that the reasonable and effective limitations people have had to = put in place are =22wrong=22 and vendors should stop doing that, requires = that there be an answer to the issue. Yours, Joel PS: This seems largely orthogonal to Ms. Elkins original topic. On 6/6/2013 5:41 PM, Joe Touch wrote: >=20 >=20 > On 6/6/2013 2:36 PM, Havard Eidnes wrote: >>>> And therein lies the problem. As pointed out by Nick Hilliard and=20 >>>> myself, we *need* those stateless firewall functions, which may=20 >>>> need to look up stuff way beyond the destination address. I don't=20 >>>> find a discussion of whether such functions *should* be needed in a=20 >>>> router or not all that relevant. >>>=20 >>> Just as I don't find a discussion of how much the cost to implement=20 >>> such functions makes the life of router venders more complex. >>>=20 >>> If the kitchen is too hot... >>=20 >> That's one vantage point.=A0 Another would be one which talks about=20 >> ivory towers and losing touch with what is practically possible now. >=20 > If it's possible, then there's no problem. >=20 > What you're all suggesting here are ways to limit IPv6 to make it more=20 > convenient for router vendors to implement various features that were=20 > never part of the design (of either the Internet architecture nor of > IPv6 in specific). >=20 > If you want to make sure that IP supports efficient router parsing of=20 > L4 header information, IMO you can take that up when we design IPv7,=20 > but it was never a requirement of IPv6. Assuming it now is - as you=20 > are all discussing - impractical. >=20 > Joe > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From mackermann@bcbsm.com Fri Jun 7 09:36:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19D421F96EB for ; Fri, 7 Jun 2013 09:36:56 -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 ZfmOBwCVAfUg for ; Fri, 7 Jun 2013 09:36:50 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDED21F965B for ; Fri, 7 Jun 2013 09:36:50 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 63BF32FF6E1 for ; Fri, 7 Jun 2013 11:36:50 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 381F830752A; Fri, 7 Jun 2013 11:36:49 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 4D19F2F0053; Fri, 7 Jun 2013 12:32:10 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 3E4122F004F; Fri, 7 Jun 2013 12:32:10 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0438.000; Fri, 7 Jun 2013 12:36:48 -0400 From: "Ackermann, Michael" To: Lorenzo Colitti , Nalini Elkins Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOYG4EHn4XBQzX90KTpobgByNivpklDR0AgAAfDICAABbVAIAAlsuAgAAI24CAAAIRAIAAPfeAgAADQICAADbugIABGoaAgAAO6wCAAAo8AIAADRKAgAAh0gCAAAMXgIAACY6AgAAIHgCAAAGWgIAAAacAgAAFmQCAAAFTAIAAImUAgAB1XwCAAPj7AIAABGoAgAAFDwCAAAWTgIAAAUMAgABJoICAACadgIAAGsKAgABgFkA= Date: Fri, 7 Jun 2013 16:36:47 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A779B80@PWN401EA160.ent.corp.bcbsm.com> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A779B80PWN401EA160entc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:36:58 -0000 --_000_4FC37E442D05A748896589E468752CAA0A779B80PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to tack on that most of our networks are not closed to the = degree you might expect. More and more of our connections are client = VPN's or Peer to Peer VPN's over the Internet. So we are VERY interested = in that path as well=21 Secondly, we do NOT expect that ANYTHING in this space will happen = quickly. But if it is right and best, we are more than willing to put in = the related time and effort to attain the strategic value our business = demand. Band aids usually fall off=21 :) From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Lorenzo Colitti Sent: Friday, June 07, 2013 1:59 AM To: Nalini Elkins Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On Fri, Jun 7, 2013 at 1:23 PM, Nalini Elkins = > wrote: If I might, I seem to sense that some of the people on this list possibly = may not really understand or may not have much sympathy for the kind of = pressure we are under to solve problems quickly and to meet service level = requirements for performance. If you can think of the type of networks = our team runs - the health care networks, the banking sector, the stock = markets, you can see that we diagnosticians have a lot of pressure on us. Agreed. But all those networks are highly specialized, highly closed, and = highly integrated, and the solutions that are appropriate for them might = not be appropriate for the general Internet. Also, if you want to solve this problem quickly, then... well, an = extension header is not a good idea, because it has to be implemented at = the lowest level possible (the host operating system). If you need a quick = solution, then what you want is the sequence number field in the GRE header. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A779B80PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

    Just wanted to tack on that most of our = networks are not closed to the degree you might expect.   More = and more of our connections  are client VPN&=238217;s or Peer to Peer VPN&=238217;s over the Internet.   So we are VERY = interested in that path as well=21 

     

    Secondly, we do NOT expect that ANYTHING in = this space will happen quickly.   But if it is right and best, = we are more than willing to put in the related time and effort to attain the strategic value our business demand.  =    Band aids usually fall off=21 J

     

    From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Lorenzo Colitti
    Sent: Friday, June 07, 2013 1:59 AM
    To: Nalini Elkins
    Cc: v6ops=40ietf.org
    Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed

     

    On Fri, Jun 7, 2013 at 1:23 PM, Nalini Elkins = <nalini.elkins=40insidethestack.com> = wrote:

    If I might, I seem to sense that some of the = people on this list possibly may not really understand or may not have = much sympathy for the kind of pressure we are under to solve problems = quickly and to meet service level requirements for performance.  If you can think of the type of networks our team runs = - the health care networks, the banking sector, the stock markets, you can = see that we diagnosticians have a lot of pressure on us.

     

    Agreed. But all those networks are highly = specialized, highly closed, and highly integrated, and the solutions that = are appropriate for them might not be appropriate for the general = Internet.

     

    Also, if you want to solve this problem = quickly, then... well, an extension header is not a good idea, because it = has to be implemented at the lowest level possible (the host operating = system). If you need a quick solution, then what you want is the sequence number field in the GRE header.


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

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

    --_000_4FC37E442D05A748896589E468752CAA0A779B80PWN401EA160entc_-- From nalini.elkins@insidethestack.com Fri Jun 7 10:07:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00F21F947C for ; Fri, 7 Jun 2013 10:07:39 -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 RBoiDoYbnZET for ; Fri, 7 Jun 2013 10:07:33 -0700 (PDT) Received: from nm24.access.bullet.mail.sp2.yahoo.com (nm24.access.bullet.mail.sp2.yahoo.com [98.139.44.151]) by ietfa.amsl.com (Postfix) with ESMTP id 55E9A21F8FBE for ; Fri, 7 Jun 2013 10:07:29 -0700 (PDT) Received: from [98.139.44.105] by nm24.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 17:07:27 -0000 Received: from [98.139.44.91] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 17:07:27 -0000 Received: from [127.0.0.1] by omp1028.access.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 17:07:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 289304.71597.bm@omp1028.access.mail.sp2.yahoo.com Received: (qmail 65069 invoked by uid 60001); 7 Jun 2013 17:07:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370624846; bh=iTk5ZYXIUZsH/J6Jun1bOIyRPNMGMBEjTUMsUujyHwE=; 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=tWE4KeWMunSIBb6p3b3z3Y5w1RTvWxqskw8yIUoDqtf2xlQhWVH6X/sBozfKpdfJreOLAjWw4pJGqHE0LrrlPfXScY4QflNdZZOsHlalrJY5JOiONEEuhs8ZYP165mwtb3XDdQP0+ToWzC+sNBgLcPF38bbqfo9N9CPzPzCfLl8= X-YMail-OSG: IRPo9vMVM1m9cWNROtmmuppF8._WAgpW0ys9PixmvWlOf8Z l3hIGn2UyC1jd0MP_46AR1Zw9cdKkQJciLULPLruVVl_hgMnUN7TuOsEVGb6 untKUAsAnTAxEHhMEyFBfzX8XLnZNq.BQiYXFKlZ79vrAhIvYEDuznR8.KxD Lik4boUbEFLW0wNwjsQ9MDPLjXFq4G056GF8uYuLyeDls9MSoVpRV7cjIjlP hqgiA.hriA4U7kTrbujSC0B4YXiALR5C8r2Qpxd5zs9ZXGBuST6kEI4kuI65 H.nY0krSpZx2iqNZdjwQsncIM2ShpEIQsrasDvBZHdcgWURk9btdcBYOTzGI mZV.beXQ2EWua8DRGyi6_.fGbq9xO6MpuGKk7YTlifUfkY83GvwIReMANolE .K0VRAGgk1GaSzx4PTYXdzdJN1YtAxiMFnDZZ2uMWs00pl4w.7tbEQ_eg.Jw PxE_Z5EHGIevAj7ZaBzsl.tBgDW0tkdV4G76nOsDzBdtTMnwiNQU7tKMz.eN buwrZNrLANcxDDJ7fGIYWubSikaQaWREzR2Pdy26ZFiPo8dGmLqVtVo5wygh afQPhwtCphTRL38QaxIUok2dGRGLH5baP_UCvZfE28vFx81iVOLDHRqAd4Pl IevN80zbC7IlDAmDBstewhMY- Received: from [76.248.166.145] by web2806.biz.mail.ne1.yahoo.com via HTTP; Fri, 07 Jun 2013 10:07:26 PDT X-Rocket-MIMEInfo: 002.001, Pj5TbywgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsIGJ1dCBpc24ndCB0aGlzIGRpc2N1c3Npb24gdGhlbiBhYm91dMKgCgo.PiDCoCDCoHdoYXQgZG8geW91IHByb3Bvc2UgdG8gcHV0IGluIHRoZSBIQkggaGVhZGVyLMKgCj4.IMKgIMKgYW5kIGlzIGl0IHNhZmUgYW5kIHdvcnRoIHRoZSBjb3N0PwoKV2VsbCwgd2UgYXJlIGFjdHVhbGx5IHVzaW5nIHRoZSBEZXN0aW5hdGlvbiBPcHRpb25zIGhlYWRlciBhbmQgbm90IGhvcC1ieS1ob3AuIMKgQnV0LCBzYW1lIHBvaW50cy4KCj4.QnV0IGlnbm9yaW5nIHBhY2sBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Message-ID: <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 10:07:26 -0700 (PDT) From: Nalini Elkins To: Joe Touch In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1295230723-1370624846=:64794" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:07:39 -0000 --1510626085-1295230723-1370624846=:64794 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>So, correct me if I'm wrong, but isn't this discussion then about=A0=0A= =0A>> =A0 =A0what do you propose to put in the HBH header,=A0=0A>> =A0 =A0a= nd is it safe and worth the cost?=0A=0AWell, we are actually using the Dest= ination Options header and not hop-by-hop. =A0But, same points.=0A=0A>>But = ignoring packets that use the chained headers that follow is a non-starter = for IPv6.=0A=0A=0AYES!!!!! =A0 Could not agree more! =A0 So now academia an= d those of us with our hands completely dirty are in complete agreement. = =A0There must be some kind of alignment of the stars or something!=0A=A0=0A= Thanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Aww= w.insidethestack.com=0A=0A=0A=0A________________________________=0A From: J= oe Touch =0ATo: Nalini Elkins =0ACc: Joel M. Halpern ; "v6ops@ietf.org" =0ASent: Friday, June 7, 2013 7:43 AM=0ASubject: Re: [v6ops] new = draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn Jun 6, 2= 013, at 9:23 PM, Nalini Elkins wrote:=0A= =0A> Speaking of Ms. Elkins original topic, some of us in the real world ha= ve used the old IPID field in IPv4 as a packet sequence number to do diagno= stics more quickly even though it was not intended as such.=A0 In the real= world, you do what you have to to keep your network running and solve prob= lems.=A0 Theory goes out the window when real users are involved.=0A> =0A> = This is why we want the new implementation of the destination options heade= r that we have defined. =0A=0AThe old IPv4 ID field never did support diagn= ostics correctly, because:=0A=0A=A0=A0=A0 - they were never intended for di= agnostics at all=0A=0A=A0=A0=A0 - vendors decided it was too much work to g= enerate unique IDs correctly:=0A=A0=A0=A0 =A0=A0=A0 - endpoints that want t= o go faster than a few Mbps=0A=A0=A0=A0 =A0=A0=A0 - NATs that want less sta= te=0A=A0=A0=A0 =A0=A0=A0 - cellphones that want even less state=0A=0ASo bas= ically the device vendors decided they should make more money, at the expen= se of the diagnostics vendors.=0A=0AA similar tension happened when IPv6 wa= s being designed, and the compromise was to put everything a router needed = in either the main header or the HBH header.=0A=0APutting more there - a ho= stID, packetID, or a copy of the transport ports - is the same tension betw= een those who want to build "cheaper than chasing a chain" routers vs. thos= e who want endpoints that run fast, can be implemented cheaply, or are secu= re (against DOS attacks, or just implement privacy).=0A=0ASo, correct me if= I'm wrong, but isn't this discussion then about =0A=0A=A0=A0=A0 what do yo= u propose to put in the HBH header, =0A=A0=A0=A0 and is it safe and worth t= he cost?=0A=0ABut ignoring packets that use the chained headers that follow= is a non-starter for IPv6.=0A=0AJoe --1510626085-1295230723-1370624846=:64794 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    >>So, correct me if I'm wrong, = but isn't this discussion then about 

    >= ;>    what do you propose to put in the HBH header, 
    >>    and is it safe = and worth the cost?

    Well, we are actually using the Destination Options header and = not hop-by-hop.  But, same points.

    >>But ignoring packets that use the ch= ained headers that follow is a non-starter for IPv6.

    YES= !!!!!   Could not agree more!   So now academia and those of us w= ith our hands completely dirty are in complete agreement.  There must = be some kind of alignment of the stars or something!
     
    Thanks,

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

    <= div style=3D"font-family: 'times new roman', 'new york', times, serif; font= -size: 12pt;">
    From: Joe Touch <touch@= isi.edu>
    To: Nalini= Elkins <nalini.elkins@insidethestack.com>
    Cc: Joel M. Halpern <jmh@joelhalpern.com>;= "v6ops@ietf.org" <v6ops@ietf.org>
    Sent: Friday, June 7, 2013 7:43 AM
    Subject: Re: [v6ops] new draft: draft-el= kins-v6ops-ipv6-end-to-end-rt-needed

    =0A
    On Jun 6, 2013, at 9:23 PM, Nalini Elkins <nalini.elkins@insidethestack.com> wrote:
    <= br>> Speaking of Ms. Elkins original topic, some of us in the real world= have used the old IPID field in IPv4 as a packet sequence number to do dia= gnostics more quickly even though it was not intended as such.  In th= e real world, you do what you have to to keep your network running and solv= e problems.  Theory goes out the window when real users are involved.<= br>>
    > This is why we want the new implementation of the destinat= ion options header that we have defined.

    The old IPv4 ID field neve= r did support diagnostics correctly, because:

        - t= hey were never intended for diagnostics at all

        - = vendors decided it was too much work to generate unique IDs correctly:
            - endpoints that want = to go faster than a few Mbps
            - NAT= s that want less state
            - cellphone= s that want even less state

    So basically the device vendors decided = they should make more money, at the expense of the diagnostics vendors.
    =
    A similar tension happened when IPv6 was being designed, and the compro= mise was to put everything a router needed in either the main header or the= HBH header.

    Putting more there - a hostID, packetID, or a copy of t= he transport ports - is the same tension between those who want to build "c= heaper than chasing a chain" routers vs. those who want endpoints that run = fast, can be implemented cheaply, or are secure (against DOS attacks, or ju= st implement privacy).

    So, correct me if I'm wrong, but isn't this d= iscussion then about

        what do you propose to put in the HBH header,
        and is it safe and worth = the cost?

    But ignoring packets that use the chained headers that fol= low is a non-starter for IPv6.

    Joe

    --1510626085-1295230723-1370624846=:64794-- From warren@kumari.net Fri Jun 7 10:13:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F421F96FC for ; Fri, 7 Jun 2013 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.503 X-Spam-Level: X-Spam-Status: No, score=-101.503 tagged_above=-999 required=5 tests=[AWL=0.496, 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 r0kkUopqf7zl for ; Fri, 7 Jun 2013 10:13:19 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C336321F96EF for ; Fri, 7 Jun 2013 10:13:19 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id C76001B407DA; Fri, 7 Jun 2013 13:13:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <4FC37E442D05A748896589E468752CAA0A779B2F@PWN401EA160.ent.corp.bcbsm.com> Date: Fri, 7 Jun 2013 12:13:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <574F1AE9-BCFC-4E05-8116-F8547C664DFC@kumari.net> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A779B2F@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:13:24 -0000 On Jun 7, 2013, at 11:36 AM, "Ackermann, Michael" = wrote: > Agree strongly that ignoring packets that have chained headers (which = an intrinsic part of the protocol), will be a HUGE detriment to IPV6 = deployment in the real world. =20 >=20 > And regarding the comment about theory going out the window when it = conflicts with reality. Unfortunately TRUE DAT! But I am hopeful = that we are not too late to get theory to somewhat match reality here = and encourage (rather than discourage) IPV6 deployments. =20 If you are trying to encourage IPv6 deployment you need to consider the = cost of deployment, what the incremental cost of looking further into = the packet and what the value to the operators is. Simply saying "you need to to be formally correct" (or "to meet my niche = need") doesn't pay the bills. W >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Joe Touch > Sent: Friday, June 07, 2013 10:44 AM > To: Nalini Elkins > Cc: v6ops@ietf.org > Subject: Re: [v6ops] new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed >=20 >=20 > On Jun 6, 2013, at 9:23 PM, Nalini Elkins = wrote: >=20 >> Speaking of Ms. Elkins original topic, some of us in the real world = have used the old IPID field in IPv4 as a packet sequence number to do = diagnostics more quickly even though it was not intended as such. In = the real world, you do what you have to to keep your network running and = solve problems. Theory goes out the window when real users are = involved. >>=20 >> This is why we want the new implementation of the destination options = header that we have defined.=20 >=20 > The old IPv4 ID field never did support diagnostics correctly, = because: >=20 > - they were never intended for diagnostics at all >=20 > - vendors decided it was too much work to generate unique IDs = correctly: > - endpoints that want to go faster than a few Mbps > - NATs that want less state > - cellphones that want even less state >=20 > So basically the device vendors decided they should make more money, = at the expense of the diagnostics vendors. >=20 > A similar tension happened when IPv6 was being designed, and the = compromise was to put everything a router needed in either the main = header or the HBH header. >=20 > Putting more there - a hostID, packetID, or a copy of the transport = ports - is the same tension between those who want to build "cheaper = than chasing a chain" routers vs. those who want endpoints that run = fast, can be implemented cheaply, or are secure (against DOS attacks, or = just implement privacy). >=20 > So, correct me if I'm wrong, but isn't this discussion then about=20 >=20 > what do you propose to put in the HBH header,=20 > and is it safe and worth the cost? >=20 > But ignoring packets that use the chained headers that follow is a = non-starter for IPv6. >=20 > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- For every complex problem, there is a solution that is simple, neat, and = wrong. -- H. L. Mencken From mackermann@bcbsm.com Fri Jun 7 10:25:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0B221F994A for ; Fri, 7 Jun 2013 10:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ru+JjCNJ-Y for ; Fri, 7 Jun 2013 10:25:54 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 5072621F955A for ; Fri, 7 Jun 2013 10:25:41 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 0548D2FF70C for ; Fri, 7 Jun 2013 12:25:41 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id F2C0D3074FE; Fri, 7 Jun 2013 12:25:39 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id E96072F0043; Fri, 7 Jun 2013 13:21:00 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id DA47C2F0040; Fri, 7 Jun 2013 13:21:00 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 7 Jun 2013 13:25:39 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%11]) with mapi id 14.01.0438.000; Fri, 7 Jun 2013 13:25:38 -0400 From: "Ackermann, Michael" To: Warren Kumari Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed Thread-Index: AQHOYG4EHn4XBQzX90KTpobgByNivpklDR0AgAAfDICAABbVAIAAlsuAgAAI24CAAAIRAIAAPfeAgAADQICAADbugIABGoaAgAAO6wCAAAo8AIAADRKAgAAh0gCAAAMXgIAACY6AgAAIHgCAAAGWgIAAAacAgAAFmQCAAAFTAIAAImUAgAB1XwCAAPj7AIAABGoAgAAFDwCAAAWTgIAAAUMAgABJoICAACadgIAArVaA///KkUCAAF9EAP//vcXg Date: Fri, 7 Jun 2013 17:25:37 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A779D3B@PWN401EA160.ent.corp.bcbsm.com> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A779B2F@PWN401EA160.ent.corp.bcbsm.com> <574F1AE9-BCFC-4E05-8116-F8547C664DFC@kumari.net> In-Reply-To: <574F1AE9-BCFC-4E05-8116-F8547C664DFC@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:25:59 -0000 YES, I think we should consider costs of deployment. We (customers) = ultimately pay that price anyway. I assume you are talking here about = cost for router and firewall vendors to =22tool up=22 to fully support = IPV6. As more of us actually start to utilize IPV6, the vendors will = learn more and more about what that REALLY means and adapt to it. I = think the EH processing issue is a great example of that. =20 If router and Firewall vendors need to make changes to accommodate IPV6 = and/or customer requirements, I am sensitive to their related efforts and = costs, but it is what we must all do to survive and prosper. =20 And while I am appreciative of the time, effort and cost this will take on = one hand, I do not think that we should base planning for the = architectures and protocols of the future, on hardware limitations of the = past. =20 We ALL will be expending cost, effort and time to accommodate IPV6 and any = other fundamental changes we face. It will be in very different areas = for us, than for equipment vendors, but significant nonetheless. My = company isn't happy about it either, but it must be accepted. =20 -----Original Message----- From: Warren Kumari =5Bmailto:warren=40kumari.net=5D=20 Sent: Friday, June 07, 2013 1:13 PM To: Ackermann, Michael Cc: Warren Kumari; Joe Touch; Nalini Elkins; v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed On Jun 7, 2013, at 11:36 AM, =22Ackermann, Michael=22 = wrote: > Agree strongly that ignoring packets that have chained headers (which an = intrinsic part of the protocol), will be a HUGE detriment to IPV6 = deployment in the real world. =20 >=20 > And regarding the comment about theory going out the window when it = conflicts with reality. Unfortunately TRUE DAT=21 But I am hopeful = that we are not too late to get theory to somewhat match reality here and = encourage (rather than discourage) IPV6 deployments. =20 If you are trying to encourage IPv6 deployment you need to consider the = cost of deployment, what the incremental cost of looking further into the = packet and what the value to the operators is. Simply saying =22you need to to be formally correct=22 (or =22to meet my = niche need=22) doesn't pay the bills. W >=20 > -----Original Message----- > From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Joe Touch > Sent: Friday, June 07, 2013 10:44 AM > To: Nalini Elkins > Cc: v6ops=40ietf.org > Subject: Re: =5Bv6ops=5D new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed >=20 >=20 > On Jun 6, 2013, at 9:23 PM, Nalini Elkins = wrote: >=20 >> Speaking of Ms. Elkins original topic, some of us in the real world = have used the old IPID field in IPv4 as a packet sequence number to do = diagnostics more quickly even though it was not intended as such. In the = real world, you do what you have to to keep your network running and solve = problems. Theory goes out the window when real users are involved. >>=20 >> This is why we want the new implementation of the destination options = header that we have defined.=20 >=20 > The old IPv4 ID field never did support diagnostics correctly, because: >=20 > =09- they were never intended for diagnostics at all >=20 > =09- vendors decided it was too much work to generate unique IDs = correctly: > =09=09- endpoints that want to go faster than a few Mbps > =09=09- NATs that want less state > =09=09- cellphones that want even less state >=20 > So basically the device vendors decided they should make more money, at = the expense of the diagnostics vendors. >=20 > A similar tension happened when IPv6 was being designed, and the = compromise was to put everything a router needed in either the main header = or the HBH header. >=20 > Putting more there - a hostID, packetID, or a copy of the transport = ports - is the same tension between those who want to build =22cheaper = than chasing a chain=22 routers vs. those who want endpoints that run = fast, can be implemented cheaply, or are secure (against DOS attacks, or = just implement privacy). >=20 > So, correct me if I'm wrong, but isn't this discussion then about=20 >=20 > =09what do you propose to put in the HBH header,=20 > =09and is it safe and worth the cost? >=20 > But ignoring packets that use the chained headers that follow is a = non-starter for IPv6. >=20 > Joe > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- For every complex problem, there is a solution that is simple, neat, and = wrong. -- H. L. Mencken The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From warren@kumari.net Fri Jun 7 10:56:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F7821F996A for ; Fri, 7 Jun 2013 10:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.436 X-Spam-Level: X-Spam-Status: No, score=-101.436 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sTXdO8FTZuB for ; Fri, 7 Jun 2013 10:56:04 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D0521F9954 for ; Fri, 7 Jun 2013 10:56:03 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id 229F01B407DA; Fri, 7 Jun 2013 13:56:03 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <20130607.095033.74669945.sthaug@nethelp.no> Date: Fri, 7 Jun 2013 12:56:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <57377A7F-C870-4984-BB3B-38F790A174A9@kumari.net> References: <51B180B3.2090106@globis.net> <20130607.090624.19791724.he@uninett.no> <51B18AC1.5070403@globis.net> <20130607.095033.74669945.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1503) Cc: v6ops@globis.net, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:56:08 -0000 On Jun 7, 2013, at 2:50 AM, sthaug@nethelp.no wrote: >> How's that worse than today, where people are apparently dropping all >> packets containing any extension headers (because they're all soft >> switched)? >=20 > Also, remember there is plenty of hardware out there that doesn't *do* > soft switching at all. If a packet cannot be forwarded in hardware, it > is dropped. Yup. I think that plenty is actually "most deployed hardware with 10GB = interfaces". >=20 >> The basic idea being that we can optimize/facilitate hardware parsing >> further and further along the header chain by publishing additional >> informational RFCs, and at some point in the future we'll get enough >> extension headers supported together with hardware forwarding that = they >> become useful. I'd certainly like to be able to buy a firewall with = ASIC >> optimized forwarding of IPv6 (including extension headers). >=20 > I definitely think this is worth pursuing, as long as the point of not > creating a DoS vector is kept in mind. >=20 >> The alternative would seem to be a stalemate of continual shouting = from >> the ivory tower that hardware vendors just need to learn to live with >> arbitrary packet complexity, whilst operational people drop = everything >> containing an extension header so there's no market demand for the >> hardware vendors to do anything. >=20 > Or operational people voting with their wallets, and buying the box=20 > that kan "only" look 256 bytes into the header, because it is N% less > expensive than the box that can look a full 64 kByte into the header. Yup, and from talking to vendors, N is *large*.=20 The big issue here isn't so much complexity of building ASICs that can = parse the linked-list, it is the cost (bandwidth and memory) of dragging = the headers up to the ASIC so that it can be inspected.=20 This may take us down (yet another) rat-hole where folk express surprise = at the cost of widgets, discussions on the actual cost vs discounted = cost, If you can afford to pay X, you can afford X+10% (or 2*X), = router-architecture, but I think it is worth folk having *some* = understanding of the costs here. Using public info: Here is the example 'show chassis hardware models' for a Juniper T1600 = from Juniper's site: = http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/tas= k/operational/t4000-upgrade-verify-t640-t1600-components.html and using = prices published here: = http://www.technicacorp.com/federal/contracts/nasa_sewpiv/sewp_search?manu= facturer=3DJuniper%20Networks,%20Inc. We get:=20 QTY DESC List Total Comment 3 T1600-FPC4-ES "$300,000.00" "$900,000.00" 1 T640-FPC2-E2 "$71,100.00" "$71,100.00" 1 T640-FPC1-E2 "$47,400.00" "$47,400.00" 1 T640-FPC3-E "$118,500.00" "$118,500.00" 1 T640-FPC3 $0.00 $0.00 Could not easily find public = price. 5 SIB-I-T1600-S "$50,000.00" "$250,000.00" 3 PC-8GE-TYPE3-SFP-IQ2 "$120,000.00" "$360,000.00" 2 PD-4XGE-XFP "$250,000.00" "$500,000.00" 2 PC-4OC48-SON-SFP "$205,000.00" "$410,000.00" 2 PC-1XGE-TYPE3-XFP-IQ2 "$141,000.00" "$282,000.00" 2 PC-10GE-SFP "$120,000.00" "$240,000.00" 2 PB-1OC48-SON-SMSR $0.00 $0.00 Could not easily find = public price. 1 CB-T-S "$9,000.00" "$9,000.00" 1 SCG-T-S "$5,000.00" "$5,000.00" 1 PD-4OC192-SON-XFP "$660,000.00" "$660,000.00" 1 PD-1OC768-SON-SR "$620,000.00" "$620,000.00" 1 PD-1CE-CFP-FPC4 "$650,000.00" "$650,000.00" 1 PC-TUNNEL "$120,000.00" "$120,000.00" 1 PC-1OC192-SON-VSR "$125,000.00" "$125,000.00" 1 PC-1OC192-SON-SR2 $0.00 $0.00 Could not easily find = public price. 1 PB-4OC12-SON-SMIR-REFURB "$20,000.00" "$20,000.00" = Refurb 1 PB-4GE-TYPE1-SFP-IQ2 "$32,000.00" "$32,000.00" 1 PB-4GE-SFP "$58,000.00" "$58,000.00" 1 PB-1CHOC12SMIR-QPP "$67,150.00" "$67,150.00" Total "$5,545,150.00" This is for a large box, but not the most expensive-- it is also missing = a control plane, the actual chassis / backplane, power, etc (I got = bored). Cisco pricing is similar - = http://www.cisco.com/web/strategy/government/wsca/pricelist_archive.html = Feel free to find 'show diag' for a CRS-1 (or -3) and do your own = calculations=85 In the real world (what we are talking about here!), everyone gets a = reasonable discount off list prices, but that discount is far from 100% = :-P What percentage more should I be willing to pay to be formally correct / = RFC compliant? Or to support some niche use? How do I justify spending = an additional X% to my bean-counters? What value can I point at? Seeing = as things are working just fine without extensions headers at the = moment, and the Internet Protocol Police have no enforcement power, it = is very hard to justify any X, let alone the type of X that I've heard = from vendors=85. And no, additional bits in my packets for diagnostics is not the value = here, I'm managing just fine without them, thanks though. Yes, 'tis sad when the development of protocols / deployment of features = is impacted by business[0] considerations -- welcome to the real world. W [0]: Or by physics ( like C / thermodynamics), or by technology (like = power and cooling), or by politics, or by IPR, or by legacy = considerations, or ... >=20 > Steinar Haug, AS 2116 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- "Go on, prove me wrong. Destroy the fabric of the universe. See if I = care." -- Terry Prachett=20 From touch@isi.edu Fri Jun 7 10:59:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECC621F997E for ; Fri, 7 Jun 2013 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.882 X-Spam-Level: X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=-0.283, 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 pJHcC4mLBCRZ for ; Fri, 7 Jun 2013 10:59:17 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 201D921F9983 for ; Fri, 7 Jun 2013 10:59:17 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r57Hwh4v023092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 10:58:43 -0700 (PDT) Message-ID: <51B21F57.2000705@isi.edu> Date: Fri, 07 Jun 2013 10:58:47 -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: Nalini Elkins References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:59:23 -0000 On 6/7/2013 10:07 AM, Nalini Elkins wrote: >>>So, correct me if I'm wrong, but isn't this discussion then about > >>> what do you propose to put in the HBH header, >>> and is it safe and worth the cost? > > Well, we are actually using the Destination Options header and not > hop-by-hop. But, same points. Well, HBH is the *correct* place to put things that are examined per-hop ;-) >>>But ignoring packets that use the chained headers that follow is a non-starter for IPv6. > > YES!!!!! Could not agree more! So now academia and those of us with > our hands completely dirty are in complete agreement. There must be > some kind of alignment of the stars or something! FWIW, ISI may be part of USC, but I've seen more academic positions in industry. Joe From repenno@cisco.com Fri Jun 7 11:09:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF25C21F9600; Fri, 7 Jun 2013 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBGr+x+1mzqF; Fri, 7 Jun 2013 11:09: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 7EF7321F8F6E; Fri, 7 Jun 2013 11:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20455; q=dns/txt; s=iport; t=1370628548; x=1371838148; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ndEDmyQo9qlHKOw7hms0yEu0UUNZRTfZAnGj/jkBQ7I=; b=BXp/RoWewM3LprHPGBAp3OqnKesd1+R4XSRPtXbnf6+s9eOcINwhLSAq dq//fqCfNq1AdwIDywJA+nKfFtuvJl+QzMHqG3aJCQkuX88FMaeMaNzfj Fw9IHrARfILxpgnWDftXymyb6Sz3JlsT76FKV5+GvgJau6fDBXvaOSiD9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACAhslGtJV2b/2dsb2JhbABZDgiCL0Qwvm+BABZ0giMBAQEDAQEBASpBCwUHBgEIEQMBAQEBCh0uCxQJCAIEAQ0FCAGHfgYMvHKNdgEJAYEGIA0EBgEGgnVhA5Nuj3OFIYJRPoFoAQgXHw X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="scan'208,217";a="220192563" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jun 2013 18:09:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r57I97vW024157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 18:09:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 13:09:06 -0500 From: "Reinaldo Penno (repenno)" To: "Poscic, Kristian (Kristian)" , "John Mann" , "Rajiv Asati (rajiva)" Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOY5e6wCO8rb0sYUquZ4EU6EXcyJkqvn+A///wB4A= Date: Fri, 7 Jun 2013 18:09:06 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A28CA@xmb-rcd-x04.cisco.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB410F8@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.76] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:09:14 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are certain port allocation methods where extending the port block is= tricky, such as (Stateless) Deterministic NAT. From: "Poscic, Kristian (Kristian)" > Date: Fri, 7 Jun 2013 16:06:13 +0000 To: John Mann >, "Rajiv A= sati (rajiva)" > Cc: "Softwires-wg list (softwires@ietf.org)" >, "v6ops@ietf.org" >, "behave@ietf.org" >, "Dan Wing (dw= ing)" > Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? But why is this a problem in CGN? You initially allocate a port block of 500ports to the subscriber and then = they can dynamically extend this on as needed basis (allocate a new port bl= ock). To me the value of this exercise is to determine what will this initial por= t block size be, not at which point the service will be denied since this c= an be easily extended. For RGs, it is what it is, if they have the limit of 500mapping, then yes, = this is the problem. But for CGN it shouldn=92t be. From: behave-bounces@ietf.org [mailto:behav= e-bounces@ietf.org] On Behalf Of John Mann Sent: Thursday, June 06, 2013 5:02 PM To: Rajiv Asati (rajiva) Cc: Softwires-wg list (softwires@ietf.org); v6op= s@ietf.org; behave@ietf.org;= Dan Wing (dwing) Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) > wrote: Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times I think a more-interesting statistic would be "how many connection setups w= ould have failed". But I don't think you can measure that just by polling concurrent connectio= ns at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" wo= uld be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then repo= rt that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@i= etf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. > > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. > > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. > > -d > > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ Behave mailing list Behave@= ietf.org https://www.ietf.org/mailman/listinfo/beha= ve --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    There are certain port allocation methods where extending the port blo= ck is tricky, such as (Stateless) Deterministic NAT.


    From: "Poscic, Kristian (Krist= ian)" <kristi= an.poscic@alcatel-lucent.com>
    Date: Fri, 7 Jun 2013 16:06:13 += ;0000
    To: John Mann <john.mann@monash.edu>, "Rajiv Asati (raj= iva)" <rajiva@cisco.com>=
    Cc: "Softwires-wg list (softwires@ietf.org)" <softwires@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "behave@ietf.org" <behave@ietf.org>, "Dan Wing (dw= ing)" <dwing@cisco.com> Subject: Re: [BEHAVE] [v6ops] Home = NAPT44 - How many ports?

    But why is this a problem in CGN?<= o:p>

    You initially allocate a port bloc= k of 500ports to the subscriber and then they can dynamically extend this o= n as needed basis (allocate a new port block).

     

    To me the value of this exercise i= s to determine what will this initial port block size be, not at which poin= t the service will be denied since this can be easily extended.

     

    For RGs, it is what it is, if they= have the limit of 500mapping, then yes, this is the problem.

    But for CGN it shouldn=92t be.

     

    From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of John Mann
    Sent: Thursday, June 06, 2013 5:02 PM
    To: Rajiv Asati (rajiva)
    Cc: Softwires-wg list (softwir= es@ietf.org); v6ops@ietf.org; behave@ietf.org; Dan Wing (dwing)
    Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports?

     

    Hi,

     

    On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> w= rote:

    Hi Dan,


    > and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
    > limit would interfere with your network use on those days.<= /p>

    I based that statement ("...seems ok,") on= the very fact that the number of times the NAT utilization exceeded 500 ma= ppings (equating to 500 ports, in my setup) in the sample period (~2 months= ) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok f= or 99% of the time and degraded 1% of the time. This is an important consid= eration, IMO.

    For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

    June 3 - 1 time
    May 29 - 1 time
    May 28 - 3 times
    May 26 - 1 time
    May 23 - 1 time
    May 22 - 2 times
    May 21 - 3 times

     

    I think a more-interesting statistic would be "= how many connection setups would have failed".

    But I don't think you can measure that just by polli= ng concurrent connections at specific times.

    It might take e.g. netflow exporting and analysis ..= .

     

    However "number of concurrent connections that = couldn't have been setup" would be useful in gauging the imp= act

    e.g. on May 29 there was one spike of 734 concurrent= connections, then report that as 234 potential failures.

     

    Of course, 1000 ports (resulting in 1000+ mappin= gs) would have been more than enough to accommodate the times when the mapp= ings exceeded 500, but stayed within 1000 (except once).



    > What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.<= /p>

     

    Is that a combined limit of TCP and UDP and ICMP, or= independent?

     

    My NAPT device seemingly can use upto 64K ports. :)<= br>
    Cheers,
    Rajiv



    > -----Original Message-----
    > From: Dan Wing (dwing)
    > Sent: Thursday, June 06, 2013 11:43 AM
    > To: Rajiv Asati (rajiva)

    > Cc: v6ops@iet= f.org; Softwires-wg list (softwir= es@ietf.org);
    > behave@ietf.org; Erik Kline (ek@google.com)
    > Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
    >
    >

    > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva= ) <rajiva@cisco.com> wrote: >
    > > Some of you may recall our discussion (during the last IETF) arou= nd "how
    > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
    > A+P paradigm. ~500, ~1000, ~3000???
    > >
    > > Well, I started monitoring my home router and plotting the NAPT44= port
    > utilization on a minute-by-minute basis. You may find it here -
    > http://= www.employees.org/~rajiva
    > >
    > > In short, port range of 500 seems ok, though 1000 would be more t= han
    > enough for my home.
    >
    > I see several spikes in your data over 500 ports.  During those t= imes,
    > applications would be unable to function (unable to get a port).  = ;April 29/30
    > is a long time where that occurs very visibly, but there are shorter s= pikes
    > elsewhere such as on April 17 and April 18.  If you had only 500 = ports on
    > those days, creating a new TCP mapping would have been impossible,
    > impacting ability to send or receive email, order books from Amazon.co= m,
    > and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
    > limit would interfere with your network use on those days.
    >
    > What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
    >
    > -d
    >
    > > Suffice to say, this is just a sample representation, since the p= ort
    > utilization would vary home to home, based on number of active devices= ,
    > type of applications, the degree of simultaneous device or application=
    > usage etc.
    > >
    > > If any of you are doing similar monitoring, then please share. > >
    > > Cheers,
    > > Rajiv
    > >
    > > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
    > google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
    > helping me out significantly.
    > >
    > > PS: My home has 3-4 active devices.
    > > _______________________________________________
    > > Behave mailing list
    > > Behave@ietf.org
    > > https://www.ietf.org/mailman/listinfo/behave

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

     

    _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave     --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_-- From touch@isi.edu Fri Jun 7 11:15:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4516421F9050 for ; Fri, 7 Jun 2013 11:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.842 X-Spam-Level: X-Spam-Status: No, score=-102.842 tagged_above=-999 required=5 tests=[AWL=-0.243, 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 ISZ7X-iAIILn for ; Fri, 7 Jun 2013 11:15:22 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 73C2821F990D for ; Fri, 7 Jun 2013 11:15:16 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r57IEpNl029148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 11:14:51 -0700 (PDT) Message-ID: <51B2231F.40203@isi.edu> Date: Fri, 07 Jun 2013 11:14:55 -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: Nalini Elkins References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> In-Reply-To: <51B21F57.2000705@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:15:28 -0000 Hi, all, In the spirit of moving towards a solution, here's my understanding of the problems: 1. the need for load balancing - if packets had true E2E addresses, those addresses would be sufficient for load-balancing - NATs and tunnels interfere with address-based loadbal, so another solution needs to be found - that other solution typically uses L4 port info >> solution: - NATs should copy the L4 port pair to a HBH 'hostmux' ID NATs want the revenue of being an L4 device, and they need L4 info to accomplish this anyway, so they already do this work - tunnel ingresses should copy the inner L3 pair to the hostmux ID 2. the need for L4 port filtering or traffic differentiation >> solution: - parse the whole L4 header in the router; you want the revenue of calling yourself an L4 device, so you need to do the work to earn it ;-) Joe From sthaug@nethelp.no Fri Jun 7 11:22:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07BD21F8FE5 for ; Fri, 7 Jun 2013 11:22:57 -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 utH6FHeJWEDP for ; Fri, 7 Jun 2013 11:22:52 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 5AFFA21F96E4 for ; Fri, 7 Jun 2013 11:22:52 -0700 (PDT) Received: (qmail 19745 invoked from network); 7 Jun 2013 18:22:49 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 Jun 2013 18:22:49 -0000 Date: Fri, 07 Jun 2013 20:22:49 +0200 (CEST) Message-Id: <20130607.202249.74735013.sthaug@nethelp.no> To: nalini.elkins@insidethestack.com From: sthaug@nethelp.no In-Reply-To: <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> References: <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:22:58 -0000 > >>But ignoring packets that use the chained headers that follow is a = non-starter for IPv6. > = > = > YES!!!!! =A0 Could not agree more! =A0 So now academia and those of u= s with our hands completely dirty are in complete agreement. =A0There m= ust be some kind of alignment of the stars or something! Not sure how much further we're going to get in this discussion. In = any case, I disagree at least to some degree with the top statement here: - I have a significant number of routers doing IPv6 forwarding in hardware today. These routers may not necessarily be able to chase long IPv6 header chains to find the L4 info. - Given a choice between 1) finding the L4 info within that part of the IPv6 header chain my routers *can* inspect (so that I can secure my network) and 2) ignoring (dropping) a packet with a long IPv6 header chain - I'm going to drop the packet. Every time. I'm not going to throw out my current equipment. I may be able to put in stronger requirements on chasing long IPv6 header chains for later purchases - but I'm *not* going to request the ability to inspect 64k bytes into the packet. Steinar Haug, AS 2116 From touch@isi.edu Fri Jun 7 11:30:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2DB21F9925 for ; Fri, 7 Jun 2013 11:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.812 X-Spam-Level: X-Spam-Status: No, score=-104.812 tagged_above=-999 required=5 tests=[AWL=1.788, 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 lN535uul76NN for ; Fri, 7 Jun 2013 11:30:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BFB9621F8FEB for ; Fri, 7 Jun 2013 11:30:35 -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 r57ITpdP028766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 11:29:51 -0700 (PDT) Message-ID: <51B22696.80503@isi.edu> Date: Fri, 07 Jun 2013 11:29: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: sthaug@nethelp.no References: <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <20130607.202249.74735013.sthaug@nethelp.no> In-Reply-To: <20130607.202249.74735013.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:30:41 -0000 On 6/7/2013 11:22 AM, sthaug@nethelp.no wrote: >>>> But ignoring packets that use the chained headers that follow is a non-starter for IPv6. >> >> >> YES!!!!! Could not agree more! So now academia and those of us >> with our hands completely dirty are in complete agreement. There >> must be some kind of alignment of the stars or something! > > Not sure how much further we're going to get in this discussion. In > any case, I disagree at least to some degree with the top statement > here: > > - I have a significant number of routers doing IPv6 forwarding in > hardware today. These routers may not necessarily be able to chase > long IPv6 header chains to find the L4 info. As long as those devices parse the main header and HBH options, that's fine. If what you *need* was for them to find L4 info in general, then you need to buy a better router, IMO. > - Given a choice between 1) finding the L4 info within that part of > the IPv6 header chain my routers *can* inspect (so that I can secure > my network) and 2) ignoring (dropping) a packet with a long IPv6 > header chain - I'm going to drop the packet. Every time. Which is your decision, but then if you were my ISP I'd find another ISP. > I'm not going to throw out my current equipment. > > I may be able to put in stronger requirements on chasing long IPv6 > header chains for later purchases - but I'm *not* going to request > the ability to inspect 64k bytes into the packet. That is your *business* decision, but it doesn't magically make the use of chained headers incorrect or inappropriate, unless the market decides to keep using you as their ISP. Joe From v6ops@globis.net Fri Jun 7 12:10:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2961421F99A1 for ; Fri, 7 Jun 2013 12:10:50 -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.572, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUCobOPfi2Jv for ; Fri, 7 Jun 2013 12:10:49 -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 CFAA521F9990 for ; Fri, 7 Jun 2013 12:10:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 01F7A8700EC; Fri, 7 Jun 2013 21:10:33 +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 weiaqMg5B8oO; Fri, 7 Jun 2013 21:10:32 +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 C649287002E; Fri, 7 Jun 2013 21:10:32 +0200 (CEST) Message-ID: <51B23022.1020401@globis.net> Date: Fri, 07 Jun 2013 21:10:26 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Warren Kumari References: <51B180B3.2090106@globis.net> <20130607.090624.19791724.he@uninett.no> <51B18AC1.5070403@globis.net> <20130607.095033.74669945.sthaug@nethelp.no> <57377A7F-C870-4984-BB3B-38F790A174A9@kumari.net> In-Reply-To: <57377A7F-C870-4984-BB3B-38F790A174A9@kumari.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 19:10:50 -0000 Thanks for the reply. Inline. > Warren Kumari > 7 June 2013 19:56 > On Jun 7, 2013, at 2:50 AM, sthaug@nethelp.no wrote: > >>> How's that worse than today, where people are apparently dropping all >>> packets containing any extension headers (because they're all soft >>> switched)? >> Also, remember there is plenty of hardware out there that doesn't *do* >> soft switching at all. If a packet cannot be forwarded in hardware, it >> is dropped. > > Yup. I think that plenty is actually "most deployed hardware with 10GB interfaces". OK. If we make a gross assumption that RFC 6437/6438 could "fix" the core devices at 10Gbps and above, by replacing their requirements to look at L4 headers with the flow label in the main IPv6 header [ECMP, LAG, other load balancing use cases] What about all the 1Gbps devices and below? The great unwashed at the edge? There's plenty of devices in enterprise networks that also need access to L4 headers apart from for LAG and ECMP use cases. And they need to work at wire rates [albeit at lower wire ratesgenerally, but not always] >>> The basic idea being that we can optimize/facilitate hardware parsing >>> further and further along the header chain by publishing additional >>> informational RFCs, and at some point in the future we'll get enough >>> extension headers supported together with hardware forwarding that they >>> become useful. I'd certainly like to be able to buy a firewall with ASIC >>> optimized forwarding of IPv6 (including extension headers). >> I definitely think this is worth pursuing, as long as the point of not >> creating a DoS vector is kept in mind. >> >>> The alternative would seem to be a stalemate of continual shouting from >>> the ivory tower that hardware vendors just need to learn to live with >>> arbitrary packet complexity, whilst operational people drop everything >>> containing an extension header so there's no market demand for the >>> hardware vendors to do anything. >> Or operational people voting with their wallets, and buying the box >> that kan "only" look 256 bytes into the header, because it is N% less >> expensive than the box that can look a full 64 kByte into the header. > > Yup, and from talking to vendors, N is *large*. > > The big issue here isn't so much complexity of building ASICs that can parse the linked-list, it is the cost (bandwidth and memory) of dragging the headers up to the ASIC so that it can be inspected. OK. Interesting. I understood that a significant problem was the inability to pre-fetch the seemingly endless multiple possible branches in the extension header + options chain, so the parser could work efficiently in parallel. I'm perfectly willing to be educated. > This may take us down (yet another) rat-hole where folk express surprise at the cost of widgets, discussions on the actual cost vs discounted cost, If you can afford to pay X, you can afford X+10% (or 2*X), router-architecture, but I think it is worth folk having *some* understanding of the costs here. I'm all for openness and am not at all surprised. I want to buy multi-gigabit IPv6 site firewalls for $50K a piece. [which is roughly what an ASIC accelerated IPv4 firewall costs today] > Using public info: > > Here is the example 'show chassis hardware models' for a Juniper T1600 from Juniper's site: http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/task/operational/t4000-upgrade-verify-t640-t1600-components.html and using prices published here: http://www.technicacorp.com/federal/contracts/nasa_sewpiv/sewp_search?manufacturer=Juniper%20Networks,%20Inc. > > We get: > > QTY DESC List Total Comment > 3 T1600-FPC4-ES "$300,000.00" "$900,000.00" > 1 T640-FPC2-E2 "$71,100.00" "$71,100.00" > 1 T640-FPC1-E2 "$47,400.00" "$47,400.00" > 1 T640-FPC3-E "$118,500.00" "$118,500.00" > 1 T640-FPC3 $0.00 $0.00 Could not easily find public price. > 5 SIB-I-T1600-S "$50,000.00" "$250,000.00" > 3 PC-8GE-TYPE3-SFP-IQ2 "$120,000.00" "$360,000.00" > 2 PD-4XGE-XFP "$250,000.00" "$500,000.00" > 2 PC-4OC48-SON-SFP "$205,000.00" "$410,000.00" > 2 PC-1XGE-TYPE3-XFP-IQ2 "$141,000.00" "$282,000.00" > 2 PC-10GE-SFP "$120,000.00" "$240,000.00" > 2 PB-1OC48-SON-SMSR $0.00 $0.00 Could not easily find public price. > 1 CB-T-S "$9,000.00" "$9,000.00" > 1 SCG-T-S "$5,000.00" "$5,000.00" > 1 PD-4OC192-SON-XFP "$660,000.00" "$660,000.00" > 1 PD-1OC768-SON-SR "$620,000.00" "$620,000.00" > 1 PD-1CE-CFP-FPC4 "$650,000.00" "$650,000.00" > 1 PC-TUNNEL "$120,000.00" "$120,000.00" > 1 PC-1OC192-SON-VSR "$125,000.00" "$125,000.00" > 1 PC-1OC192-SON-SR2 $0.00 $0.00 Could not easily find public price. > 1 PB-4OC12-SON-SMIR-REFURB "$20,000.00" "$20,000.00" Refurb > 1 PB-4GE-TYPE1-SFP-IQ2 "$32,000.00" "$32,000.00" > 1 PB-4GE-SFP "$58,000.00" "$58,000.00" > 1 PB-1CHOC12SMIR-QPP "$67,150.00" "$67,150.00" > > Total "$5,545,150.00" > > This is for a large box, but not the most expensive-- it is also missing a control plane, the actual chassis / backplane, power, etc (I got bored). > > Cisco pricing is similar - http://www.cisco.com/web/strategy/government/wsca/pricelist_archive.html Feel free to find 'show diag' for a CRS-1 (or -3) and do your own calculations… > > In the real world (what we are talking about here!), everyone gets a reasonable discount off list prices, but that discount is far from 100% :-P > > What percentage more should I be willing to pay to be formally correct / RFC compliant? Or to support some niche use? How do I justify spending an additional X% to my bean-counters? What value can I point at? Seeing as things are working just fine without extensions headers at the moment, and the Internet Protocol Police have no enforcement power, it is very hard to justify any X, let alone the type of X that I've heard from vendors…. Are they working fine? IPv6 relies on PMTUD and fragmentation headers. But AFAICS neither of these are a particularly good solution if 1) there are firewalls that block ICMPv6 so PMTUD doesn't detect the drop [working on this with educating the security people] 2) there are devices on the path that drop all packets with extension headers (including fragment extension headers as far as I read) 3) today's IPv6 firewalls can't handle today's IPv4 traffic volumes at today's prices AFAICS. [correct me if I'm wrong] = unhappy eyeballs and having to rewrite *all* applications to work with 1280 byte packets (enormous cost!) Even if we just documented a common packet format in an informational RFC that allowed everyone to reliably switch a hop by hop extension header + a fragment extension header in hardware end to end, wouldn't that be a huge step forward? And then AH + ESP? Doesn't that have real value? I'm looking for a pragmatic compromise here between the long-term academic position of "this is IPv6, deal with it" and the short-term ops manager saying "we have no money this year". > And no, additional bits in my packets for diagnostics is not the value here, I'm managing just fine without them, thanks though. > > > Yes, 'tis sad when the development of protocols / deployment of features is impacted by business[0] considerations -- welcome to the real world. Never said it would be otherwise. DECnet V was mighty fine: I've never seen it in operations. DECnet IV is still running in many networks. > W > > [0]: Or by physics ( like C / thermodynamics), or by technology (like power and cooling), or by politics, or by IPR, or by legacy considerations, or ... > >> Steinar Haug, AS 2116 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > -- > "Go on, prove me wrong. Destroy the fabric of the universe. See if I care." -- Terry Prachett > > > 0 From brian.e.carpenter@gmail.com Fri Jun 7 13:21:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB92B21F99C9 for ; Fri, 7 Jun 2013 13:21:13 -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 jZZE5WZHUmMn for ; Fri, 7 Jun 2013 13:21:07 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF321F99C2 for ; Fri, 7 Jun 2013 13:21:07 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so5278957pdj.28 for ; Fri, 07 Jun 2013 13:21:07 -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=jpI+Xk657Vz1c55kkp9X/Zs86y/BkUWS8jG0uiMKGAo=; b=zqgGazGwyaJEZbk4IEgAJFA5N9rgN8VNExaR+Rr+Iyp/ribnC+EaRygj4NqAir+fov M07+y3sgNMI4Du50b9rZ0cRppgANneWM/VIcHtwf6A0dcy1YWcfBlghicy67HoWLcmkh xXWDvpgqZrdmWS7AtBNS9OuMGqaY96ZMunn01ZGziJZuMK+dz04uGNAE8ZqV4X/VYk/e /X0UVTUe1L8EUCTRyA9R2J+Nh3aE/4QWgPdAp0MktMeuUG7dU3Q52w18xnVQWNHtAMYQ e5N1nmoTaASnlZPXpxpK0tCct4ZUSAoos67OmQrIhUK7flW0Pdj4U0H+J05kM0tRiZLw E4hg== X-Received: by 10.68.143.5 with SMTP id sa5mr336148pbb.106.1370636467550; Fri, 07 Jun 2013 13:21:07 -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 xd2sm4541998pac.15.2013.06.07.13.21.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Jun 2013 13:21:06 -0700 (PDT) Message-ID: <51B240BD.6080207@gmail.com> Date: Sat, 08 Jun 2013 08:21:17 +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 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <51B2231F.40203@isi.edu> In-Reply-To: <51B2231F.40203@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:21:13 -0000 Joe, On 08/06/2013 06:14, Joe Touch wrote: > Hi, all, > > In the spirit of moving towards a solution, here's my understanding of > the problems: > > 1. the need for load balancing > > - if packets had true E2E addresses, those addresses would be > sufficient for load-balancing Absolutely not. Load balancing routinely looks at L4 headers. See RFC 6438, draft-ietf-intarea-flow-label-balancing, draft-ietf-opsawg-large-flow-load-balancing. Brian From touch@isi.edu Fri Jun 7 13:44:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50C921F9925 for ; Fri, 7 Jun 2013 13:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.01 X-Spam-Level: X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=-0.411, 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 HFfcFhVOkRwB for ; Fri, 7 Jun 2013 13:43:56 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 78DE721F9923 for ; Fri, 7 Jun 2013 13:43:56 -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 r57KhcFo017452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 13:43:39 -0700 (PDT) Message-ID: <51B245F1.2070901@isi.edu> Date: Fri, 07 Jun 2013 13:43:29 -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: Brian E Carpenter References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <51B2231F.40203@isi.edu> <51B240BD.6080207@gmail.com> In-Reply-To: <51B240BD.6080207@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:44:02 -0000 Hi, Brian, On 6/7/2013 1:21 PM, Brian E Carpenter wrote: > Joe, > > On 08/06/2013 06:14, Joe Touch wrote: >> Hi, all, >> >> In the spirit of moving towards a solution, here's my understanding of >> the problems: >> >> 1. the need for load balancing >> >> - if packets had true E2E addresses, those addresses would be >> sufficient for load-balancing > > Absolutely not. Load balancing routinely looks at L4 headers. > > See RFC 6438, draft-ietf-intarea-flow-label-balancing, > draft-ietf-opsawg-large-flow-load-balancing. Both docs refer to cases I indicate in my later post: > I don't quite understand why IP addresses are insufficient; the only > way that would be true is if: > > a) a host could send data at very high rates (possible, but > unlikely sustained) > > b) a block of hosts share a single address and send data > out at an aggregate high rate > > c) aggregated traffic is either NAT'd or tunneled The first doc focuses on case (b). IMO, that's a failure of the configuration of the block of hosts. The second doc indicates that there are several ways to differentiate flows, of which only the first - the 5-tuple - includes L4 information. The other post explained how I suggested handling each of these three cases, FWIW. Joe From owen@delong.com Fri Jun 7 15:19:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: "Manfredi, Albert E" , "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Sheng Jiang Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 touch@isi.edu Fri Jun 7 15:21:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1734721F99B9 for ; Fri, 7 Jun 2013 15:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.969 X-Spam-Level: X-Spam-Status: No, score=-104.969 tagged_above=-999 required=5 tests=[AWL=1.630, 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 mhdpk-LR9x5e for ; Fri, 7 Jun 2013 15:21:14 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 055EF21F99A6 for ; Fri, 7 Jun 2013 15:21:13 -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 r57MKpIW008603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 15:20:51 -0700 (PDT) Message-ID: <51B25CC7.4070700@isi.edu> Date: Fri, 07 Jun 2013 15:20:55 -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: Brian E Carpenter References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <51B2231F.40203@isi.edu> <51B240BD.6080207@gmail.com> <51B245F1.2070901@isi.edu> In-Reply-To: <51B245F1.2070901@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 22:21:24 -0000 Hi, all, I realized that part of my response below was based on a message I sent privately, but it needn't have been; here's the post: ----- I'm trying to get at the core of this issue. I don't quite understand why IP addresses are insufficient; the only way that would be true is if: a) a host could send data at very high rates (possible, but unlikely sustained) b) a block of hosts share a single address and send data out at an aggregate high rate c) aggregated traffic is either NAT'd or tunneled In the case of (c), the NAT/tunnel ingress should be part of the solution; it clearly is creating the problem, as I suggest below. In case (a), the network won't benefit from *any* host identity solution; there's no point in solving that case. In case (b), I would argue that the problem is sharing the address in the first place. That case should be solved by reconfiguration. Is there some other case? Or maybe, rather than "drop all packets that have extension headers", a better solution is to "load balance where the IP information is sufficient", and where it is not just drop traffic that exceeds the need to balance? Joe On 6/7/2013 1:43 PM, Joe Touch wrote: > Hi, Brian, > > On 6/7/2013 1:21 PM, Brian E Carpenter wrote: >> Joe, >> >> On 08/06/2013 06:14, Joe Touch wrote: >>> Hi, all, >>> >>> In the spirit of moving towards a solution, here's my understanding of >>> the problems: >>> >>> 1. the need for load balancing >>> >>> - if packets had true E2E addresses, those addresses would be >>> sufficient for load-balancing >> >> Absolutely not. Load balancing routinely looks at L4 headers. > > >> See RFC 6438, draft-ietf-intarea-flow-label-balancing, >> draft-ietf-opsawg-large-flow-load-balancing. > > Both docs refer to cases I indicate in my later post: > >> I don't quite understand why IP addresses are insufficient; the only >> way that would be true is if: >> >> a) a host could send data at very high rates (possible, but >> unlikely sustained) >> >> b) a block of hosts share a single address and send data >> out at an aggregate high rate >> >> c) aggregated traffic is either NAT'd or tunneled > > The first doc focuses on case (b). IMO, that's a failure of the > configuration of the block of hosts. > > The second doc indicates that there are several ways to differentiate > flows, of which only the first - the 5-tuple - includes L4 information. > > The other post explained how I suggested handling each of these three > cases, FWIW. > > Joe From jmh@joelhalpern.com Fri Jun 7 15:53:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EE821F99DD for ; Fri, 7 Jun 2013 15:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1sgOn9h5t2w for ; Fri, 7 Jun 2013 15:53:11 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0A821F99DB for ; Fri, 7 Jun 2013 15:53:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 240D11C84AB5; Fri, 7 Jun 2013 15:53:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-48.clppva.east.verizon.net [70.106.135.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 41A231C84AB4; Fri, 7 Jun 2013 15:53:10 -0700 (PDT) Message-ID: <51B26451.3080900@joelhalpern.com> Date: Fri, 07 Jun 2013 18:53:05 -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: Joe Touch References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <51B2231F.40203@isi.edu> <51B240BD.6080207@gmail.com> <51B245F1.2070901@isi.edu> <51B25CC7.4070700@isi.edu> In-Reply-To: <51B25CC7.4070700@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 22:53:16 -0000 One thing that was observed years ago was that for whatever reason, even in the absence of NAT, the source and dest IP address simply did not have enough entropy to give a good distribution of packets across ECMP groups. Yours, Joel On 6/7/2013 6:20 PM, Joe Touch wrote: > Hi, all, > > I realized that part of my response below was based on a message I sent > privately, but it needn't have been; here's the post: > > ----- > > I'm trying to get at the core of this issue. > > I don't quite understand why IP addresses are insufficient; the only way > that would be true is if: > > a) a host could send data at very high rates (possible, but > unlikely sustained) > > b) a block of hosts share a single address and send data > out at an aggregate high rate > > c) aggregated traffic is either NAT'd or tunneled > > In the case of (c), the NAT/tunnel ingress should be part of the > solution; it clearly is creating the problem, as I suggest below. > > In case (a), the network won't benefit from *any* host identity > solution; there's no point in solving that case. > > In case (b), I would argue that the problem is sharing the address in > the first place. That case should be solved by reconfiguration. > > Is there some other case? > > Or maybe, rather than "drop all packets that have extension headers", a > better solution is to "load balance where the IP information is > sufficient", and where it is not just drop traffic that exceeds the need > to balance? > > Joe > > On 6/7/2013 1:43 PM, Joe Touch wrote: >> Hi, Brian, >> >> On 6/7/2013 1:21 PM, Brian E Carpenter wrote: >>> Joe, >>> >>> On 08/06/2013 06:14, Joe Touch wrote: >>>> Hi, all, >>>> >>>> In the spirit of moving towards a solution, here's my understanding of >>>> the problems: >>>> >>>> 1. the need for load balancing >>>> >>>> - if packets had true E2E addresses, those addresses would be >>>> sufficient for load-balancing >>> >>> Absolutely not. Load balancing routinely looks at L4 headers. >> > >>> See RFC 6438, draft-ietf-intarea-flow-label-balancing, >>> draft-ietf-opsawg-large-flow-load-balancing. >> >> Both docs refer to cases I indicate in my later post: >> >>> I don't quite understand why IP addresses are insufficient; the only >>> way that would be true is if: >>> >>> a) a host could send data at very high rates (possible, but >>> unlikely sustained) >>> >>> b) a block of hosts share a single address and send data >>> out at an aggregate high rate >>> >>> c) aggregated traffic is either NAT'd or tunneled >> >> The first doc focuses on case (b). IMO, that's a failure of the >> configuration of the block of hosts. >> >> The second doc indicates that there are several ways to differentiate >> flows, of which only the first - the 5-tuple - includes L4 information. >> >> The other post explained how I suggested handling each of these three >> cases, FWIW. >> >> Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From touch@isi.edu Fri Jun 7 16:00:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0341221F99D8 for ; Fri, 7 Jun 2013 16:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.117 X-Spam-Level: X-Spam-Status: No, score=-103.117 tagged_above=-999 required=5 tests=[AWL=-0.518, 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 45C8pS1a3ISq for ; Fri, 7 Jun 2013 15:59:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3997221F99CE for ; Fri, 7 Jun 2013 15:59:54 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r57MxV3X028353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 15:59:31 -0700 (PDT) Message-ID: <51B265D6.6000101@isi.edu> Date: Fri, 07 Jun 2013 15:59:34 -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: "Joel M. Halpern" References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <51B2231F.40203@isi.edu> <51B240BD.6080207@gmail.com> <51B245F1.2070901@isi.edu> <51B25CC7.4070700@isi.edu> <51B26451.3080900@joelhalpern.com> In-Reply-To: <51B26451.3080900@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 23:00:00 -0000 On 6/7/2013 3:53 PM, Joel M. Halpern wrote: > One thing that was observed years ago was that for whatever reason, even > in the absence of NAT, the source and dest IP address simply did not > have enough entropy to give a good distribution of packets across ECMP > groups. Until we understand why this is true, it's not realistic to try to address it as a problem, IMO. Joe From nalini.elkins@insidethestack.com Fri Jun 7 16:16:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC121F99A9 for ; Fri, 7 Jun 2013 16:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYTVsVcQGueT for ; Fri, 7 Jun 2013 16:16:50 -0700 (PDT) Received: from nm11-vm0.access.bullet.mail.sp2.yahoo.com (nm11-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.124]) by ietfa.amsl.com (Postfix) with ESMTP id EF43321F9936 for ; Fri, 7 Jun 2013 16:16:49 -0700 (PDT) Received: from [98.139.44.103] by nm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 23:16:49 -0000 Received: from [98.139.44.90] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 23:16:49 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 23:16:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 283761.20855.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 64995 invoked by uid 60001); 7 Jun 2013 23:16:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370647008; bh=F18RZlBi6ScfPoIsIKTULe6GbEpPzlf6TFt3cVvufQ8=; 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=O2UoeVIXcSpy6kdyAe71sd48WpPAHEWB7JBp2JOdgAEF63LLpj/mmes1q3XZWdFxFg36q6pVH3e7SXAdwf3nNsSjYRHfbd3RM5te4kElwfmKZ7TDoCGt306K153MsFM7wkykmWtIx8wnfEhIqPayifpBA8E8n6MIjY7mV73IYww= X-YMail-OSG: gj6njfgVM1kh.xglaauduKJgSFoWZB_1tPUFxq3U1ulMwvy Hv73PLzBp4g2g9L271v7JHl2cocxkOibc.ftH_dwIjDS4XLlfHFF5ijigqUK fWg7oaUbQ3cuM13c40G22waHU13EmSUpqwYgHb3JAYu0XA8242VFlaIxk9J6 3Sd7ARSPiZumcMDTWQzuefrEwxfrI7en_IyXXODhQ8f9bFKzy9XbxBqPve.O 3Zu_VrYZZncwDAP1iUbN5_YYJf6HZBq6LIr0QNKa6YrLSXaxKcTeopNsQ25M wZsUjyDHMyNRb.o9YmAOH5lrUWF6evAZBOAQDXLeUmlHAfNKfJVPN77Danuw 8juKafH1b9MJcgxsD5vLIDI8r75fZ1oZIqulVSPrkag_5LF9VzLzzCIedPJK 9yNqVrElAOd0.uF_HZcf105q35gPcrxXDY3Wun8wm27uv1093tXKzLAAFrbh Qm1695hcXNDa8oYS117C.85Lp9Fzu3Deoxn9q88HfCihiHd25.Tjn0eDDgUF fmr6SqVA36JiR9hTvb_kTmGkbSvkck28dAvvgV9wjHAa8njFAkM6nvWBV5WM jkwuUP4ivQ3fga4RTOEK1GhEkehveBR56M.SLYAIXd4E8rEIQw8kXFsHr0Wq BRB_Xz8_w9iAyAHWrDIKG7yDHX0rqU5Ynk1xWFW7GHfk5oQa3y9E1DUMcVov zycTfOpJeU4qUXogoUjxXMFZKtQ5miGyz4g8f7ySvSpxdeIo47oN4zME_uqi z33lXnwGzU5ZqjiLDlLrB9prdMjrdrpUFzMJqp4OfnpTP4R4PIlDLRryHyOC q07HsFvIw.Ay6NB6C_BP9slO_OFNbN7t7yCsuBXe.gl2WELCQxDj_cgCc6LS ikT_sKiCaivmjukAX0saalJq4S0vrB33ImO0oOkM3dSS7B7wpJozAZ0m_HyH MrWNB8vbnGk7Z4OP1enha6nqxfyvj8Xc9qw0aTbiGBqpPsBpLiYAiwUp50dg pdAWhTSDW27sW.tchkNsz.VRaCVbf6F2_F0m3oWWUK9jlWI8LTvCgVz1_e7u kGs_A_4CoCEsdUhSpo9P05sUt0cl1wc27fjIVxcZRv1n068pCVz4wFX_H71R EbjKY3ZF32fI1Eh6ZZrHyWes- Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Fri, 07 Jun 2013 16:16:48 PDT X-Rocket-MIMEInfo: 002.001, R3JlYXQgaW5mbyBhYm91dCB0aGUgaGFyZHdhcmUgcHJpY2VzIQoKPj5BbmQgbm8sIGFkZGl0aW9uYWwgYml0cyBpbiBteSBwYWNrZXRzIGZvciBkaWFnbm9zdGljcyBpcyBub3QgdGhlIHZhbHVlIGhlcmUsIEknbSBtYW5hZ2luZyBqdXN0IGZpbmUgd2l0aG91dCB0aGVtLCB0aGFua3MgdGhvdWdoLgoKVGhpcyBoaWdobGlnaHRzIHRoZSBkaWZmZXJlbnQgY29uc3RpdHVlbmNpZXMuIMKgIFVuZm9ydHVuYXRlbHksIHdlIGJvdGggaGF2ZSB0byBidXkgZXF1aXBtZW50IGZyb20gdGhlIHNhbWUgdmVuZG9ycyB3aG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B180B3.2090106@globis.net> <20130607.090624.19791724.he@uninett.no> <51B18AC1.5070403@globis.net> <20130607.095033.74669945.sthaug@nethelp.no> <57377A7F-C870-4984-BB3B-38F790A174A9@kumari.net> Message-ID: <1370647008.49387.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 16:16:48 -0700 (PDT) From: Nalini Elkins To: Warren Kumari , "sthaug@nethelp.no" In-Reply-To: <57377A7F-C870-4984-BB3B-38F790A174A9@kumari.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-503698149-1370647008=:49387" Cc: "v6ops@globis.net" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 23:16:54 -0000 ---1051860855-503698149-1370647008=:49387 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great info about the hardware prices!=0A=0A>>And no, additional bits in my = packets for diagnostics is not the value here, I'm managing just fine witho= ut them, thanks though.=0A=0AThis highlights the different constituencies. = =C2=A0 Unfortunately, we both have to buy equipment from the same vendors w= ho are following the same RFCs. =C2=A0(Let's leave aside the argument that = maybe they are not following ANY RFCs!). =C2=A0 You wouldn't like it if you= were forced to live under rules that in many ways didn't apply to you. =C2= =A0Well, we don't either.=0A=C2=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside= Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______= __________________________=0A From: Warren Kumari =0ATo:= sthaug@nethelp.no =0ACc: v6ops@globis.net; "v6ops@ietf.org WG" =0ASent: Friday, June 7, 2013 10:56 AM=0ASubject: Re: [v6ops] new dra= ft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn Jun 7, 2013= , at 2:50 AM, sthaug@nethelp.no wrote:=0A=0A>> How's that worse than today,= where people are apparently dropping all=0A>> packets containing any exten= sion headers (because they're all soft=0A>> switched)?=0A> =0A> Also, remem= ber there is plenty of hardware out there that doesn't *do*=0A> soft switch= ing at all. If a packet cannot be forwarded in hardware, it=0A> is dropped.= =0A=0AYup. I think that plenty is actually "most deployed hardware with 10G= B interfaces".=0A=0A> =0A>> The basic idea being that we can optimize/facil= itate hardware parsing=0A>> further and further along the header chain by p= ublishing additional=0A>> informational RFCs, and at some point in the futu= re we'll get enough=0A>> extension headers supported together with hardware= forwarding that they=0A>> become useful. I'd certainly like to be able to = buy a firewall with ASIC=0A>> optimized forwarding of IPv6 (including exten= sion headers).=0A> =0A> I definitely think this is worth pursuing, as long = as the point of not=0A> creating a DoS vector is kept in mind.=0A> =0A>> Th= e alternative would seem to be a stalemate of continual shouting from=0A>> = the ivory tower that hardware vendors just need to learn to live with=0A>> = arbitrary packet complexity, whilst operational people drop everything=0A>>= containing an extension header so there's no market demand for the=0A>> ha= rdware vendors to do anything.=0A> =0A> Or operational people voting with t= heir wallets, and buying the box =0A> that kan "only" look 256 bytes into t= he header, because it is N% less=0A> expensive than the box that can look a= full 64 kByte into the header.=0A=0AYup, and from talking to vendors, N is= *large*. =0A=0AThe big issue here isn't so much complexity of building ASI= Cs that can parse the linked-list, it is the cost (bandwidth and memory) of= dragging the headers up to the ASIC so that it can be inspected. =0A=0AThi= s may take us down (yet another) rat-hole where folk express surprise at th= e cost of widgets, discussions on the actual cost vs discounted cost, If yo= u can afford to pay X, you can afford X+10% (or 2*X), router-architecture, = but I think it is worth folk having *some* understanding of the costs here.= =0A=0AUsing public info:=0A=0AHere is the example 'show chassis hardware mo= dels' for a Juniper T1600 from Juniper's site: http://www.juniper.net/techp= ubs/en_US/release-independent/junos/topics/task/operational/t4000-upgrade-v= erify-t640-t1600-components.html and using prices published here: http://ww= w.technicacorp.com/federal/contracts/nasa_sewpiv/sewp_search?manufacturer= =3DJuniper%20Networks,%20Inc.=0A=0AWe get: =0A=0AQTY=C2=A0 =C2=A0 DESC=C2= =A0 =C2=A0 List=C2=A0 =C2=A0 Total=C2=A0 Comment=0A3=C2=A0 =C2=A0 =C2=A0 = T1600-FPC4-ES=C2=A0 "$300,000.00"=C2=A0 "$900,000.00"=0A1=C2=A0 =C2=A0 = =C2=A0 T640-FPC2-E2=C2=A0 =C2=A0 "$71,100.00"=C2=A0 =C2=A0 "$71,100.00"=0A= 1=C2=A0 =C2=A0 =C2=A0 T640-FPC1-E2=C2=A0 =C2=A0 "$47,400.00"=C2=A0 =C2=A0 = "$47,400.00"=0A1=C2=A0 =C2=A0 =C2=A0 T640-FPC3-E=C2=A0 =C2=A0 "$118,500.0= 0"=C2=A0 "$118,500.00"=0A1=C2=A0 =C2=A0 =C2=A0 T640-FPC3=C2=A0 =C2=A0 =C2= =A0 $0.00=C2=A0 $0.00=C2=A0 Could not easily find public price.=0A5=C2= =A0 =C2=A0 =C2=A0 SIB-I-T1600-S=C2=A0 "$50,000.00"=C2=A0 =C2=A0 "$250,000= .00"=0A3=C2=A0 =C2=A0 =C2=A0 PC-8GE-TYPE3-SFP-IQ2=C2=A0 =C2=A0 "$120,000.0= 0"=C2=A0 "$360,000.00"=0A2=C2=A0 =C2=A0 =C2=A0 PD-4XGE-XFP=C2=A0 =C2=A0 = "$250,000.00"=C2=A0 "$500,000.00"=0A2=C2=A0 =C2=A0 =C2=A0 PC-4OC48-SON-SF= P=C2=A0 =C2=A0 =C2=A0 =C2=A0 "$205,000.00"=C2=A0 "$410,000.00"=0A2=C2=A0 = =C2=A0 =C2=A0 PC-1XGE-TYPE3-XFP-IQ2=C2=A0 "$141,000.00"=C2=A0 "$282,000.= 00"=0A2=C2=A0 =C2=A0 =C2=A0 PC-10GE-SFP=C2=A0 =C2=A0 "$120,000.00"=C2=A0 = "$240,000.00"=0A2=C2=A0 =C2=A0 =C2=A0 PB-1OC48-SON-SMSR=C2=A0 =C2=A0 =C2= =A0 $0.00=C2=A0 $0.00=C2=A0 Could not easily find public price.=0A1=C2= =A0 =C2=A0 =C2=A0 CB-T-S=C2=A0 "$9,000.00"=C2=A0 =C2=A0 "$9,000.00"=0A1= =C2=A0 =C2=A0 =C2=A0 SCG-T-S "$5,000.00"=C2=A0 =C2=A0 "$5,000.00"=0A1=C2= =A0 =C2=A0 =C2=A0 PD-4OC192-SON-XFP=C2=A0 =C2=A0 =C2=A0 "$660,000.00"=C2= =A0 "$660,000.00"=0A1=C2=A0 =C2=A0 =C2=A0 PD-1OC768-SON-SR=C2=A0 =C2=A0 = =C2=A0 =C2=A0 "$620,000.00"=C2=A0 "$620,000.00"=0A1=C2=A0 =C2=A0 =C2=A0 P= D-1CE-CFP-FPC4 "$650,000.00"=C2=A0 "$650,000.00"=0A1=C2=A0 =C2=A0 =C2=A0 = PC-TUNNEL=C2=A0 =C2=A0 =C2=A0 "$120,000.00"=C2=A0 "$120,000.00"=0A1=C2=A0= =C2=A0 =C2=A0 PC-1OC192-SON-VSR=C2=A0 =C2=A0 =C2=A0 "$125,000.00"=C2=A0 = "$125,000.00"=0A1=C2=A0 =C2=A0 =C2=A0 PC-1OC192-SON-SR2=C2=A0 =C2=A0 =C2= =A0 $0.00=C2=A0 $0.00=C2=A0 Could not easily find public price.=0A1=C2= =A0 =C2=A0 =C2=A0 PB-4OC12-SON-SMIR-REFURB=C2=A0 =C2=A0 =C2=A0 =C2=A0 "$20= ,000.00"=C2=A0 =C2=A0 "$20,000.00"=C2=A0 =C2=A0 Refurb=0A1=C2=A0 =C2=A0 =C2= =A0 PB-4GE-TYPE1-SFP-IQ2=C2=A0 =C2=A0 "$32,000.00"=C2=A0 =C2=A0 "$32,000.0= 0"=0A1=C2=A0 =C2=A0 =C2=A0 PB-4GE-SFP=C2=A0 =C2=A0 =C2=A0 "$58,000.00"=C2= =A0 =C2=A0 "$58,000.00"=0A1=C2=A0 =C2=A0 =C2=A0 PB-1CHOC12SMIR-QPP=C2=A0 = =C2=A0 =C2=A0 "$67,150.00"=C2=A0 =C2=A0 "$67,150.00"=0A=0A=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Total=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "$5,545,150.00"=0A=0ATh= is is for a large box, but not the most expensive-- it is also missing a co= ntrol plane, the actual chassis / backplane, power, etc (I got bored).=0A= =0ACisco pricing is similar - http://www.cisco.com/web/strategy/government/= wsca/pricelist_archive.html Feel free to find 'show diag' for a CRS-1 (or -= 3) and do your own calculations=E2=80=A6=0A=0AIn=C2=A0 the real world (what= we are talking about here!), everyone gets a reasonable discount off list = prices, but that discount is far from 100% :-P=0A=0AWhat percentage more sh= ould I be willing to pay to be formally correct / RFC compliant? Or to supp= ort some niche use? How do I justify spending an additional X% to my bean-c= ounters? What value can I point at? Seeing as things are working just fine = without extensions headers at the moment, and the Internet Protocol Police = have no enforcement power, it is very hard to justify any X, let alone the = type of X that I've heard from vendors=E2=80=A6.=0A=0AAnd no, additional bi= ts in my packets for diagnostics is not the value here, I'm managing just f= ine without them, thanks though.=0A=0A=0AYes, 'tis sad when the development= of protocols / deployment of features is impacted by business[0] considera= tions -- welcome to the real world.=0A=0AW=0A=0A[0]: Or by physics ( like C= / thermodynamics), or by technology (like power and cooling), or by politi= cs, or by IPR, or by legacy considerations, or ...=0A=0A> =0A> Steinar Haug= , AS 2116=0A> _______________________________________________=0A> v6ops mai= ling list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6op= s=0A> =0A=0A--=0A"Go on, prove me wrong. Destroy the fabric of the universe= . See if I care."=C2=A0 -- Terry Prachett =0A=0A=0A________________________= _______________________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www= .ietf.org/mailman/listinfo/v6ops ---1051860855-503698149-1370647008=:49387 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Great info about the hardware prices!

    =
    >>And no, additional bits in my packets for diagnostics i= s not the value here, I'm managing just fine without them, thanks though.=

    This highlights the different constituencies.   U= nfortunately, we both have to buy equipment from the same vendors who are f= ollowing the same RFCs.  (Let's leave aside the argument that maybe th= ey are not following ANY RFCs!).   You wouldn't like it if you were forced to live under rules that in many ways didn't apply to you.  We= ll, we don't either.
     
    Th= anks,

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

    =
    From: Warren Kumari <warren@kumari.net>
    <= b>To: sthaug@nethelp.no
    <= b>Cc:     v6ops@globis.net; "v6op= s@ietf.org WG" <v6ops@ietf.org>
    Sent: Friday, June 7, 2013 10:56 AM
    Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

    =0A
    On Jun 7, 2013, at 2:50 AM, sthaug@nethelp.n= o wrote:

    >> How's that worse than today, where people are = apparently dropping all
    >> packets containing any extension header= s (because they're all soft
    >> switched)?
    >
    > Also, r= emember there is plenty of hardware out there that doesn't *do*
    > sof= t switching at all. If a packet cannot be forwarded in hardware, it
    >= is dropped.

    Yup. I think that plenty is actually "most deployed har= dware with 10GB interfaces".

    >
    >> The basic idea being = that we can optimize/facilitate hardware parsing
    >> further and fu= rther along the header chain by publishing additional
    >> informati= onal RFCs, and at some point in the future we'll get enough
    >> ext= ension headers supported together with hardware forwarding that they
    >= ;> become useful. I'd certainly like to be able to buy a firewall with ASIC
    >> optimize= d forwarding of IPv6 (including extension headers).
    >
    > I defi= nitely think this is worth pursuing, as long as the point of not
    > cr= eating a DoS vector is kept in mind.
    >
    >> The alternative w= ould seem to be a stalemate of continual shouting from
    >> the ivor= y tower that hardware vendors just need to learn to live with
    >> a= rbitrary packet complexity, whilst operational people drop everything
    &g= t;> containing an extension header so there's no market demand for the>> hardware vendors to do anything.
    >
    > Or operational= people voting with their wallets, and buying the box
    > that kan "on= ly" look 256 bytes into the header, because it is N% less
    > expensive= than the box that can look a full 64 kByte into the header.

    Yup, an= d from talking to vendors, N is *large*.

    The big issue here isn't so much complexity of building ASICs that can parse the linked-list,= it is the cost (bandwidth and memory) of dragging the headers up to the AS= IC so that it can be inspected.

    This may take us down (yet another)= rat-hole where folk express surprise at the cost of widgets, discussions o= n the actual cost vs discounted cost, If you can afford to pay X, you can a= fford X+10% (or 2*X), router-architecture, but I think it is worth folk hav= ing *some* understanding of the costs here.

    Using public info:
    Here is the example 'show chassis hardware models' for a Juniper T1600 fr= om Juniper's site: http://www.juniper.net/techpubs/en_US/release-independen= t/junos/topics/task/operational/t4000-upgrade-verify-t640-t1600-components.= html and using prices published here: http://www.technicacorp.com/federal/c= ontracts/nasa_sewpiv/sewp_search?manufacturer=3DJuniper%20Networks,%20Inc.<= br>
    We get:

    QTY    DESC    List    Total  Comment
    3      T1600-FPC4-ES  = "$300,000.00"  "$900,000.00"
    1      T640-FPC2-E2&= nbsp;   "$71,100.00"    "$71,100.00"
    1     = ; T640-FPC1-E2    "$47,400.00"    "$47,400.00"
    1&nb= sp;     T640-FPC3-E    "$118,500.00"  "$118,500= .00"
    1      T640-FPC3      $0.00  = $0.00  Could not easily find public price.
    5      = SIB-I-T1600-S  "$50,000.00"    "$250,000.00"
    3  &nb= sp;   PC-8GE-TYPE3-SFP-IQ2    "$120,000.00"  "$360,00= 0.00"
    2      PD-4XGE-XFP    "$250,000.00"&nbs= p; "$500,000.00"
    2      PC-4OC48-SON-SFP    &= nbsp;   "$205,000.00"  "$410,000.00"
    2      P= C-1XGE-TYPE3-XFP-IQ2  "$141,000.00" =20 "$282,000.00"
    2      PC-10GE-SFP    "$120,00= 0.00"  "$240,000.00"
    2      PB-1OC48-SON-SMSR = ;     $0.00  $0.00  Could not easily find public pri= ce.
    1      CB-T-S  "$9,000.00"    "$9,00= 0.00"
    1      SCG-T-S "$5,000.00"    "$5,000.0= 0"
    1      PD-4OC192-SON-XFP      "$660,0= 00.00"  "$660,000.00"
    1      PD-1OC768-SON-SR = ;       "$620,000.00"  "$620,000.00"
    1   =   PD-1CE-CFP-FPC4 "$650,000.00"  "$650,000.00"
    1  &nbs= p;   PC-TUNNEL      "$120,000.00"  "$120,000.00= "
    1      PC-1OC192-SON-VSR      "$125,00= 0.00"  "$125,000.00"
    1      PC-1OC192-SON-SR2 = ;     $0.00  $0.00  Could not easily find public price.
    1      PB-4OC12-SON-SMIR-REFURB  &nb= sp;     "$20,000.00"    "$20,000.00"    Refur= b
    1      PB-4GE-TYPE1-SFP-IQ2    "$32,000.00"&= nbsp;   "$32,000.00"
    1      PB-4GE-SFP   =   "$58,000.00"    "$58,000.00"
    1      PB= -1CHOC12SMIR-QPP      "$67,150.00"    "$67,150.00"=

            Total         = "$5,545,150.00"

    This is for a large box, but not the most expensiv= e-- it is also missing a control plane, the actual chassis / backplane, pow= er, etc (I got bored).

    Cisco pricing is similar - http://www.cisco.c= om/web/strategy/government/wsca/pricelist_archive.html Feel free to find 's= how diag' for a CRS-1 (or -3) and do your own calculations=E2=80=A6

    = In  the real world (what we are talking about here!), everyone gets a reasonable discount off list prices, but that discount is far from 100% :-= P

    What percentage more should I be willing to pay to be formally cor= rect / RFC compliant? Or to support some niche use? How do I justify spendi= ng an additional X% to my bean-counters? What value can I point at? Seeing = as things are working just fine without extensions headers at the moment, a= nd the Internet Protocol Police have no enforcement power, it is very hard = to justify any X, let alone the type of X that I've heard from vendors=E2= =80=A6.

    And no, additional bits in my packets for diagnostics is not= the value here, I'm managing just fine without them, thanks though.

    Yes, 'tis sad when the development of protocols / deployment of featur= es is impacted by business[0] considerations -- welcome to the real world.<= br>
    W

    [0]: Or by physics ( like C / thermodynamics), or by techno= logy (like power and cooling), or by politics, or by IPR, or by legacy considerations, or ...

    >
    > Steinar Haug, AS 2116
    > = _______________________________________________
    > v6ops mailing list<= br>> v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops<= br>>

    --
    "Go on, prove me wrong. Destroy the fabric of the uni= verse. See if I care."  -- Terry Prachett


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


    =
    ---1051860855-503698149-1370647008=:49387-- From nalini.elkins@insidethestack.com Fri Jun 7 16:18:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FD421F991F for ; Fri, 7 Jun 2013 16:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.570, 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 cVoTySzfWX+w for ; Fri, 7 Jun 2013 16:18:45 -0700 (PDT) Received: from nm26-vm0.access.bullet.mail.mud.yahoo.com (nm26-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97F21F8FEC for ; Fri, 7 Jun 2013 16:18:45 -0700 (PDT) Received: from [66.94.237.192] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 23:18:45 -0000 Received: from [66.94.237.122] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 23:18:45 -0000 Received: from [127.0.0.1] by omp1027.access.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 23:18:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 195723.80840.bm@omp1027.access.mail.mud.yahoo.com Received: (qmail 52729 invoked by uid 60001); 7 Jun 2013 23:18:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370647124; bh=/Cng3vz3L2SWzrE1FTu0BNIFW+xs8VVEHJev9BAewFU=; 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=x3npxKyGCj/5H0VKONmMGlI5YIMiDRbXGoDVq6Y6ZkzMcYOoZBkZaYxyUEo5vmG81Qnk7CRk1XsMr09YB5UVxgGhZImuwVwdi3lMaiRV9t8JW9HZcwvPfRAJ/9ehBIfgfDFPX1n87O63pa3rsGH0GvTEFzkzcP3S1kbjdJxIOEg= X-YMail-OSG: FMSDLB8VM1lcQvExIXePc1sfImyo5BQrB8x1k.c9m2QDjl. IOo180FFkGnInYb1j6_YFoCRXALr5emwQV2qw_5e837uGcroJoOotMpcem8G SVxpsBgY72sAxbmf1MIraAigxy5Z4OZ591pFxGKeRjBqhXi3AZMKHyOI5pN7 Vd2onSkLkfNj9CqAQ6LO49Sev7deXJoLPzkqedqXBS8L4sU9zSHw7yl.EXLV JtJznFov20CaWb9s8hSSlXMLETt6Dpy_8PbLysoQA7rCEDAoCrUBcD7LQSJk DfCDDT6UvHvIy5cFbMAJAh4w3QoJf4Tg7stZ5u9ww05kygTIi4y322BboN8I w9iJaa5FS5qocp7xdr0UYYcepDk6S79eH7pdawm80hiyT.tBY2DkYOFiS8sf xfT_HDnd2BFAUA3Rgl5CyImYt_Eno81AoW189cdvQZguscIwJa5lReQ7WAmi jJKYMM29ZYmy79wEn2FwEfmGlPdWL38M5iNl_mTeBWdQ7Y89SWZj6PWPOr4p 2t81LPudc0ltmVPh8IzbF6cOl.6uLTTGpbOVyO7bVMkzNjLJe.kaa2u67rdz THidl5RF4kt4OtperGG07EgPhbpHv_1FUOIcfWxm5bH401PJUWkKmNo1W3U6 pPItrTDwnykBhnd2NPiwPTfn1Xw-- Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Fri, 07 Jun 2013 16:18:44 PDT X-Rocket-MIMEInfo: 002.001, Pj5XZWxsLCBIQkggaXMgdGhlICpjb3JyZWN0KiBwbGFjZSB0byBwdXQgdGhpbmdzIHRoYXQgYXJlIGV4YW1pbmVkIHBlci1ob3AgOy0pCgoKTWF5YmUgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBidXQgSSBhbSBub3Qgc2VlaW5nIHdoeSB0aGUgaGVhZGVyIHdlIGFyZSBwcm9wb3NpbmcgaGFzIHRvIGJlIGxvb2tlZCBhdCBieSBBTlkgaW50ZXJtZWRpYXRlIGhvcC4gwqBUaGUgc291cmNlIG5vZGUgc3RpY2tzIGluIHRoZSB0aW1lc3RhbXAgYW5kIHBhY2tldCBzZXF1ZW5jZSBudW1iZXIgJiB3ZSBhcmUgYWxsIHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> Message-ID: <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 16:18:44 -0700 (PDT) From: Nalini Elkins To: Joe Touch In-Reply-To: <51B21F57.2000705@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-625423803-1370647124=:51536" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 23:18:51 -0000 --36908767-625423803-1370647124=:51536 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>Well, HBH is the *correct* place to put things that are examined per-hop = ;-)=0A=0A=0AMaybe I am missing something but I am not seeing why the header= we are proposing has to be looked at by ANY intermediate hop. =A0The sourc= e node sticks in the timestamp and packet sequence number & we are all set.= =A0Why would that need to be in a HBH header?=0A=A0=0AThanks,=0A=0A=0ANali= ni Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com= =0A=0A=0A=0A________________________________=0A From: Joe Touch =0ATo: Nalini Elkins =0ACc: Joel M. = Halpern ; "v6ops@ietf.org" =0ASent: F= riday, June 7, 2013 10:58 AM=0ASubject: Re: [v6ops] new draft: draft-elkins= -v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0A=0AOn 6/7/2013 10:07 AM, Nalin= i Elkins wrote:=0A>>>So, correct me if I'm wrong, but isn't this discussion= then about=0A>=0A>>>=A0 =A0 what do you propose to put in the HBH header,= =0A>>>=A0 =A0 and is it safe and worth the cost?=0A>=0A> Well, we are actua= lly using the Destination Options header and not=0A> hop-by-hop.=A0 But, sa= me points.=0A=0AWell, HBH is the *correct* place to put things that are exa= mined per-hop ;-)=0A=0A>>>But ignoring packets that use the chained headers= that follow is a non-starter for IPv6.=0A>=0A> YES!!!!!=A0 Could not agre= e more!=A0 So now academia and those of us with=0A> our hands completely d= irty are in complete agreement.=A0 There must be=0A> some kind of alignment= of the stars or something!=0A=0AFWIW, ISI may be part of USC, but I've see= n more academic positions in =0Aindustry.=0A=0AJoe --36908767-625423803-1370647124=:51536 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    >>Well, HBH is the *correct* place to put thing= s that are examined per-hop ;-)

    <= span style=3D"color: rgb(69, 69, 69); font-family: 'Helvetica Neue', Helvet= ica, Arial, sans-serif; font-size: 12px;">Maybe I am missing something but = I am not seeing why the header we are proposing has to be looked at by ANY inte= rmediate hop.  The source node sticks in the timestamp and packet sequ= ence number & we are all set.  Why would that need to be in a HBH = header?
     
    Thanks,

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

    = From: Joe Touch <touch@isi.edu>
    To: Nalini Elkins <nalini.elkins@insidethesta= ck.com>
    Cc: Joel M.= Halpern <jmh@joelhalpern.com>; "v6ops@ietf.org" <v6ops@ietf.org&g= t;
    Sent: Friday, June 7, 201= 3 10:58 AM
    Subject: Re= : [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

    =0A

    On 6/7/2013 10:07 A= M, Nalini Elkins wrote:
    >>>So, correct me if I'm wrong, but isn= 't this discussion then about
    >
    >>>    what do = you propose to put in the HBH header,
    >>>    and is i= t safe and worth the cost?
    >
    > Well, we are actually using the = Destination Options header and not
    > hop-by-hop.  But, same poin= ts.

    Well, HBH is the *correct* place to put things that are examined= per-hop ;-)

    >>>But ignoring packets that use the chained h= eaders that follow is a non-starter for IPv6.
    >
    > YES!!!!! = ; Could not agree more!  So now academia and those of us with
    >= ; our hands completely dirty are in complete agreement.  There must be=
    > some kind of alignment of the stars or something!

    FWIW, ISI= may be part of USC, but I've seen more academic positions in
    industry.=

    Joe


    --36908767-625423803-1370647124=:51536-- From touch@isi.edu Fri Jun 7 16:33:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFAD21F99B9 for ; Fri, 7 Jun 2013 16:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.074 X-Spam-Level: X-Spam-Status: No, score=-105.074 tagged_above=-999 required=5 tests=[AWL=1.525, 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 x3nPdHsLfMnA for ; Fri, 7 Jun 2013 16:33:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 534BC21F99A3 for ; Fri, 7 Jun 2013 16:33:09 -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 r57NW5f2020161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 16:32:05 -0700 (PDT) Message-ID: <51B26D6C.8050706@isi.edu> Date: Fri, 07 Jun 2013 16:31: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: Nalini Elkins References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 23:33:16 -0000 On 6/7/2013 4:18 PM, Nalini Elkins wrote: >>>Well, HBH is the *correct* place to put things that are examined per-hop ;-) > > Maybe I am missing something but I am not seeing why the header we are > proposing has to be looked at by ANY intermediate hop. The source node > sticks in the timestamp and packet sequence number & we are all set. > Why would that need to be in a HBH header? It wounldn't unless you need it to be examined by a router. If it's only examined by the endpoints, it could be elsewhere. The point of the HBH header is to place all of the info a router should *ever* need to look at (that isn't in the main IPv6 header) in one place that's easy to find and parse. Joe From nalini.elkins@insidethestack.com Fri Jun 7 16:59:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9840A21F99E2 for ; Fri, 7 Jun 2013 16:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.489, 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 FG8IIgKXyAhL for ; Fri, 7 Jun 2013 16:59:52 -0700 (PDT) Received: from nm16-vm0.access.bullet.mail.sp2.yahoo.com (nm16-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE0B21F99DE for ; Fri, 7 Jun 2013 16:59:52 -0700 (PDT) Received: from [98.139.44.98] by nm16.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 23:59:51 -0000 Received: from [98.139.44.84] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 23:59:51 -0000 Received: from [127.0.0.1] by omp1021.access.mail.sp2.yahoo.com with NNFMP; 07 Jun 2013 23:59:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 849868.53374.bm@omp1021.access.mail.sp2.yahoo.com Received: (qmail 98842 invoked by uid 60001); 7 Jun 2013 23:59:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370649591; bh=SkmPPScmRkXsQu0AH17sbLNNS3+fVcsd64/VKPVG0Fk=; 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=KKxi7zm19cMF6Qi2IHjq5sQKbQ9EtUR1l1kW0DDgytUBCBiYQWoi+5Z2M1Q2dCwpRt7/8RQREdnpJ8YiIC6+eu53/65LhfFqV9ZUZK34MTMKr98i+m+5dHkHwL/i1KTp86mWITOqoNCgB528lg3VTJOZgbZpYd6aAjRQLzntoOA= X-YMail-OSG: H6G0C6cVM1kKdRg9bdlwLSWAQTBGiJdwy_kWxMgyZv0Psmo gRXX3kjAcr11ZYYk1s.1zNP8FH1lapBSjao7StltoiCf.pbluNQPae03qK3u VQeBMhPXhR_aEkYCVDlhYIFnOXLCFxDD1sZ.ILbwF0tXdSnFwiwhc9JvPspx EVvUZi0LJESQYEcQ9ML_ZRDHCUf.yseMKOoSZXoUKiLpcE.uuGHOjDeC7LOQ hNjuZFCFRryuDVMnvrzKqhV6c.SU1SdCYJp8V8y5f1467t43m5kTHTyV9G4o TGIAlwh8hCTUCuugZy7qrqipmyJt6RseOHDgLsHLpqMXgfG1eTzcBojnj9dF px1pVY3TxAFOd9jws_dx7AA3lpF8FY_9d4BnCV8pH_Oje3WkBgH9NbhPrybe AxioqIvirRYqhVkfW5rx6X_c0NvBMI1XhO.cLJvDbBGFVN2ylgWnhZcIrgP8 VpI2vKDURmc9IrKQNUJMdmN9YkBSabTWBO6uNJ30L922lGw.ZRkX14.XaolJ YasajBX89WkfZDagGCyamMP4ErHRY2K7C2bmIZH7eg1I2peSXubq7LUU3 Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Fri, 07 Jun 2013 16:59:50 PDT X-Rocket-MIMEInfo: 002.001, CgpPbiA2LzcvMjAxMyA0OjE4IFBNLCBOYWxpbmkgRWxraW5zIHdyb3RlOgo.Pj4gV2VsbCwgSEJIIGlzIHRoZSAqY29ycmVjdCogcGxhY2UgdG8gcHV0IHRoaW5ncyB0aGF0IGFyZSBleGFtaW5lZCBwZXItaG9wIDstKQo.IAo.IE1heWJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgYnV0IEkgYW0gbm90IHNlZWluZyB3aHkgdGhlIGhlYWRlciB3ZSBhcmUKPiBwcm9wb3NpbmcgaGFzIHRvIGJlIGxvb2tlZCBhdCBieSBBTlkgaW50ZXJtZWRpYXRlIGhvcC7CoCBUaGUgc291cmNlIG5vZGUKPiBzdGlja3MgaW4gdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> Message-ID: <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 16:59:50 -0700 (PDT) From: Nalini Elkins To: Joe Touch In-Reply-To: <51B26D6C.8050706@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-402608383-1370649590=:98588" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 23:59:58 -0000 ---153701192-402608383-1370649590=:98588 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AOn 6/7/2013 4:18 PM, Nalini Elkins wrote:=0A>>> Well, HBH is the *cor= rect* place to put things that are examined per-hop ;-)=0A> =0A> Maybe I am= missing something but I am not seeing why the header we are=0A> proposing = has to be looked at by ANY intermediate hop.=A0 The source node=0A> sticks = in the timestamp and packet sequence number & we are all set.=0A>=A0 Why w= ould that need to be in a HBH header?=0A=0A>>It wounldn't unless you need i= t to be examined by a router. If it's only examined by the endpoints, it co= uld be elsewhere.=0A=0A>>The point of the HBH header is to place all of the= info a router should *ever* need to look at (that isn't in the main IPv6 h= eader) in one place that's easy to find and parse.=0A=0ASure. =A0That is wh= y we put it in the Dest Ops header. =A0No need for a router to ever bother = with our little guy!=0A=0AJoe ---153701192-402608383-1370649590=:98588 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

    On 6/7/2013 4:18 PM, Nalini Elkins wrot= e:
    >>> Well, HBH is the *correct* place to put things that are = examined per-hop ;-)
    >
    > Maybe I am missing something but I am= not seeing why the header we are
    > proposing has to be looked at by = ANY intermediate hop.  The source node
    > sticks in the timestamp= and packet sequence number & we are all set.
    >  Why would = that need to be in a HBH header?

    >>It wounldn't unless you nee= d it to be examined by a router. If it's only examined by the endpoints, it= could be elsewhere.

    >>The point of the HBH header is to place all of the info a router should *ever* need to look at (that isn't in the = main IPv6 header) in one place that's easy to find and parse.

    Sure.  = ;That is why we put it in the Dest Ops header.  No need for a router t= o ever bother with our little guy!

    Joe



    =
    ---153701192-402608383-1370649590=:98588-- From warren@kumari.net Fri Jun 7 17:22:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337A721F99EB for ; Fri, 7 Jun 2013 17:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_20=-0.74, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=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 2GA+4t3qWzM7 for ; Fri, 7 Jun 2013 17:22:54 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC01D21F99D8 for ; Fri, 7 Jun 2013 17:22:53 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id 662061B40C48; Fri, 7 Jun 2013 20:22:50 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 20:22:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> To: Nalini Elkins X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 00:22:58 -0000 On Jun 7, 2013, at 7:59 PM, Nalini Elkins = wrote: >=20 > On 6/7/2013 4:18 PM, Nalini Elkins wrote: > >>> Well, HBH is the *correct* place to put things that are examined = per-hop ;-) > >=20 > > Maybe I am missing something but I am not seeing why the header we = are > > proposing has to be looked at by ANY intermediate hop. The source = node > > sticks in the timestamp and packet sequence number & we are all set. > > Why would that need to be in a HBH header? >=20 > >>It wounldn't unless you need it to be examined by a router. If it's = only examined by the endpoints, it could be elsewhere. >=20 > >>The point of the HBH header is to place all of the info a router = should *ever* need to look at (that isn't in the main IPv6 header) in = one place that's easy to find and parse. >=20 > Sure. That is why we put it in the Dest Ops header. No need for a = router to ever bother with our little guy! Sure, but the Dest Ops header shows up before the L4 information, and so = pushed the L4 header further out. Someone (it may have been Ron Bonica, hopefully he doesn't mind me = mentioning it) suggested reordering the header chain so that it goes IP = -> HBH -> L4 / Payload -:> Dest Options. This is not a stupid idea=85. Anyway, I decided that maybe having some data here would be useful, so I = decided to see how many sites from Dan Wing's list = (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt)= I could: A: make an IPv6 connection to and=20 B: would accept packets where the first header was not the payload. So, here are some stats. I connect (using scapy) and do an HTTP GET. If = that works, I try again, with an empty Destination Options (the only = thing I could figure out that would move the payload up and not = influence routing / seem weird). My methodology may be broken, and the = code (pasted at the bottom *certainly* is horrendous, but at least we = have *some* data. And kvetching about methodology, data is (IMO) more = interesting than where are currently are, which seems to not be = progressing=85=20 [SNIP] www.ssa.gov does not work if there is a Destination Option Extension = Header www.techtudo.com.br does not work if there is a Destination Option = Extension Header www.tradebit.com does NOT seem to work on IPv6 tutsplus.com does NOT seem to work on IPv6 www.turktelekom.com.tr does NOT seem to work on IPv6 www.ub.ac.id does not work if there is a Destination Option Extension = Header Processed 1100 sites, 6.173994 work with extension headers www.unesp.br does NOT seem to work on IPv6 www.newsen.com does NOT seem to work on IPv6 Working V6 sites: 1069, Working v6 sites with EH: 66. Percent: 6.173994 ------------------------------------------------------------ Working EH sites: acesso.uol.com.br www.adrenaline.uol.com.br www.automobile.it www.automobile.fr band.uol.com.br www.batepapo.uol.com.br www.blogfolha.uol.com.br blogdojuca.uol.com.br www.blogosfera.uol.com.br www.bol.uol.com.br www.bpm.uol.com.br www.busca.uol.com.br caras.uol.com.br www.celebridades.uol.com.br www.clickjogos.uol.com.br www.cms.gov copadomundo.uol.com.br www.clixboom.com www.disponivel.uol.com.br economia.uol.com.br educacao.uol.com.br www.empregocerto.uol.com.br esporte.uol.com.br www.folha.uol.com.br gizmodo.uol.com.br www.idgnow.uol.com.br www.harvard.edu www.jogosonlinegratis.uol.com.br www.indosat.com www.levelupgames.uol.com.br www.ed.gov www.mail.uol.com.br www.medicare.gov meusjogosdemeninas.uol.com.br www.mobile.de www.mobile.ro www.mulher.uol.com.br www.musica.uol.com.br www.ne10.uol.com.br www.noticias.uol.com.br olhardigital.uol.com.br www.omelete.uol.com.br portalcorreio.uol.com.br www.radio.uol.com.br www.radardedescontos.com.br www.ripe.net sac.uol.com.br www.shopping.uol.com.br www.tecnologia.uol.com.br www.televisao.uol.com.br www.todaoferta.uol.com.br www.tportal.hr www.tpg.com.au www.tudogostoso.uol.com.br www.tvuol.uol.com.br www.uol.com.br www.uolhost.com.br www.userapi.com www.virgula.uol.com.br www.vk.me www.turkcell.com.tr www.vk.com www.xpg.uol.com.br ziggi.uol.com.br zipmail.uol.com.br www.xl.co.id The majority of these are uol.com.br hosts. If I count them as one = "site", then 1.7% of sites can handle packets with a dest options = header.=20 This is more than I had expected, but keep in mind that this is a = *single* Destination Option header (8 bytes (2 + PadN of 6)) I'll extend this sometime to see how the numbers change when there is = more (16, 32, 48, etc) header. Warning: Ugly tossed together code: #!/usr/bin/ # # $Revision:: $ # $Date:: $ # $Author:: $ # $HeadURL:: $ # Copyright: Warren Kumari (warren@kumari.net) -- 2013 # from scapy.all import * def SupportsEH(name): try: a=3Dsr1(IPv6(dst=3Dname)/TCP(dport=3D80)/'GET / HTTP/1.0\r\n\r\n', = timeout=3D2, verbose=3D0) except socket.gaierror: print 'Cannot resolve %s' % name return (False, False) if a: b=3Dsr1(IPv6(dst=3Dname)/IPv6ExtHdrDestOpt()/TCP(dport=3D80)/'GET / = HTTP/1.0\r\n\r\n', timeout=3D2, verbose=3D0) if b: print '*** %s works with extension headers! ***' % name return (True, True) else: print '%s does not work if there is a Destination Option Extension = Header' % name return (True, False) else: print '%s does NOT seem to work on IPv6' % name return (False, False) def ReadSiteList(filename): sites=3D[] for line in open(filename).read().splitlines(): try: site =3D line.split()[0] except IndexError: pass sites.append(site) return sites def main(): v6_sites=3D[] eh_sites=3D[] count =3D 0 # From: = http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt sites =3D ReadSiteList('ipv6-aaaa.2013-06-07_0800.txt') for site in sites: count +=3D1 (v6, eh) =3D SupportsEH(site) if v6: v6_sites.append(site) if eh: eh_sites.append(site) if not count % 20: print 'Processed %d sites, %f work with extension headers\n' % = (count, = float(len(eh_sites)) / len(v6_sites) * 100.0) print 'Working V6 sites: %d, Working v6 sites with EH: %d. Percent: = %f' % (len(v6_sites), len (eh_sites), float(len(eh_sites)) / = len(v6_sites) * 100.0) print '-'*60 print 'Working EH sites:' print '\n'.join([site for site in eh_sites]) =20 if __name__ =3D=3D '__main__': main() W >=20 > Joe >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 From touch@isi.edu Fri Jun 7 17:34:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AC421F9A06 for ; Fri, 7 Jun 2013 17:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, 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 kuN7bVd6kkWw for ; Fri, 7 Jun 2013 17:34:37 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8AE21F9A00 for ; Fri, 7 Jun 2013 17:34:36 -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 r580YCPS026149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 17:34:12 -0700 (PDT) Message-ID: <51B27BFB.9010801@isi.edu> Date: Fri, 07 Jun 2013 17:34:03 -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: Warren Kumari References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> In-Reply-To: <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 00:34:42 -0000 On 6/7/2013 5:22 PM, Warren Kumari wrote: > > On Jun 7, 2013, at 7:59 PM, Nalini Elkins wrote: > >> >> On 6/7/2013 4:18 PM, Nalini Elkins wrote: >>>>> Well, HBH is the *correct* place to put things that are examined per-hop ;-) >>> >>> Maybe I am missing something but I am not seeing why the header we are >>> proposing has to be looked at by ANY intermediate hop. The source node >>> sticks in the timestamp and packet sequence number & we are all set. >>> Why would that need to be in a HBH header? >> >>>> It wounldn't unless you need it to be examined by a router. If it's only examined by the endpoints, it could be elsewhere. >> >>>> The point of the HBH header is to place all of the info a router should *ever* need to look at (that isn't in the main IPv6 header) in one place that's easy to find and parse. >> >> Sure. That is why we put it in the Dest Ops header. No need for a router to ever bother with our little guy! > > Sure, but the Dest Ops header shows up before the L4 information, and so pushed the L4 header further out. > > Someone (it may have been Ron Bonica, hopefully he doesn't mind me > mentioning it) suggested reordering the header chain so that it goes IP > -> HBH -> L4 / Payload -:> Dest Options. > > This is not a stupid idea…. Oh, don't be so sure ;-) Where are the other headers? HBH and DestOpts are only two; you're forgetting fragmentation, encryption, etc. If you move those two - in particular - after L4, then how do you even know that what you think is L4 control info (ports) is really there? vs. some other data, or an encrypted copy? Joe From nalini.elkins@insidethestack.com Fri Jun 7 18:17:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0CB21F842E for ; Fri, 7 Jun 2013 18:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGNQKdHVR26T for ; Fri, 7 Jun 2013 18:16:54 -0700 (PDT) Received: from nm29-vm0.access.bullet.mail.sp2.yahoo.com (nm29-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.192]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA321E804B for ; Fri, 7 Jun 2013 18:16:53 -0700 (PDT) Received: from [98.139.44.97] by nm29.access.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jun 2013 01:16:53 -0000 Received: from [98.139.44.75] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jun 2013 01:16:53 -0000 Received: from [127.0.0.1] by omp1012.access.mail.sp2.yahoo.com with NNFMP; 08 Jun 2013 01:16:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 774435.85258.bm@omp1012.access.mail.sp2.yahoo.com Received: (qmail 66471 invoked by uid 60001); 8 Jun 2013 01:16:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370654213; bh=ghW+Y2uYBsl/93dc0ZOIb+QXXHwhTMKBhm7Azx/Zjks=; 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=xYwAy48QDa3M/mHfZHBMP0MtR/XWu2wgt6R53urRvhyA2PWUsWuHyX41spkQ2/ig/3LD/c2p/Wj7u8lflyzNeklIuBRVfgpgJkaVh14d19Umz/H4gdzXfARIzOCrGPX9myr8b7rx7oqBo5pPKQzMNrUf73h+2qMerjwSsXBl2W4= X-YMail-OSG: cwE7.AcVM1kDX34ALDgRAqHWMbJohb0zfYgOJ8h6DwnK2jY P0ccXOpAMrFS0_auJCJV6 Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Fri, 07 Jun 2013 18:16:52 PDT X-Rocket-MIMEInfo: 002.001, V2FycmVuLAoKVmVyeSBjb29sIQoKTm93LCBJIGtub3cgb25lIHNpdGUgaGFzIHRvbGQgbWUgdGhhdCB0aGV5IGRpc2FibGUgZXh0ZW5zaW9uIGhlYWRlcnMgb24gdGhlIG91dHNpZGUgKGZhY2luZyB0aGUgSW50ZXJuZXQpIGFuZCBlbmFibGUgdGhlbSBvbiB0aGUgaW50ZXJuYWwgbmV0d29yay4KwqAKVGhhbmtzLAoKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18BMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> Message-ID: <1370654212.56362.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 18:16:52 -0700 (PDT) From: Nalini Elkins To: Warren Kumari In-Reply-To: <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-638012387-1370654212=:56362" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 01:17:01 -0000 --1619178251-638012387-1370654212=:56362 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Warren,=0A=0AVery cool!=0A=0ANow, I know one site has told me that they dis= able extension headers on the outside (facing the Internet) and enable them= on the internal network.=0A=C2=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside= Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______= __________________________=0A From: Warren Kumari =0ATo:= Nalini Elkins =0ACc: Warren Kumari ; Joe Touch ; "v6ops@ietf.org" =0ASent: Friday, June 7, 2013 5:22 PM=0ASubject: Re: [v6ops] new draft: = draft-elkins-v6ops-ipv6-end-to-end-rt-needed=0A =0A=0A=0AOn Jun 7, 2013, at= 7:59 PM, Nalini Elkins wrote:=0A=0A> = =0A> On 6/7/2013 4:18 PM, Nalini Elkins wrote:=0A> >>> Well, HBH is the *co= rrect* place to put things that are examined per-hop ;-)=0A> > =0A> > Maybe= I am missing something but I am not seeing why the header we are=0A> > pro= posing has to be looked at by ANY intermediate hop.=C2=A0 The source node= =0A> > sticks in the timestamp and packet sequence number & we are all set.= =0A> >=C2=A0 Why would that need to be in a HBH header?=0A> =0A> >>It wounl= dn't unless you need it to be examined by a router. If it's only examined b= y the endpoints, it could be elsewhere.=0A> =0A> >>The point of the HBH hea= der is to place all of the info a router should *ever* need to look at (tha= t isn't in the main IPv6 header) in one place that's easy to find and parse= .=0A> =0A> Sure.=C2=A0 That is why we put it in the Dest Ops header.=C2=A0 = No need for a router to ever bother with our little guy!=0A=0ASure, but the= Dest Ops header shows up before the L4 information, and so pushed the L4 h= eader further out.=0A=0ASomeone (it may have been Ron Bonica, hopefully he = doesn't mind me mentioning it) suggested reordering the header chain so tha= t it goes IP -> HBH -> L4 / Payload -:> Dest Options.=0AThis is not a stupi= d idea=E2=80=A6.=0A=0AAnyway, I decided that maybe having some data here wo= uld be useful, so I decided to see how many sites from Dan Wing's list (htt= p://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt) I co= uld:=0AA: make an IPv6 connection to and =0AB: would accept packets where t= he first header was not the payload.=0A=0ASo, here are some stats. I connec= t (using scapy) and do an HTTP GET. If that works, I try again, with an emp= ty Destination Options (the only thing I could figure out that would move t= he payload up and not influence routing / seem weird). My methodology may b= e broken, and the code (pasted at the bottom *certainly* is horrendous, but= at least we have *some* data. And kvetching about methodology, data is (IM= O) more interesting than where are currently are, which seems to not be pro= gressing=E2=80=A6 =0A=0A=0A[SNIP]=0Awww.ssa.gov does not work if there is a= Destination Option Extension Header=0Awww.techtudo.com.br does not work if= there is a Destination Option Extension Header=0Awww.tradebit.com does NOT= seem to work on IPv6=0Atutsplus.com does NOT seem to work on IPv6=0Awww.tu= rktelekom.com.tr does NOT seem to work on IPv6=0Awww.ub.ac.id does not work= if there is a Destination Option Extension Header=0AProcessed 1100 sites, = 6.173994 work with extension headers=0A=0Awww.unesp.br does NOT seem to wor= k on IPv6=0Awww.newsen.com does NOT seem to work on IPv6=0AWorking V6 sites= : 1069, Working v6 sites with EH: 66. Percent: 6.173994=0A-----------------= -------------------------------------------=0AWorking EH sites:=0Aacesso.uo= l.com.br=0Awww.adrenaline.uol.com.br=0Awww.automobile.it=0Awww.automobile.f= r=0Aband.uol.com.br=0Awww.batepapo.uol.com.br=0Awww.blogfolha.uol.com.br=0A= blogdojuca.uol.com.br=0Awww.blogosfera.uol.com.br=0Awww.bol.uol.com.br=0Aww= w.bpm.uol.com.br=0Awww.busca.uol.com.br=0Acaras.uol.com.br=0Awww.celebridad= es.uol.com.br=0Awww.clickjogos.uol.com.br=0Awww.cms.gov=0Acopadomundo.uol.c= om.br=0Awww.clixboom.com=0Awww.disponivel.uol.com.br=0Aeconomia.uol.com.br= =0Aeducacao.uol.com.br=0Awww.empregocerto.uol.com.br=0Aesporte.uol.com.br= =0Awww.folha.uol.com.br=0Agizmodo.uol.com.br=0Awww.idgnow.uol.com.br=0Awww.= harvard.edu=0Awww.jogosonlinegratis.uol.com.br=0Awww.indosat.com=0Awww.leve= lupgames.uol.com.br=0Awww.ed.gov=0Awww.mail.uol.com.br=0Awww.medicare.gov= =0Ameusjogosdemeninas.uol.com.br=0Awww.mobile.de=0Awww.mobile.ro=0Awww.mulh= er.uol.com.br=0Awww.musica.uol.com.br=0Awww.ne10.uol.com.br=0Awww.noticias.= uol.com.br=0Aolhardigital.uol.com.br=0Awww.omelete.uol.com.br=0Aportalcorre= io.uol.com.br=0Awww.radio.uol.com.br=0Awww.radardedescontos.com.br=0Awww.ri= pe.net=0Asac.uol.com.br=0Awww.shopping.uol.com.br=0Awww.tecnologia.uol.com.= br=0Awww.televisao.uol.com.br=0Awww.todaoferta.uol.com.br=0Awww.tportal.hr= =0Awww.tpg.com.au=0Awww.tudogostoso.uol.com.br=0Awww.tvuol.uol.com.br=0Awww= .uol.com.br=0Awww.uolhost.com.br=0Awww.userapi.com=0Awww.virgula.uol.com.br= =0Awww.vk.me=0Awww.turkcell.com.tr=0Awww.vk.com=0Awww.xpg.uol.com.br=0Azigg= i.uol.com.br=0Azipmail.uol.com.br=0Awww.xl.co.id=0A=0A=0AThe majority of th= ese are uol.com.br hosts. If I count them as one "site", then 1.7% of sites= can handle packets with a dest options header. =0AThis is more than I had = expected, but keep in mind that this is a *single* Destination Option heade= r (8 bytes (2 + PadN of 6))=0A=0AI'll extend this sometime to see how the n= umbers change when there is more (16, 32, 48, etc) header.=0A=0A=0AWarning:= Ugly tossed together code:=0A=0A#!/usr/bin/=0A#=0A# $Revision::=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 $=0A# $Date::=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 $=0A# $Author::=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 $=0A# $HeadURL::=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 $=0A# Copyright: Warren Kumari (warren@= kumari.net) -- 2013=0A#=0A=0Afrom scapy.all import *=0A=0Adef SupportsEH(na= me):=0A=C2=A0 try:=0A=C2=A0 =C2=A0 a=3Dsr1(IPv6(dst=3Dname)/TCP(dport=3D80)= /'GET / HTTP/1.0\r\n\r\n', timeout=3D2, verbose=3D0)=0A=C2=A0 except socket= .gaierror:=0A=C2=A0 =C2=A0 print 'Cannot resolve %s' % name=0A=C2=A0 =C2=A0= return (False, False)=0A=C2=A0 if a:=0A=C2=A0 =C2=A0 b=3Dsr1(IPv6(dst=3Dna= me)/IPv6ExtHdrDestOpt()/TCP(dport=3D80)/'GET / HTTP/1.0\r\n\r\n', timeout= =3D2, verbose=3D0)=0A=C2=A0 =C2=A0 if b:=0A=C2=A0 =C2=A0 =C2=A0 print '*** = %s works with extension headers! ***' % name=0A=C2=A0 =C2=A0 =C2=A0 return = (True, True)=0A=C2=A0 =C2=A0 else:=0A=C2=A0 =C2=A0 =C2=A0 print '%s does no= t work if there is a Destination Option Extension Header' % name=0A=C2=A0 = =C2=A0 =C2=A0 return (True, False)=0A=C2=A0 else:=0A=C2=A0 =C2=A0 print '%s= does NOT seem to work on IPv6' % name=0A=C2=A0 =C2=A0 return (False, False= )=0A=0A=0Adef ReadSiteList(filename):=0A=C2=A0 sites=3D[]=0A=C2=A0 for line= in open(filename).read().splitlines():=0A=C2=A0 =C2=A0 try:=0A=C2=A0 =C2= =A0 =C2=A0 site =3D line.split()[0]=0A=C2=A0 =C2=A0 except IndexError:=0A= =C2=A0 =C2=A0 =C2=A0 pass=0A=C2=A0 =C2=A0 sites.append(site)=0A=C2=A0 retur= n sites=0A=0Adef main():=0A=C2=A0 v6_sites=3D[]=0A=C2=A0 eh_sites=3D[]=0A= =C2=A0 count =3D 0=0A=C2=A0 # From: http://www.employees.org/~dwing/aaaa-st= ats/ipv6-aaaa.2013-06-07_0800.txt=0A=C2=A0 sites =3D ReadSiteList('ipv6-aaa= a.2013-06-07_0800.txt')=0A=C2=A0 for site in sites:=0A=C2=A0 =C2=A0 count += =3D1=0A=C2=A0 =C2=A0 (v6, eh) =3D SupportsEH(site)=0A=C2=A0 =C2=A0 if v6:= =0A=C2=A0 =C2=A0 =C2=A0 v6_sites.append(site)=0A=C2=A0 =C2=A0 if eh:=0A=C2= =A0 =C2=A0 =C2=A0 eh_sites.append(site)=0A=C2=A0 =C2=A0 if not count % 20:= =0A=C2=A0 =C2=A0 =C2=A0 print 'Processed %d sites, %f work with extension h= eaders\n' % (count,=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 float(len(eh_sites)) / len(v6_sites)= * 100.0)=0A=0A=C2=A0 print 'Working V6 sites: %d, Working v6 sites with EH= : %d. Percent: %f' % (len(v6_sites), len (eh_sites), float(len(eh_sites)) /= len(v6_sites) * 100.0)=0A=0A=C2=A0 print '-'*60=0A=C2=A0 print 'Working EH= sites:'=0A=C2=A0 print '\n'.join([site for site in eh_sites])=0A=C2=A0 =C2= =A0 =C2=A0 =0A=0Aif __name__ =3D=3D '__main__':=0A=C2=A0 main()=0A=0A=0AW= =0A=0A=0A=0A> =0A> Joe=0A> =0A> =0A> =0A> _________________________________= ______________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ie= tf.org/mailman/listinfo/v6ops=0A=0A--=0A"I think perhaps the most important= problem is that we are trying to understand the fundamental workings of th= e universe via a language devised for telling one another when the best fru= it is." --Terry Prachett --1619178251-638012387-1370654212=:56362 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Warren,
    <= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: arial, helv= etica, sans-serif; background-color: transparent; font-style: normal;">
    Very cool!

    Now, I = know one site has told me that they disable extension headers on the outsid= e (facing the Internet) and enable them on the internal network.
     
    Thanks,

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

    = From:= Warren Kumari <warren@kumari.net>
    To: Nalini Elkins <nalini.elkins@insidethe= stack.com>
    Cc: Warr= en Kumari <warren@kumari.net>; Joe Touch <touch@isi.edu>; "v6op= s@ietf.org" <v6ops@ietf.org>
    Sent: Friday, June 7, 2013 5:22 PM
    Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

    =0A
    On Jun 7, 2013, at 7:59 PM, Nalini Elkins &= lt;nalini.elkins@insidethestack.com> wr= ote:

    >
    > On 6/7/2013 4:18 PM, Nalini Elkins wrote:
    >= >>> Well, HBH is the *correct* place to put things that are exami= ned per-hop ;-)
    > >
    > > Maybe I am missing something but= I am not seeing why the header we are
    > > proposing has to be loo= ked at by ANY intermediate hop.  The source node
    > > sticks i= n the timestamp and packet sequence number & we are all set.
    > &g= t;  Why would that need to be in a HBH header?
    >
    > >&g= t;It wounldn't unless you need it to be examined by a router. If it's only = examined by the endpoints, it could be elsewhere.
    >
    > >>= The point of the HBH header is to place all of the info a router should *ev= er* need to look at (that isn't in the main IPv6 header) in one place that's easy to find and parse.=
    >
    > Sure.  That is why we put it in the Dest Ops header.=   No need for a router to ever bother with our little guy!

    Sure= , but the Dest Ops header shows up before the L4 information, and so pushed= the L4 header further out.

    Someone (it may have been Ron Bonica, ho= pefully he doesn't mind me mentioning it) suggested reordering the header c= hain so that it goes IP -> HBH -> L4 / Payload -:> Dest Options.This is not a stupid idea=E2=80=A6.

    Anyway, I decided that maybe h= aving some data here would be useful, so I decided to see how many sites fr= om Dan Wing's list (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.20= 13-06-07_0800.txt) I could:
    A: make an IPv6 connection to and
    B: wou= ld accept packets where the first header was not the payload.

    So, he= re are some stats. I connect (using scapy) and do an HTTP GET. If that works, I try again, with an empty Destination Options (the only thing I co= uld figure out that would move the payload up and not influence routing / s= eem weird). My methodology may be broken, and the code (pasted at the botto= m *certainly* is horrendous, but at least we have *some* data. And kvetchin= g about methodology, data is (IMO) more interesting than where are currentl= y are, which seems to not be progressing=E2=80=A6


    [SNIP]
    www.ssa.gov does not wor= k if there is a Destination Option Extension Header
    www.techtudo.com.br does not work= if there is a Destination Option Extension Header
    www.tradebit.com does NOT seem to wor= k on IPv6
    tutsplus.co= m does NOT seem to work on IPv6
    www.turktelekom.com.tr does NO= T seem to work on IPv6
    www.ub.ac.id does not work if there is a Destination Option Extension= Header
    Processed 1100 sites, 6.173994 work with extension headers
    www.unesp.br does = NOT seem to work on IPv6
    www.newsen.com does NOT seem to work on IPv6
    Working V6 sites:= 1069, Working v6 sites with EH: 66. Percent: 6.173994
    -----------------= -------------------------------------------
    Working EH sites:
    acesso.uol.com.br
    <= a target=3D"_blank" href=3D"http://www.adrenaline.uol.com.br/">www.adrenali= ne.uol.com.br
    www.automobile.it
    www.automobile.fr
    band.uol.com.br
    www.batepapo.uol.com.br
    www.bl= ogfolha.uol.com.br
    blogdojuca.uol.com.br
    www.blogosfera.uol.com.br
    www.bol.uol.com.br
    www.bpm.uol.com.br<= br>www.busca.uol= .com.br
    caras= .uol.com.br
    www.celebridades.uol.com.br
    www.clickjogos.uol.com.brwww.cms.gov
    copadomundo.uol.co= m.br
    www.clix= boom.com
    www.disponivel.uol.com.br
    economia.uol.com.br
    educacao.uol.com.br
    www.empregocerto.uol.com= .br
    esporte= .uol.com.br
    www.folha.uol.com.br
    gizmodo.uol.com.br
    www.idgnow.uol.com.br
    www.harvard.edu
    www.jogo= sonlinegratis.uol.com.br
    www.indosat.com
    www.levelupgames.uol.com.br
    www.ed.gov
    www.mail.uol.com.br
    www.medicare.gov
    meusjogosdemenin= as.uol.com.br
    ww= w.mobile.de
    www.= mobile.ro
    www.mulher.uol.com.br
    www.musica.uol.co= m.br
    www.n= e10.uol.com.br
    www.noticias.uol.com.br
    olhardigital.uol.com.br
    www.omelete.uol.com.br
    <= a target=3D"_blank" href=3D"http://portalcorreio.uol.com.br/">portalcorreio= .uol.com.br
    www.radio.uol.com.br
    www.radardedescontos.com.br
    www.ripe.net
    sac.uol.com.br
    www.shopping.uol.com.br
    www.tecnologia.uol.com.brwww.televi= sao.uol.com.br
    www.todaoferta.uol.com.br
    www.tportal.hr
    www.tpg.com.au
    www.tudogostoso.uol.com.br
    www.tvuol.uol.com.br
    www.uol.com.br
    www.uolhost.c= om.br
    www.user= api.com
    www.virgula.uol.com.br
    www.vk.me
    www.turkcell.com.tr
    www.vk.com
    www.xpg.uol.com.b= r
    ziggi.uol.com.br
    zipmail.uol.com.br
    www.xl.co.id


    The = majority of these are uol.com.br hosts. If I count them as one "site", then= 1.7% of sites can handle packets with a dest options header.
    This is m= ore than I had expected, but keep in mind that this is a *single* Destinati= on Option header (8 bytes (2 + PadN of 6))

    I'll extend this sometime= to see how the numbers change when there is more (16, 32, 48, etc) header.=


    Warning: Ugly tossed together code:

    #!/usr/bin/
    #
    = # $Revision::                 =                     &nbs= p;       $
    # $Date::          &n= bsp;                                       $
    # $Aut= hor::                    =                      = ;       $
    # $HeadURL::          =                      = ;               $
    # Copyright: Warre= n Kumari (warren@kumari.net) -- 2013
    #

    from scapy.all import *=

    def SupportsEH(name):
      try:
        a=3Dsr1(IPv6(= dst=3Dname)/TCP(dport=3D80)/'GET / HTTP/1.0\r\n\r\n', timeout=3D2, verbose= =3D0)
      except socket.gaierror:
        print 'Cannot reso= lve %s' % name
        return (False, False)
      if a:
    &n= bsp;   b=3Dsr1(IPv6(dst=3Dname)/IPv6ExtHdrDestOpt()/TCP(dport=3D80)/'G= ET / HTTP/1.0\r\n\r\n', timeout=3D2, verbose=3D0)
        if b:
    &nb= sp;     print '*** %s works with extension headers! ***' % name      return (True, True)
        else:
     =     print '%s does not work if there is a Destination Option Ext= ension Header' % name
          return (True, False)
     = ; else:
        print '%s does NOT seem to work on IPv6' % name    return (False, False)


    def ReadSiteList(filename):=
      sites=3D[]
      for line in open(filename).read().splitline= s():
        try:
          site =3D line.split()[0]=
        except IndexError:
          pass
     =   sites.append(site)
      return sites

    def main():
    &nb= sp; v6_sites=3D[]
      eh_sites=3D[]
      count =3D 0
      #= From: http://www.employees.org/~dwing/aaaa-stats/ipv6-a= aaa.2013-06-07_0800.txt
      sites =3D ReadSiteList('ipv6-aaaa.201= 3-06-07_0800.txt')
      for site in sites:
        count +=3D= 1
        (v6, eh) =3D SupportsEH(site)
        if v6:      v6_sites.append(site)
        if eh:
    &nbs= p;     eh_sites.append(site)
        if not count % 20:=
          print 'Processed %d sites, %f work with extension = headers\n' % (count,
                  &n= bsp;                     =                      = ;           float(len(eh_sites)) / len(v6_sites) *= 100.0)

      print 'Working V6 sites: %d, Working v6 sites with EH= : %d. Percent: %f' % (len(v6_sites), len (eh_sites), float(len(eh_sites)) / = len(v6_sites) * 100.0)

      print '-'*60
      print 'Working = EH sites:'
      print '\n'.join([site for site in eh_sites])
     =    

    if __name__ =3D=3D '__main__':
      main()
    <= br>
    W



    >
    > Joe
    >
    >
    >
    >= ; _______________________________________________
    > v6ops mailing lis= t
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops

    --
    "I think perhaps the most important problem is that we are t= rying to understand the fundamental workings of the universe via a language= devised for telling one another when the best fruit is." --Terry Prachett =




    --1619178251-638012387-1370654212=:56362-- From jiangsheng@huawei.com Fri Jun 7 18:58:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: "Manfredi, Albert E" , "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:01:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C471121F9A1C for ; Fri, 7 Jun 2013 19:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 OM2zXKsSj5sc for ; Fri, 7 Jun 2013 19:00:58 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE6121F9A11 for ; Fri, 7 Jun 2013 19:00:46 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id k5so3133585qej.16 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=LTrNm5syLGFMvqubLRbzj5/jUbQ5VMbaG3vYlISuidRn0VW6y90likdZxxDv14GEmb VwNpAbtL3pRWoesDmv8FBs5imvNa7swbDMS06BOA3/2YO/hKQu2AoVvZOkFD9Xu0FxB7 LonKtZ9FyFwCwaAhbErUzfqzKi9SrH2FNbyESmbBWDMYvPJEWBGw0zMa6kKws9ZDCXq/ fcKgEdPK4Y5upPN00RWM0Azh1SEEO0qBA9DTqGHtCA0KNo5CP6bl9rXndftLqAX9x4m3 KeadU6qNIhmHimWPXPysedDPd9BmlJfq+Qx1Q29htNNkYLS7heaW7ljrvT4m/vtxKyzT 3U5w== 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: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1133327067026004de9aea2f X-Gm-Message-State: ALoCoQnA4t+wYWj0+sJQa4kwvHIFoeYLJrPaAyrwlrH3bEuNrOmSTajtc2mRH0BIc7DI5NlieBUnoMY/Ih2mYg+IoHsRSDVTsT4uKunf8jMgbUYptTs4HFPHXsurHcnmOFoJhsz5cjD1nxHVLLJfjcDG9Qf+3GHs8eXHVq6h1nvgLqVdhnq52iNjCAlSlOCQy8AplH2+X9k6 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 02:01:03 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 brian.e.carpenter@gmail.com Fri Jun 7 22:02:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8A721F9923 for ; Fri, 7 Jun 2013 22:02:58 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_75=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 oZTcbs4MrL3N for ; Fri, 7 Jun 2013 22:02:58 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB1321F98AC for ; Fri, 7 Jun 2013 22:02:57 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so7323482iea.25 for ; Fri, 07 Jun 2013 22:02: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=BjNjtRJBZK6uCcB32PzgaDnVxxyLgSJAaNjyLY+db9w=; b=N5riQIEk8GRtcER30S9K7nShZh9Gf85DDB5lPbjeO3u5/dLKd6j0n4ToKeyYsh0/dP NyrAb5MvdqBaGJg06hUkyvrczzjaiEwJjSF66lV+fBLhp7Ou9gh8MoHGV4Zwvl1jwZ93 CCRS2eNNCxiZRhNdkb7s8ZNf/lZ2piY6ApdFtv2SA5MH6aHO+PtOIS660JCq17jLImSX 9XplFHen7mnTpIIViiUp8WeCtFIlKl08bxs7GtQNEOJTEmKIBklqhf02vp8CUzP7zswI tzfWLStNVF4IVr0TeEBgSWsa2uSjP8E/TZRg/AEdW69hK8ldlGXgwpOIarjbHWJb/hcI Tjlg== X-Received: by 10.50.47.105 with SMTP id c9mr341040ign.50.1370667773689; Fri, 07 Jun 2013 22:02:53 -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 it3sm1206787igb.0.2013.06.07.22.02.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Jun 2013 22:02:53 -0700 (PDT) Message-ID: <51B2BB07.2040208@gmail.com> Date: Sat, 08 Jun 2013 17:03:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Mansfield References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 05:02:59 -0000 Scott, Has the Security Area actually reviewed this document? If not, IMHO they certainly need to, PDQ. A few things that caught my eye in a very quick scan: > 7.3.1 Security threats and countermeasures > Threat 7: A Network Address Translation (NAT) device is > commonly deployed on a border of a network and translates > either source or destination IP addresses of a packet in > order to bridge two different types of networks such as > private-global networks and IPv4-IPv6 networks. Particularly, > NAT66, so-called NAT and port translation version 6 (NPTv6), > translates IP addresses of packets between two distinct IPv6 > networks That is wrong. The IETF has not defined NAT66. A correct statement would be: IPv6-to-IPv6 Network Prefix Translation (NPTv6) translates the prefixes of the addresses of packets between two distinct IPv6 networks, but does not translate the interface identifiers and port numbers. This is an Experimental protocol, not on the standards track. (the reference is RFC 6296) Aside: if this is typical of the document's thoroughness and accuracy, that is rather worrying. > Measure 7: IETF is discussing stateless NAT66 (without a > state table) function. As far as I know this is an untrue statement. > Measure 8: To minimize the security risk by forged RA > messages, it is recommended that each host discard all RA > messages with an extremely short lifetime. "Extremely short" isn't actionable. (Also, Measure 10 seems more to the point.) > Measure 18: IDSs have to support the decapsulation function > of the encapsulated IPv6 packets and 6to4 packets over 6to4. Why is this limited to 6to4 tunnels? Any form of IPv6-in-IPv4 tunnel has this risk. There are other risks specific to tunnels, e.g. RFC 6324. There are also many other security issues with 6to4 (RFC 3964) and a number of guidelines about how to deploy it and how *not* to deploy it (RFC 6343). There are relevant documents that are listed in the references but are not mentioned in the text - surely the important points in them should be mentioned? At the moment, the document is an incomplete story, and a reader might be confused into thinking it covers everything there is to know. In general I was surprised how short this document is. For example,there is absolutely no discussion of scanning attacks, DoS, or of the very real problems that firewalls face in handling legitimate IPv6 extension headers at line speed. Serious efforts such as Fernando Gont's are hundreds of pages long. I'm no security expert, so again: it needs a serious review by somebody who is one. Regards Brian Carpenter On 08/06/2013 00:00, Scott Mansfield wrote: > > From: Scott Mansfield Sent: Friday, June 07, 2013 5:22 AM To: > 'saag@ietf.org' Subject: ITU-T Recommendation ITU-T X.1037, > Technical security guideline on deploying IPv6 > > https://datatracker.ietf.org/liaison/1255/ > > Further information on this document. X.1037 is in an ITU > approval process called AAP. The deadline for comments on > the document is 12 June 2013. There are a number of comments > on the document already submitted by an ITU sector member, > so the document will have to be reviewed and modified before > it can move forward. The next step in the process would be > something call additional review. In additional review, > comments are accepted only on the parts of the document that > were modified, no new substantive comments on the rest of the > document are accepted. So, if there are comments anyone > would like to make on the document, please send them to be > before 12 June. > > Regards, -scott. > > Scott Mansfield Ericsson Inc. +1 724 931 9316 > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ v6ops mailing > list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Fri Jun 7 22:39:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF5421F9A2A for ; Fri, 7 Jun 2013 22:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hop+Xv-zHK+H for ; Fri, 7 Jun 2013 22:39:55 -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 1E46021F9A29 for ; Fri, 7 Jun 2013 22:39:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 401968700E7; Sat, 8 Jun 2013 07:39:39 +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 K1Z7rfZV0Brw; Sat, 8 Jun 2013 07:39:39 +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 25D72870002; Sat, 8 Jun 2013 07:39:39 +0200 (CEST) Message-ID: <51B2C394.1080508@globis.net> Date: Sat, 08 Jun 2013 07:39:32 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Warren Kumari References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> In-Reply-To: <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 05:39:56 -0000 Warren Kumari wrote: > On Jun 7, 2013, at 7:59 PM, Nalini Elkins wrote: > >> On 6/7/2013 4:18 PM, Nalini Elkins wrote: >>>>> Well, HBH is the *correct* place to put things that are examined per-hop ;-) >>> Maybe I am missing something but I am not seeing why the header we are >>> proposing has to be looked at by ANY intermediate hop. The source node >>> sticks in the timestamp and packet sequence number & we are all set. >>> Why would that need to be in a HBH header? >>>> It wounldn't unless you need it to be examined by a router. If it's only examined by the endpoints, it could be elsewhere. >>>> The point of the HBH header is to place all of the info a router should *ever* need to look at (that isn't in the main IPv6 header) in one place that's easy to find and parse. >> Sure. That is why we put it in the Dest Ops header. No need for a router to ever bother with our little guy! > > Sure, but the Dest Ops header shows up before the L4 information, and so pushed the L4 header further out. Absolutely. > Someone (it may have been Ron Bonica, hopefully he doesn't mind me mentioning it) suggested reordering the header chain so that it goes IP -> HBH -> L4 / Payload -:> Dest Options. > This is not a stupid idea…. > > Anyway, I decided that maybe having some data here would be useful, so I decided to see how many sites from Dan Wing's list (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt) I could: > A: make an IPv6 connection to and > B: would accept packets where the first header was not the payload. > > So, here are some stats. I connect (using scapy) and do an HTTP GET. If that works, I try again, with an empty Destination Options (the only thing I could figure out that would move the payload up and not influence routing / seem weird). My methodology may be broken, and the code (pasted at the bottom *certainly* is horrendous, but at least we have *some* data. And kvetching about methodology, data is (IMO) more interesting than where are currently are, which seems to not be progressing… > > > [SNIP] Thanks for the data. But your test only pushed the L4 header out by one Destination Option header (8 bytes (2 + PadN of 6)) That to me would suggest far more brokenness than simply that the L4 header had moved a small amount beyond the limit of the 'n' first bytes of the packet (where 'n' is limited due to bandwidth limitations to the ASIC), because 8 bytes is the absolute minimum a L4 header can be displaced. Your test traffic would certainly not constitute an abnormally long extension header chain IMHO. e.g. It might be that there were problems with a broken parser not finding the L4 header at an exact fixed location where it expected it, a filter that had been configured, or some additional configuration to say drop all destination options. Speaking entirely selfishly: accelerating fragment headers, and AH+ESP through firewalls that examine L4 data would be the two use-cases I'd want to see most supported. Or is the IPv6 Internet "web only"? regards, RayH From joelja@bogus.com Sat Jun 8 01:24:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 02:32:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30E21F8B04 for ; Sat, 8 Jun 2013 02:32:06 -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.201, 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 E3XcdXH9Rxkn for ; Sat, 8 Jun 2013 02:32:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 119E121F8ADC for ; Sat, 8 Jun 2013 02:32:06 -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 r589Vwxu068389 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Jun 2013 09:32:02 GMT (envelope-from joelja@bogus.com) Message-ID: <51B2FA0F.8090803@bogus.com> Date: Sat, 08 Jun 2013 11:31:59 +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: Joe Touch , Brian E Carpenter References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <51B2231F.40203@isi.edu> <51B240BD.6080207@gmail.com> <51B245F1.2070901@isi.edu> <51B25CC7.4070700@isi.edu> In-Reply-To: <51B25CC7.4070700@isi.edu> 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:32:04 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 09:32:06 -0000 On 6/8/13 12:20 AM, Joe Touch wrote: > Hi, all, > > I realized that part of my response below was based on a message I > sent privately, but it needn't have been; here's the post: > > ----- > > I'm trying to get at the core of this issue. > > I don't quite understand why IP addresses are insufficient; the only > way that would be true is if: > > a) a host could send data at very high rates (possible, but > unlikely sustained) > > b) a block of hosts share a single address and send data > out at an aggregate high rate > > c) aggregated traffic is either NAT'd or tunneled > > In the case of (c), the NAT/tunnel ingress should be part of the > solution; it clearly is creating the problem, as I suggest below. > > In case (a), the network won't benefit from *any* host identity > solution; there's no point in solving that case. > > In case (b), I would argue that the problem is sharing the address in > the first place. That case should be solved by reconfiguration. > > Is there some other case? > > Or maybe, rather than "drop all packets that have extension headers", > a better solution is to "load balance where the IP information is > sufficient", and where it is not just drop traffic that exceeds the > need to balance? > > Joe > > On 6/7/2013 1:43 PM, Joe Touch wrote: >> Hi, Brian, >> >> On 6/7/2013 1:21 PM, Brian E Carpenter wrote: >>> Joe, >>> >>> On 08/06/2013 06:14, Joe Touch wrote: >>>> Hi, all, >>>> >>>> In the spirit of moving towards a solution, here's my understanding of >>>> the problems: >>>> >>>> 1. the need for load balancing >>>> >>>> - if packets had true E2E addresses, those addresses would be >>>> sufficient for load-balancing >>> >>> Absolutely not. Load balancing routinely looks at L4 headers. >> > >>> See RFC 6438, draft-ietf-intarea-flow-label-balancing, >>> draft-ietf-opsawg-large-flow-load-balancing. >> >> Both docs refer to cases I indicate in my later post: >> >>> I don't quite understand why IP addresses are insufficient; the only >>> way that would be true is if: >>> >>> a) a host could send data at very high rates (possible, but >>> unlikely sustained) >>> >>> b) a block of hosts share a single address and send data >>> out at an aggregate high rate This is the load balancer case yes... which is essentially a localized form of anycast, say for example 20 nexthop addresses for the same destination IP. each one of those a load balancer with a pool of hosts behind it. There is rather a lot of outgoing traffic with the same source ip on it. >>> >>> c) aggregated traffic is either NAT'd or tunneled >> >> The first doc focuses on case (b). IMO, that's a failure of the >> configuration of the block of hosts. >> >> The second doc indicates that there are several ways to differentiate >> flows, of which only the first - the 5-tuple - includes L4 information. >> >> The other post explained how I suggested handling each of these three >> cases, FWIW. >> >> Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From arturo.servin@gmail.com Sat Jun 8 07:23:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FA721F9A0D for ; Sat, 8 Jun 2013 07:23:45 -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_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 1j2r2cZTRYwT for ; Sat, 8 Jun 2013 07:23:44 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8599821F99A3 for ; Sat, 8 Jun 2013 07:23:34 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id z20so492178yhz.0 for ; Sat, 08 Jun 2013 07:23:34 -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=uXJ7munYnWeK6CuK5iVPlokH5NZWNzCGj92Tq1GmQ4I=; b=BaUgP8cy+wH4SKVHXj/v4EhnMXroLJLt2kRJSgzOVQU+9MunmULhf/9Cgmy7vC4nB8 a3ojmecIbqH/7P6e50gl/F3QeHqiZkyxkABb9cuH7QGuxtH5CmR7CU7gcAIbD1C4JVEC ifDNvzYst68CL008Stzln8r5EwHrLaWjNdUwQJt/c+TgI5cVYcbWvLFm18FEo+QY4rb/ 2ZGuoxaLLwT3JYZ/FR1J4mxB/ij31d4CqfGdYynrjpmCQC0cwhR0a7XZeFc6fYueSfK+ B5/yhvAhmVQ+9+bJgfH0XUqnkbmJYYLTK0Ltc04PAl9T1ocBUK5gEDW44BBUr4s1Lr/U Ln6w== X-Received: by 10.236.2.202 with SMTP id 50mr1243522yhf.126.1370701413811; Sat, 08 Jun 2013 07:23:33 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2800:af:ba30:d849:d1c:e03:6166:3826]) by mx.google.com with ESMTPSA id s29sm4690416yhf.6.2013.06.08.07.23.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Jun 2013 07:23:32 -0700 (PDT) Message-ID: <51B33E60.4050902@gmail.com> Date: Sat, 08 Jun 2013 11:23:28 -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: Nick Hilliard References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> <51B0D6A6.20908@isi.edu> <51B0E654.9000403@inex.ie> <51B0EE3B.4000807@isi.edu> <51B0F2DA.30300@inex.ie> In-Reply-To: <51B0F2DA.30300@inex.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 14:23:46 -0000 I agree we need to leave this debate about routers/firewalls and L3 and L4. But the worst thing that we can do now it is to leave the status quo (Extension Headers as they exists today) without even questioning if we need to change it. First, we need to ask ourselves if extension headers are worth at all and if they really make IPv6 a better protocol. Then if so, we need to try to find a compromise between performance/deployment (vendors) vs protocol design (ietf). A compromise may be a fixed maximum size on EH chains. If we found that EX are useless (or some of them) then we should deprecate them. my 20 cents. as On 6/6/13 5:36 PM, Nick Hilliard wrote: > On 06/06/2013 21:16, Joe Touch wrote: >> They're sold as routers, but they have two distinct functions: >> >> router functions >> firewall functions >> >> Routers don't *need* to do anything with L4 to be called a router. That's >> not how router vendors market them, agreed. > > Joe, they are routers. They need stateless packet filtering and various > other things which require packet header inspection to survive on the > internet, but that does not make them routers any the less. > > We can pick nits about this all day if you want, but a firewall is > generally accepted to be a device which performs stateful/inspected flow > forwarding, and a router is generally accepted to be a device which does > stateless packet forwarding (albeit with features which allow stateless > filtering). Now can we move on? > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nalini.elkins@insidethestack.com Sat Jun 8 08:53:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2C521F961B for ; Sat, 8 Jun 2013 08:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22q4zODtQkZM for ; Sat, 8 Jun 2013 08:53:38 -0700 (PDT) Received: from nm7.access.bullet.mail.sp2.yahoo.com (nm7.access.bullet.mail.sp2.yahoo.com [98.139.44.134]) by ietfa.amsl.com (Postfix) with ESMTP id ED7BF21F949D for ; Sat, 8 Jun 2013 08:53:37 -0700 (PDT) Received: from [98.139.44.100] by nm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jun 2013 15:53:37 -0000 Received: from [98.139.44.93] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 08 Jun 2013 15:53:37 -0000 Received: from [127.0.0.1] by omp1030.access.mail.sp2.yahoo.com with NNFMP; 08 Jun 2013 15:53:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 710397.72917.bm@omp1030.access.mail.sp2.yahoo.com Received: (qmail 54358 invoked by uid 60001); 8 Jun 2013 15:53:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370706816; bh=t3SkNllxGv6t8KzRNmPVG7sYqsj6tzPaTrKRo/TcOF0=; 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=6VBtKHPlyoY456IB6JCLf1kQN3XT4GK0mVWmoUP9ZNyPqo/YlB6SAsRhayOp60aNJEKH51YDvBvVlDgpHO8PUnvXATNUeDL30pVeMb8XeBkhpbHoYPWQt+CUqiGBZqRz224dHExWH/FrKFTHu9891zXWQLvvYoeIu8sSZBxfSlI= X-YMail-OSG: jqZoOJwVM1k38FouiEbc01zAC9lCo5AaRTw8PaBWPGPInLn 5.u.xHi0VrZBiSn8V7UbS7_rxklufqLmybtziUQvsnYAwKqm5DEs0k7iJ7wK OyWPbVWrwUMsgh.SQ5sBehaaaENfsgx4XkO7GYw7ZXTVLk8LOMRiK8zXvjRq zN1b9cEBfi51ctLKBtJruVqQ8I8_QBnSOC6xEcEcrbvNqjx9dmoDvMDtuLdk 4d21S4hsy1k3czVHR1Nc5fUwoByM6NL1MjPbXFSL8hILYSLIjbomSp60DkCU MZOQXnwWdNzE7sw0TmjKV8yj.OU13DcOg95MHqiOT0jGeqB7VCPJq5jbSUlK EAbvi81qmfaCXwkCe7QOty5jWgRPyMVx5gs21a17YEtDXXTHtq3ihCYzKt1g VflD4w64jgugAoSZ2K_WZwayTZtIqeZhpjabbSW9lzUJrQ.ThvjXm4PfUDf1 LDp2Pky8joLP.hXHc_XVnnC31KE0QcqG1RfVm4uPy0hcPO85fWMn23ZPvtuK t2nne4hux8KMuU7EgOHSi_1s_VswXlhTbqi7xu_XE6aNT_uDzhsQeoQdu4xJ tHdvycbsxKEffsOpnOaBwq_Fkigl3jcaewChvOL4u9_DJQ8O81MIs6Im6FGT vEgib2mFcKfXL_BXiLBf3zIxCCAR2DJVPRaweHoQHfFz4vW8TptgWOFCSlMF EdbnvtmR8rP8o1lMcV0sV Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Sat, 08 Jun 2013 08:53:36 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgoKV2FycmVuIEt1bWFyaSB3cm90ZToKPiBPbiBKdW4gNywgMjAxMywgYXQgNzo1OSBQTSwgTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20.IHdyb3RlOgo.Cj4.IE9uIDYvNy8yMDEzIDQ6MTggUE0sIE5hbGluaSBFbGtpbnMgd3JvdGU6Cgo.IEFueXdheSwgSSBkZWNpZGVkIHRoYXQgbWF5YmUgaGF2aW5nIHNvbWUgZGF0YSBoZXJlIHdvdWxkIGJlIHVzZWZ1bCwgc28gSSBkZWNpZGVkIHRvIHNlZSBob3cgbWFueSBzaXRlcyBmcm9tIERhbiBXaW5nJ3MgbGlzdCAoaHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> Message-ID: <1370706816.52882.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Sat, 8 Jun 2013 08:53:36 -0700 (PDT) From: Nalini Elkins To: Ray Hunter , Warren Kumari In-Reply-To: <51B2C394.1080508@globis.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-723695597-1370706816=:52882" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 15:53:44 -0000 --36908767-723695597-1370706816=:52882 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A=0AWarren Kumari wrote:=0A> On Jun 7, 2013, at 7:59 PM, Nali= ni Elkins wrote:=0A>=0A>> On 6/7/2013 4:= 18 PM, Nalini Elkins wrote:=0A=0A> Anyway, I decided that maybe having some= data here would be useful, so I decided to see how many sites from Dan Win= g's list (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0= 800.txt) I could:=0A=0A> A: make an IPv6 connection to and=C2=A0=0A> B: wou= ld accept packets where the first header was not the payload.=0A>=0A> So, h= ere are some stats. I connect (using scapy) and do an HTTP GET. If that wor= ks, I try again, with an empty Destination Options (the only thing I could = figure out that would move the payload up and not influence routing / seem = weird). My methodology may be broken, and the code (pasted at the bottom *c= ertainly* is horrendous, but at least we have *some* data. And kvetching ab= out methodology, data is (IMO) more interesting than where are currently ar= e, which seems to not be progressing=E2=80=A6=C2=A0=0A>=0A=0A>Thanks for th= e data.=0A=0A>But your test only pushed the L4 header out by one Destinatio= n Option header (8 bytes (2 + PadN of 6))=0A=0A>That to me would suggest fa= r more brokenness than simply that the L4=0A>header had moved a small amoun= t beyond the limit of the 'n' first bytes=0A>of the packet (where 'n' is li= mited due to bandwidth limitations to the=0A>ASIC), because 8 bytes is the = absolute minimum a L4 header can be=0A>displaced. Your test traffic would c= ertainly not constitute an=0A>abnormally long extension header chain IMHO. = e.g. It might be that there=0A>were problems with a broken parser not findi= ng the L4 header at an exact=0A>fixed location where it expected it, a filt= er that had been configured,=0A>or some additional configuration to say dro= p all destination options.=0A=0A>Speaking entirely selfishly: accelerating = fragment headers, and AH+ESP=0A>through firewalls that examine L4 data woul= d be the two use-cases I'd=0A>want to see most supported.=0A=0A>Or is the I= Pv6 Internet "web only"?=0A=0A=0AVery interesting point.=0A=0ALet me stress= that I have talked to real organizations on the IPv6 internet and some are= blocking IPv6 extension headers on their Internet facing sides. =C2=A0 But= not on the internal facing network. =C2=A0 Their concern is security. =C2= =A0So, what I think has happened here is NOT that Warren's code pushed the = L4 header out but that the mere existence of a dest ops header was enough t= o cause the firewall to drop the packet. =C2=A0=C2=A0=0A=0AJust saying beca= use I know one of the organizations that Warren tested against. =C2=A0Now, = I only asked 3 organizations and did not do some kind of systematic study.= =0A=0ANalini --36908767-723695597-1370706816=:52882 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable





    Warren Ku= mari wrote:
    > On Jun 7, 2013, at 7:59 PM, Nalini Elkins <nalini.elkins@insidethestack.com> w= rote:
    >
    >> On 6/7/2013 4:18 PM, Nalini Elkins wrote:
    &= gt; Anyway, I decided that maybe having some data here would be useful, so = I decided to see how many sites from Dan Wing's list (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt)= I could:
    > A: make an IPv6 conne= ction to and 
    > B: would accept packets where the first header w= as not the payload.
    >
    > So, here are some stats. I connect (using sc= apy) and do an HTTP GET. If that works, I try again, with an empty Destinat= ion Options (the only thing I could figure out that would move the payload = up and not influence routing / seem weird). My methodology may be broken, a= nd the code (pasted at the bottom *certainly* is horrendous, but at least w= e have *some* data. And kvetching about methodology, data is (IMO) more int= eresting than where are currently are, which seems to not be progressing=E2= =80=A6 
    >
    =
    >Than= ks for the data.

    = >But your test only pushed the L4 header out by one Destination Option h= eader (8 bytes (2 + PadN of 6))
    <= br style=3D"color: rgb(69, 69, 69); font-family: 'Helvetica Neue', Helvetic= a, Arial, sans-serif; font-size: 12px;">>That to me would suggest far more brokenness than simply that t= he L4
    >header had moved a small amount beyond the limit o= f the 'n' first bytes
    >of the packet (where 'n' is limited due = to bandwidth limitations to the
    >ASIC), because 8 bytes i= s the absolute minimum a L4 header can be
    >displaced. You= r test traffic would certainly not constitute an
    >abnorma= lly long extension header chain IMHO. e.g. It might be that there
    >were problems with a broken parser not finding the L4 header at an e= xact
    >fixed location where it expected it, a filter that = had been configured,
    >or some additional configuration to= say drop all destination options.

    >Speaking entirely selfishly: accelerating fragment headers,= and AH+ESP
    >through firewalls that examine L4 data would= be the two use-cases I'd
    >want to see most supported.


    = Very interesting point.=
    Let me stress that I have talked to real organizations on the= IPv6 internet and some are blocking IPv6 extension headers on their Intern= et facing sides.   But not on the internal facing network.   Thei= r concern is security.  So, what I think has happened here is NOT that = Warren's code pushed the L4 header out but that the mere existence of a des= t ops header was enough to cause the firewall to drop the packet.  &nb= sp;

    Just saying because I know one of the organ= izations that Warren tested against.  Now, I only asked 3 organization= s and did not do some kind of systematic study.

    Nalini
     


    <= /div> --36908767-723695597-1370706816=:52882-- From nalini.elkins@insidethestack.com Sat Jun 8 08:55:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A43A21F9976 for ; Sat, 8 Jun 2013 08:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.432, 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 Yb0apuoTVLdW for ; Sat, 8 Jun 2013 08:54:53 -0700 (PDT) Received: from nm15.access.bullet.mail.mud.yahoo.com (nm15.access.bullet.mail.mud.yahoo.com [66.94.237.216]) by ietfa.amsl.com (Postfix) with ESMTP id 71F3521F9965 for ; Sat, 8 Jun 2013 08:54:53 -0700 (PDT) Received: from [66.94.237.192] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 08 Jun 2013 15:54:45 -0000 Received: from [66.94.237.100] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 08 Jun 2013 15:54:45 -0000 Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 08 Jun 2013 15:54:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 375494.98445.bm@omp1005.access.mail.mud.yahoo.com Received: (qmail 38402 invoked by uid 60001); 8 Jun 2013 15:54:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370706884; bh=tiPl+XRbVY40GCtmyjBkGMUfDthipfOmhuBsPdsO9EE=; 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=vPxIjagmfv+iUW10e31dqep2JH3E2ImSRF9Sw4c5IMawb8WP4grPTCytWYvGNxXkJGatKgzJcmi5BFAEvi8qPxL3AOp1lvK3M7CrdxlWunoryEotA+OdclmeJ2rnWA4IrOA3iOhtAP/7mb7995LRxTGLiaskHn2xinanNrj+EZ8= X-YMail-OSG: 9RdfEFMVM1lFsinfHQgikK6O.uhjYZzXbUJ9MrG.H2htRbN sJzlVYkEm4uO8uOoz51ilMdJFKhjhnF7XTPmKVH4tnMP5tTv_LJCJlQHIKy4 9yBzHZ0KOnLXH6T_OzHGmmX6ON75fQrgFGPSBfjWu_fh47wvA6g4ueDB2oDX PsiBUAg4tRO6qnialS7sy0DR0hIR87JBeV05oynNHdNW0KRpo0bWpThdJFzJ RQW4dwUvOZBFeQqpWbjfkgvDR0U5miiy7hhuP2U7QnzRVMx5HZqNcSVInP5D XOzXg2XKcZbn5kuZKmCX2kBk7.7tPvVihwOWmNRaWLjArYOagUvr79QFYFZy gcJcHTZVDIlEoH5BtExDaGn4hlaGyNlZ3a.e5qjYP9NlFLekR5eu5mC1DQe_ TawCLKgXRoNsY34IPOTrxZNeVTeS5WOAPyNLvB1snIUH5zeXklaNZ3X5BRhG ElcO8LaGgvYrrzxTV6z939kmKkjSP4PlPMGCk83NpxRkHXRRhA6IGvZLUIz8 nirtJSnKgxFWXnWivJZh2lVt.Ft1no_y_jIUuKVPqt_dxEKVpcUxoByAN Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Sat, 08 Jun 2013 08:54:44 PDT X-Rocket-MIMEInfo: 002.001, Cgo.PiDCoCDCoEkgYWdyZWUgd2UgbmVlZCB0byBsZWF2ZSB0aGlzIGRlYmF0ZSBhYm91dCByb3V0ZXJzL2ZpcmV3YWxscyBhbmQgTDMgYW5kIEw0LgoKwqAgPj4gwqBCdXQgdGhlIHdvcnN0IHRoaW5nIHRoYXQgd2UgY2FuIGRvIG5vdyBpdCBpcyB0byBsZWF2ZSB0aGUgc3RhdHVzIHF1bwo.PihFeHRlbnNpb24gSGVhZGVycyBhcyB0aGV5IGV4aXN0cyB0b2RheSkgd2l0aG91dCBldmVuIHF1ZXN0aW9uaW5nIGlmIHdlCj4.bmVlZCB0byBjaGFuZ2UgaXQuCgrCoCA.PiDCoEZpcnN0LCB3ZSBuZWVkIHRvIGFzayABMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> <51B0D6A6.20908@isi.edu> <51B0E654.9000403@inex.ie> <51B0EE3B.4000807@isi.edu> <51B0F2DA.30300@inex.ie> <51B33E60.4050902@ gmail.com> Message-ID: <1370706884.38210.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Sat, 8 Jun 2013 08:54:44 -0700 (PDT) From: Nalini Elkins To: Arturo Servin , Nick Hilliard In-Reply-To: <51B33E60.4050902@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1373589059-1370706884=:38210" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 15:55:00 -0000 --1510626085-1373589059-1370706884=:38210 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A>> =A0 =A0I agree we need to leave this debate about routers/firewall= s and L3 and L4.=0A=0A=A0 >> =A0But the worst thing that we can do now it i= s to leave the status quo=0A>>(Extension Headers as they exists today) with= out even questioning if we=0A>>need to change it.=0A=0A=A0 >> =A0First, we = need to ask ourselves if extension headers are worth at all=0A>>and if they= really make IPv6 a better protocol. Then if so, we need to=0A>>try to find= a compromise between performance/deployment (vendors) vs=0A>>protocol desi= gn (ietf). A compromise may be a fixed maximum size on EH=0A>>chains.=0A=0A= =A0>> =A0If we found that EX are useless (or some of them) then we should= =0A>>deprecate them.=0A=A0=0AArturo, very sensible statement.=0A=0ANalini --1510626085-1373589059-1370706884=:38210 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

    >>    I agree we need t= o leave this debate about routers/firewalls and L3 and L4.

      &g= t;>  But the worst thing that we can do now it is to leave the stat= us quo
    >>(Extension Headers as they exists today) without even que= stioning if we
    >>need to change it.

      >>  F= irst, we need to ask ourselves if extension headers are worth at all
    >= ;>and if they really make IPv6 a better protocol. Then if so, we need to=
    >>try to find a compromise between performance/deployment (vendor= s) vs
    >>protocol design (ietf). A compromise may be a fixed maximu= m size on EH
    >>chains.

     >>  If we found that= EX are useless (or some of them) then we should
    >>deprecate them.=
     
    Arturo, very sensible statem= ent.

    Nalini
    --1510626085-1373589059-1370706884=:38210-- From warren@kumari.net Sat Jun 8 09:28:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB35921F92F5 for ; Sat, 8 Jun 2013 09:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.489 X-Spam-Level: X-Spam-Status: No, score=-101.489 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, J_CHICKENPOX_23=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 1fjFbSbP1er7 for ; Sat, 8 Jun 2013 09:28:40 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577EC21F92EC for ; Sat, 8 Jun 2013 09:28:40 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id D8AE11B4119F; Sat, 8 Jun 2013 12:28:38 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <51B2C394.1080508@globis.net> Date: Sat, 8 Jun 2013 12:28:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 16:28:44 -0000 On Jun 8, 2013, at 1:39 AM, Ray Hunter wrote: >=20 >=20 > Warren Kumari wrote: >> On Jun 7, 2013, at 7:59 PM, Nalini Elkins = wrote: >>=20 >>> On 6/7/2013 4:18 PM, Nalini Elkins wrote: >>>>>> Well, HBH is the *correct* place to put things that are examined = per-hop ;-) >>>> Maybe I am missing something but I am not seeing why the header we = are >>>> proposing has to be looked at by ANY intermediate hop. The source = node >>>> sticks in the timestamp and packet sequence number & we are all = set. >>>> Why would that need to be in a HBH header? >>>>> It wounldn't unless you need it to be examined by a router. If = it's only examined by the endpoints, it could be elsewhere. >>>>> The point of the HBH header is to place all of the info a router = should *ever* need to look at (that isn't in the main IPv6 header) in = one place that's easy to find and parse. >>> Sure. That is why we put it in the Dest Ops header. No need for a = router to ever bother with our little guy! >>=20 >> Sure, but the Dest Ops header shows up before the L4 information, and = so pushed the L4 header further out. > Absolutely. >=20 >> Someone (it may have been Ron Bonica, hopefully he doesn't mind me = mentioning it) suggested reordering the header chain so that it goes IP = -> HBH -> L4 / Payload -:> Dest Options. >> This is not a stupid idea=85. >>=20 >> Anyway, I decided that maybe having some data here would be useful, = so I decided to see how many sites from Dan Wing's list = (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt)= I could: >> A: make an IPv6 connection to and=20 >> B: would accept packets where the first header was not the payload. >>=20 >> So, here are some stats. I connect (using scapy) and do an HTTP GET. = If that works, I try again, with an empty Destination Options (the only = thing I could figure out that would move the payload up and not = influence routing / seem weird). My methodology may be broken, and the = code (pasted at the bottom *certainly* is horrendous, but at least we = have *some* data. And kvetching about methodology, data is (IMO) more = interesting than where are currently are, which seems to not be = progressing=85=20 >>=20 >>=20 >> [SNIP] > >=20 > Thanks for the data. >=20 > But your test only pushed the L4 header out by one Destination Option = header (8 bytes (2 + PadN of 6)) Yup. I mentioned that in my mail I am planning on retesting the sites that managed to pass *any* headers = by adding more padding and seeing where various sites fall out. Unfortunately scapy doesn't really like my adding the padding myself = (or, at least I haven't yet figured out yet how). I'll try beat it into = submission more, or just give up and hand-craft the packets myself.=20 >=20 > That to me would suggest far more brokenness than simply that the L4 > header had moved a small amount beyond the limit of the 'n' first = bytes > of the packet (where 'n' is limited due to bandwidth limitations to = the > ASIC), because 8 bytes is the absolute minimum a L4 header can be > displaced. Your test traffic would certainly not constitute an > abnormally long extension header chain IMHO. e.g. It might be that = there > were problems with a broken parser not finding the L4 header at an = exact > fixed location where it expected it, a filter that had been = configured, > or some additional configuration to say drop all destination options. Yup, the *huge* majority of the "brokenness" was probably filters like = the below - if you don't apply any filters / hashing / load-balancing = the router is only looking at the IP header. term discard-ext-header-packets { from { next-header-except [ tcp udp icmpv6 ]; } then { count discarded-packets-with-headers; discard; } } } But, as we say in: = http://tools.ietf.org/html/draft-wkumari-long-headers-00 "In one widely deployed router architecture, if there are any extension headers between the IPv6 header and the upper-layer header, the forwarding logic never sees the upper-layer header, and so is not able to filter on it." and=20 "Network operators may filter traffic with extention header, because of the lack of fixed extention header size, the complexity of following header chains, and the inability of deployed routers to look sufficently deep into packets to see the upper-layer header." But, as a [ web / content ] operator, why would you allow in any traffic = that seems suspicious?=20 We have an updated version of this draft sitting in an edit buffer (and = a corresponding recommendation draft), which we intend to submit in a = few days (as soon as we figure out who has the most recent revision, why = they didn't check it into svn, and who exactly was supposed to post it=85 = :-P)=20 > Speaking entirely selfishly: accelerating fragment headers, and AH+ESP > through firewalls that examine L4 data would be the two use-cases I'd > want to see most supported. So, yes, there *are* extensions that are useful -- ESP, AH / Mobility = spring to mind. One of the updates to the draft suggests that devices be designed to be = able to look N bytes into the packet to find the L4 info (where N is 64 = / 128 / 256). This seems like a good compromise between extensibility = and cost. Most *sites* on the Internet will continue to only allow = traffic in that they are expecting though. As it is "hard" for machines / applications to know if they are emitting = a packet that will traverse the big-I Internet they should assume that = there will be a filter that will barf on EH headers and so not emit = them. "For this reason, appplications and IPv6 stacks should avoid the use of extention headers whenever possaible, and applications should be designed to deal with the posibility that packets containing extention headers may not be delivered." What flavor of kink you get up to in the privacy of your own network is = (largely) your own decision, but keep in mind that: 1: hardware is designed for the majority / profitable cases. 2: adding complexity to the protocol has a cost to all (bugs per kloc, = limited developer resources, edge cases and operational considerations, = endless threads on v6ops@ ). >=20 > Or is the IPv6 Internet "web only"? >=20 Nope. No-one said that, but sometimes it does seem that way, doesn't it? = :-).=20 W > regards, > RayH >=20 --=20 With Feudalism, it's your Count that votes. From prvs=6870ecd210=scott.mansfield@ericsson.com Fri Jun 7 07:25:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3243F21F9843 for ; Fri, 7 Jun 2013 07:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 TQ7R9QgdktVS for ; Fri, 7 Jun 2013 07:25:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAEB21F9619 for ; Fri, 7 Jun 2013 07:25:36 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-70-51b1ed5ff48f Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BE.1E.05617.F5DE1B15; Fri, 7 Jun 2013 16:25:36 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 10:25:35 -0400 From: Scott Mansfield To: Fernando Gont Thread-Topic: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: Ac5jYIPck0d+2CUNT3Sp/Yo0Bb4r3gAFgdfAAA0IUoAAB/2Q4A== Date: Fri, 7 Jun 2013 14:25:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E245586411523C88eusaamb102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPlG7C242BBtOb+SyerHrDZnH62F5m ByaPJUt+Mnl8ONTDHsAUxW2TlFhSFpyZnqdvl8Cdce2GYsHNsIrOS0tZGhgb/boYOTgkBEwk njUVdTFyApliEhfurWfrYuTiEBI4yiix6MMqZghnGaPE4VtrmUCq2IAatu6azghiiwhoSsx9 foQJZBCzgKrE7D/8IGFhgRyJ9s9HGEHCIgK5Ep8v10JUO0ncefUNbAqLgIrEhVuHmEFKeAV8 Je5OdITYNAVo04V9LCA1nAKBEt82/gCzGYFu+35qDVgvs4C4xK0n85kgbhaQWLLnPDOELSrx 8vE/VghbWWLJk/0sEPX5EtcbFoPFeQUEJU7OfMIygVF0FpJRs5CUzUJSBhHXkViw+xMbhK0t sWzha2YY+8yBx0zI4gsY2VcxcpQWp5blphsZbmIERtQxCTbHHYwLPlkeYpTmYFES59XhXRwo JJCeWJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MDIWnlfe7Hv70DnrHKnrK/tmzZsVmmmjoLrP +thk/ZyZU2V2C+1ub72UVRfByHy9S8lT4bAr+2VVAcULboy5O3KE7se8nGJ3sPt2Z794QmfV IjcBza66I2yd5/K7MrJu+reevsFpy9gw2/He0T4GTn+1iGeKwoERa0Pk7wj/0eoW4f5ZOumM EktxRqKhFnNRcSIAYETf7XsCAAA= X-Mailman-Approved-At: Sat, 08 Jun 2013 09:39:29 -0700 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:25:43 -0000 --_000_EF35EE4B92789843B1DECBC0E245586411523C88eusaamb102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the link to the document https://datatracker.ietf.org/documents/LIAISON/liaison-2013-05-07-itu-t-sg-= 17-sec-lso-on-the-itu-t-recommendation-itu-t-x1037-technical-security-guide= line-on-deploying-ipv6-to-ietf-security-are-attachment-1.pdf regards, -scott. From: fgont.si6networks.nexus@gmail.com [mailto:fgont.si6networks.nexus@gma= il.com] On Behalf Of Fernando Gont Sent: Friday, June 07, 2013 10:13 AM To: Scott Mansfield Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical secur= ity guideline on deploying IPv6 Can anyone provide the url for the actual document? Thanks! Fernando On Jun 7, 2013 2:14 PM, "Scott Mansfield" > wrote: From: Scott Mansfield Sent: Friday, June 07, 2013 5:22 AM To: 'saag@ietf.org' Subject: ITU-T Recommendation ITU-T X.1037, Technical security guideline on= deploying IPv6 https://datatracker.ietf.org/liaison/1255/ Further information on this document. X.1037 is in an ITU approval process= called AAP. The deadline for comments on the document is 12 June 2013. T= here are a number of comments on the document already submitted by an ITU s= ector member, so the document will have to be reviewed and modified before = it can move forward. The next step in the process would be something call = additional review. In additional review, comments are accepted only on the= parts of the document that were modified, no new substantive comments on t= he rest of the document are accepted. So, if there are comments anyone wou= ld like to make on the document, please send them to be before 12 June. Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_EF35EE4B92789843B1DECBC0E245586411523C88eusaamb102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     <= /p>

    Here is the link to the d= ocument

    https://datatracker.ietf.or= g/documents/LIAISON/liaison-2013-05-07-itu-t-sg-17-sec-lso-on-the-itu-t-rec= ommendation-itu-t-x1037-technical-security-guideline-on-deploying-ipv6-to-i= etf-security-are-attachment-1.pdf

     <= /p>

    regards,

    -scott.=

     <= /p>

     <= /p>

     <= /p>

    From: fgont.si= 6networks.nexus@gmail.com [mailto:fgont.si6networks.nexus@gmail.com] On Behalf Of Fernando Gont
    Sent: Friday, June 07, 2013 10:13 AM
    To: Scott Mansfield
    Cc: v6ops@ietf.org
    Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technica= l security guideline on deploying IPv6

     

    Can anyone provide the url for the actual document?

    Thanks!
    Fernando

    On Jun 7, 2013 2:14 PM, "Scott Mansfield" = <scott.mansfield@ericsso= n.com> wrote:

     

     

    From: Scott Mansfield
    Sent: Friday, June 07, 2013 5:22 AM
    To: 'saag@ietf.or= g'
    Subject: ITU-T Recommendation ITU-T X.1037, Technical security guide= line on deploying IPv6

     

    https://datatracker.ietf.org/liaison/1255/

     

    Further information on this document.  X.1037 is in an ITU ap= proval process called AAP.  The deadline for comments on the document = is 12 June 2013.  There are a number of comments on the document already submitted by an ITU sector member, so the document= will have to be reviewed and modified before it can move forward.  Th= e next step in the process would be something call additional review. = In additional review, comments are accepted only on the parts of the document that were modified, no new substantive c= omments on the rest of the document are accepted.  So, if there are co= mments anyone would like to make on the document, please send them to be be= fore 12 June.

     

    Regards,

    -scott.

     

    Scott Mansfield

    Ericsson Inc.

    +1 7= 24 931 9316

     


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

    --_000_EF35EE4B92789843B1DECBC0E245586411523C88eusaamb102erics_-- From kristian.poscic@alcatel-lucent.com Fri Jun 7 10:49:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48121F9968; Fri, 7 Jun 2013 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu0p-srhJXoZ; Fri, 7 Jun 2013 10:49:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58821F9962; Fri, 7 Jun 2013 10:49:38 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r57HgGSw022575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Jun 2013 12:49:36 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r57G6Di4004375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 12:06:15 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 7 Jun 2013 12:06:13 -0400 From: "Poscic, Kristian (Kristian)" To: John Mann , "Rajiv Asati (rajiva)" Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOY5e9UtUF75OTtk6+SrU9uyYH2JkqaW8w Date: Fri, 7 Jun 2013 16:06:13 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AB410F8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Mailman-Approved-At: Sat, 08 Jun 2013 09:39:29 -0700 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:49:44 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But why is this a problem in CGN? You initially allocate a port block of 500ports to the subscriber and then = they can dynamically extend this on as needed basis (allocate a new port bl= ock). To me the value of this exercise is to determine what will this initial por= t block size be, not at which point the service will be denied since this c= an be easily extended. For RGs, it is what it is, if they have the limit of 500mapping, then yes, = this is the problem. But for CGN it shouldn't be. From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= John Mann Sent: Thursday, June 06, 2013 5:02 PM To: Rajiv Asati (rajiva) Cc: Softwires-wg list (softwires@ietf.org); v6ops@ietf.org; behave@ietf.org= ; Dan Wing (dwing) Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) > wrote: Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times I think a more-interesting statistic would be "how many connection setups w= ould have failed". But I don't think you can measure that just by polling concurrent connectio= ns at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" wo= uld be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then repo= rt that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@i= etf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. > > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. > > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. > > -d > > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    But why is this a problem= in CGN?

    You initially allocate a = port block of 500ports to the subscriber and then they can dynamically exte= nd this on as needed basis (allocate a new port block).

     <= /p>

    To me the value of this e= xercise is to determine what will this initial port block size be, not at w= hich point the service will be denied since this can be easily extended.

     <= /p>

    For RGs, it is what it is= , if they have the limit of 500mapping, then yes, this is the problem.=

    But for CGN it shouldn= 217;t be.

     <= /p>

    From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of John Mann
    Sent: Thursday, June 06, 2013 5:02 PM
    To: Rajiv Asati (rajiva)
    Cc: Softwires-wg list (softwires@ietf.org); v6ops@ietf.org; behave@i= etf.org; Dan Wing (dwing)
    Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports?

     

    Hi,

     

    On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> w= rote:

    Hi Dan,


    > and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
    > limit would interfere with your network use on those days.<= /p>

    I based that statement ("...seems ok,") on= the very fact that the number of times the NAT utilization exceeded 500 ma= ppings (equating to 500 ports, in my setup) in the sample period (~2 months= ) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok f= or 99% of the time and degraded 1% of the time. This is an important consid= eration, IMO.

    For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

    June 3 - 1 time
    May 29 - 1 time
    May 28 - 3 times
    May 26 - 1 time
    May 23 - 1 time
    May 22 - 2 times
    May 21 - 3 times

     

    I think a more-interesting statistic would be "= how many connection setups would have failed".

    But I don't think you can measure that just by polli= ng concurrent connections at specific times.

    It might take e.g. netflow exporting and analysis ..= .

     

    However "number of concurrent connections that = couldn't have been setup" would be useful in gauging the imp= act

    e.g. on May 29 there was one spike of 734 concurrent= connections, then report that as 234 potential failures.

     

    Of course, 1000 ports (resulting in 1000+ mappin= gs) would have been more than enough to accommodate the times when the mapp= ings exceeded 500, but stayed within 1000 (except once).



    > What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.<= /p>

     

    Is that a combined limit of TCP and UDP and ICMP, or= independent?

     

    My NAPT device seemingly can use upto 64K ports. :)<= br>
    Cheers,
    Rajiv



    > -----Original Message-----
    > From: Dan Wing (dwing)
    > Sent: Thursday, June 06, 2013 11:43 AM
    > To: Rajiv Asati (rajiva)

    > Cc: v6ops@iet= f.org; Softwires-wg list (softwir= es@ietf.org);
    > behave@ietf.org; Erik Kline (ek@google.com)
    > Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
    >
    >

    > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva= ) <rajiva@cisco.com> wrote: >
    > > Some of you may recall our discussion (during the last IETF) arou= nd "how
    > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
    > A+P paradigm. ~500, ~1000, ~3000???
    > >
    > > Well, I started monitoring my home router and plotting the NAPT44= port
    > utilization on a minute-by-minute basis. You may find it here -
    > http://= www.employees.org/~rajiva
    > >
    > > In short, port range of 500 seems ok, though 1000 would be more t= han
    > enough for my home.
    >
    > I see several spikes in your data over 500 ports.  During those t= imes,
    > applications would be unable to function (unable to get a port).  = ;April 29/30
    > is a long time where that occurs very visibly, but there are shorter s= pikes
    > elsewhere such as on April 17 and April 18.  If you had only 500 = ports on
    > those days, creating a new TCP mapping would have been impossible,
    > impacting ability to send or receive email, order books from Amazon.co= m,
    > and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
    > limit would interfere with your network use on those days.
    >
    > What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
    >
    > -d
    >
    > > Suffice to say, this is just a sample representation, since the p= ort
    > utilization would vary home to home, based on number of active devices= ,
    > type of applications, the degree of simultaneous device or application=
    > usage etc.
    > >
    > > If any of you are doing similar monitoring, then please share. > >
    > > Cheers,
    > > Rajiv
    > >
    > > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
    > google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
    > helping me out significantly.
    > >
    > > PS: My home has 3-4 active devices.
    > > _______________________________________________
    > > Behave mailing list
    > > Behave@ietf.org
    > > https://www.ietf.org/mailman/listinfo/behave

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

     

    --_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_-- From brian.e.carpenter@gmail.com Sat Jun 8 12:59:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F5D21F962B for ; Sat, 8 Jun 2013 12:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96oeBA+7qkFc for ; Sat, 8 Jun 2013 12:59:27 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id BE16921F901F for ; Sat, 8 Jun 2013 12:59:27 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so1083039pab.27 for ; Sat, 08 Jun 2013 12:59: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=57+a4Tls1UDDYPXbhqr7E9d89ZCsXm+vjYpfaXefzcQ=; b=zC1xT+Jg6O9Ad0AV7ELkmFf3fhQdUTNjP+qc6bbYitwspTtWwWAO6EqSJ++HM20Viv 4g+2AAPsnymaxnOF4PqRY2TZp2yfNMvj1GR9JcEbLn7CYj3U6XANRmuLIsIHEh61Nwgz YiSIhD8xLt+ZbTCgmqZ7p/DTQ7QvDSNEdWLTiRzE+AvKcVKQ73E8rQTTZhXTVoETPmX6 LEasr53uFhS8XNjVv8nDMuV3Y0DM0d7yz5xCaGxFYtr9x3NeRU9a/WgxcNBo6qSwuMo6 y+bWl2cOM8WYhokMm7DW8LUgWcYKsAqjOEkNJhAtGg4ys+L8F/BLF4ySNdvWDQTtYWjs wGrg== X-Received: by 10.66.139.198 with SMTP id ra6mr7982691pab.140.1370721567521; Sat, 08 Jun 2013 12:59: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 kv2sm4025988pbc.28.2013.06.08.12.59.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Jun 2013 12:59:26 -0700 (PDT) Message-ID: <51B38D16.7080509@gmail.com> Date: Sun, 09 Jun 2013 07:59:18 +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 References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> In-Reply-To: <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "v6ops@ietf.org" Subject: [v6ops] draft-wkumari-long-headers [was: new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 19:59:28 -0000 > One of the updates to the draft suggests that devices be > designed to be able to look N bytes into the packet to find > the L4 info (where N is 64 / 128 / 256). If you mean "look" in the sense of draft-ietf-6man-ext-transmit, it is very reasonable to say that in the real world, line speed devices can only do so for a finite number of bytes, and we could do some analysis to decide what is a reasonable number of bytes to avoid problems most of the time. In fact, I would personally see this as a good thing to add to the 6man draft, which at the moment leaves it open-ended. So, what is the longest reasonable header chain using any reasonable combination of the extensions defined to date? > This seems like a > good compromise between extensibility and cost. Agreed. > Most > *sites* on the Internet will continue to only allow traffic > in that they are expecting though. That's exactly why all the rules need to be configurable, as required by the 6man draft, so that sites can decide for themselves. Regards Brian From touch@isi.edu Sat Jun 8 14:53:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F024F21F9452 for ; Sat, 8 Jun 2013 14:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y50cmpjFZfCV for ; Sat, 8 Jun 2013 14:53:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1D80B21F91A5 for ; Sat, 8 Jun 2013 14:53:26 -0700 (PDT) Received: from [192.168.1.92] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r58Lqkf1015177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Jun 2013 14:52:56 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <51B33E60.4050902@gmail.com> Date: Sat, 8 Jun 2013 14:52:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4AEFCDE1-A000-4C93-BBBD-4467DBB4B2F1@isi.edu> References: <1370272888.80189.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> <1370443215.59608.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51AF5A52.8010100@inex.ie> <51AF6DDF.2060307@innovationslab.net> <1370458686.46843.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51AF8CD5.8080802@innovationslab.net> <51AF94D9.2020300@bogus.com> <51AF9BA8.2030201@gmail.com> <160522DD-5254-488D-AE87-0B0E24C535FB@kumari.net> <51AFA312.50500@gmail.com> <353237CF-2911-479E-A8A2-3EDC01EED5AB@kumari.net> <124C167D-3341-484E-B1BF-1EEC0C8369DB@employees.org> <51B06B9D.7060300@in! ex.ie> <51B0D6A6.20908@isi.edu> <51B0E654.9000403@inex.ie> <51B0EE3B.4000807@isi.edu> <51B0F2DA.30300@inex.ie> <51B33E60.4050902! @gmail.com> To: Arturo Servin X-Mailer: Apple Mail (2.1508) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 21:53:32 -0000 On Jun 8, 2013, at 7:23 AM, Arturo Servin = wrote: >=20 > I agree we need to leave this debate about routers/firewalls and = L3 and L4. >=20 > But the worst thing that we can do now it is to leave the status = quo > (Extension Headers as they exists today) without even questioning if = we > need to change it. >=20 > First, we need to ask ourselves if extension headers are worth = at all > and if they really make IPv6 a better protocol. Then if so, we need to > try to find a compromise between performance/deployment (vendors) vs > protocol design (ietf). A compromise may be a fixed maximum size on EH > chains. >=20 > If we found that EX are useless (or some of them) then we should > deprecate them. How about talking about the server farms that cause the problem? Maybe = they should be told to use one IP per host, or suffer from arbitrary = packet reordering caused by random load balancing. Or they should incur = the cost of labelling their flows, so load balancers can manage those = flows. Or about the load balancer, that wants to share paths without the cost = of differential delay. They could fix that by creating a tunnel with a = label and egress reordering. Or they could balance flows where they can, = and either balance randomly or drop traffic that isn't flow-labeled when = it exceeds a threshold. Or about those who buy routers that can't process extension headers, who = should realize they got an underpowered device that doesn't comply with = the standards. THere are a lot of 'practical' recommendations here - but, IMO, they = ought to first and foremost put the pain where the problem is. The = problem is sharing a single address without flow labeling, and devices = that think it's OK to implement "most" of a standard. Joe= From warren@kumari.net Sat Jun 8 16:59:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82AD21F93D7 for ; Sat, 8 Jun 2013 16:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.344 X-Spam-Level: X-Spam-Status: No, score=-99.344 tagged_above=-999 required=5 tests=[AWL=-1.839, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_53=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 WkJwXTBnHD0P for ; Sat, 8 Jun 2013 16:59:03 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E52821F93DA for ; Sat, 8 Jun 2013 16:59:02 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id DB8D51B40AA1; Sat, 8 Jun 2013 19:59:00 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> Date: Sat, 8 Jun 2013 19:58:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> To: Ray Hunter X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 23:59:07 -0000 On Jun 8, 2013, at 12:28 PM, Warren Kumari wrote: >=20 > On Jun 8, 2013, at 1:39 AM, Ray Hunter wrote: >=20 >>=20 >>=20 >> Warren Kumari wrote: >>> On Jun 7, 2013, at 7:59 PM, Nalini Elkins = wrote: >>>=20 >>>> On 6/7/2013 4:18 PM, Nalini Elkins wrote: >>>>>>> Well, HBH is the *correct* place to put things that are examined = per-hop ;-) >>>>> Maybe I am missing something but I am not seeing why the header we = are >>>>> proposing has to be looked at by ANY intermediate hop. The source = node >>>>> sticks in the timestamp and packet sequence number & we are all = set. >>>>> Why would that need to be in a HBH header? >>>>>> It wounldn't unless you need it to be examined by a router. If = it's only examined by the endpoints, it could be elsewhere. >>>>>> The point of the HBH header is to place all of the info a router = should *ever* need to look at (that isn't in the main IPv6 header) in = one place that's easy to find and parse. >>>> Sure. That is why we put it in the Dest Ops header. No need for a = router to ever bother with our little guy! >>>=20 >>> Sure, but the Dest Ops header shows up before the L4 information, = and so pushed the L4 header further out. >> Absolutely. >>=20 >>> Someone (it may have been Ron Bonica, hopefully he doesn't mind me = mentioning it) suggested reordering the header chain so that it goes IP = -> HBH -> L4 / Payload -:> Dest Options. >>> This is not a stupid idea=85. >>>=20 >>> Anyway, I decided that maybe having some data here would be useful, = so I decided to see how many sites from Dan Wing's list = (http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt)= I could: >>> A: make an IPv6 connection to and=20 >>> B: would accept packets where the first header was not the payload. >>>=20 >>> So, here are some stats. I connect (using scapy) and do an HTTP GET. = If that works, I try again, with an empty Destination Options (the only = thing I could figure out that would move the payload up and not = influence routing / seem weird). My methodology may be broken, and the = code (pasted at the bottom *certainly* is horrendous, but at least we = have *some* data. And kvetching about methodology, data is (IMO) more = interesting than where are currently are, which seems to not be = progressing=85=20 >>>=20 >>>=20 >>> [SNIP] >> >>=20 >> Thanks for the data. >>=20 >> But your test only pushed the L4 header out by one Destination Option = header (8 bytes (2 + PadN of 6)) >=20 > Yup. I mentioned that in my mail >=20 > I am planning on retesting the sites that managed to pass *any* = headers by adding more padding and seeing where various sites fall out. > Unfortunately scapy doesn't really like my adding the padding myself = (or, at least I haven't yet figured out yet how). I'll try beat it into = submission more, or just give up and hand-craft the packets myself.=20 And, while doing this (which I think I finally got to work right) I = discovered that I had an embarrassingly stupid bug in my initial code = -- I was only checking to make sure that I got *some* response from the = site, but not what the response was. This means that I was counting = sites that returned e.g. an ICMPv6DestUnreach as though they worked. The view of the world after fixing this (code below) is *very* different = -- one site (www.sapo.pt) works with extension headers, but only = sporadically - I'm guessing there is a LB and one node is missing = filters / there is ECMP and one path is missing filters. This is 0.09% of tested sites. This is more like what I would have = expected -- I'm paranoid and so expect others to be as well, and to = discard / reject packets that don't start with [TCP/UDP/ICMP].=20 It is also possible that there is something wrong with my methodology / = scapy's packet crafting, but seeing as one site works I think the = generated packets are ok... wkumari@vimes:~/tmp$ time sudo python ./ipv6_eh_tester.py [SNIP] www.zbozi.cz does not work if there is a Destination Option Extension = Header www.zerolag.com does not work if there is a Destination Option Extension = Header ### ziggi.uol.com.br returned an ICMPv6 Destination Unreachable ### zipmail.uol.com.br does not work if there is a Destination Option = Extension Header www.zimbra.free.fr does not work if there is a Destination Option = Extension Header www.singtel.com does not work if there is a Destination Option Extension = Header www.zuhause.de does not work if there is a Destination Option Extension = Header www.zoover.nl does not work if there is a Destination Option Extension = Header www.zwame.pt does not work if there is a Destination Option Extension = Header www.zoover.de does not work if there is a Destination Option Extension = Header Cannot resolve www.skoob.com.br ### www.xl.co.id returned an ICMPv6 Destination Unreachable ### www.slysoft.com does not work if there is a Destination Option Extension = Header www.socialsecurity.gov does not work if there is a Destination Option = Extension Header www.ssa.gov does not work if there is a Destination Option Extension = Header www.techtudo.com.br does not work if there is a Destination Option = Extension Header www.tradebit.com does not work if there is a Destination Option = Extension Header tutsplus.com does not work if there is a Destination Option Extension = Header www.turktelekom.com.tr does not work if there is a Destination Option = Extension Header www.ub.ac.id does not work if there is a Destination Option Extension = Header Progress: Processed 1100 sites, 0.092081 work with extension headers www.unesp.br does not work if there is a Destination Option Extension = Header www.newsen.com does not work if there is a Destination Option Extension = Header Working V6 sites: 1088, Working v6 sites with EH: 1. Percent: 0.091912 ------------------------------------------------------------ Working EH sites: www.sapo.pt real 81m3.027s user 2m4.080s sys 0m13.525s Here is the scapy show() for a working www.sapo.pt: >>> b.show() ###[ IPv6 ]### version=3D 6L tc=3D 0L fl=3D 0L plen=3D 24 nh=3D Destination Option Header hlim=3D 118 src=3D 2001:8a0:2104:ff:213:13:146:140 dst=3D 2606:700:e:551::100 ###[ IPv6 Extension Header - Destination Options Header ]### nh=3D TCP len=3D 0 autopad=3D On \options\ |###[ PadN ]### | otype=3D PadN [00: skip, 0: Don't change en-route] | optlen=3D 4 | optdata=3D '\x00\x00\x00\x00' ###[ TCP ]### sport=3D www dport=3D ftp_data seq=3D 2802195972 ack=3D 1 dataofs=3D 6L reserved=3D 0L flags=3D SA window=3D 8192 chksum=3D None urgptr=3D 0 options=3D {} So, it looks like 0.09% of sites on the big-I Internet will accept = packets that look like: >>> packet.show() ###[ IPv6 ]### version=3D 6 tc=3D 0 fl=3D 0 plen=3D None nh=3D Destination Option Header hlim=3D 64 src=3D 2606:700:e:551::100 dst=3D ###[ IPv6 Extension Header - Destination Options Header ]### nh=3D TCP len=3D None autopad=3D On \options\ ###[ TCP ]### sport=3D ftp_data dport=3D www seq=3D 0 ack=3D 0 dataofs=3D None reserved=3D 0 flags=3D S window=3D 8192 chksum=3D None urgptr=3D 0 options=3D {} ###[ Raw ]### load=3D 'GET / HTTP/1.0\r\n\r\n' Yes, I'm only testing web servers here, and those on the public = Internet. Feel free to perform your own testing internally, etc. W Ugly code: #!/usr/bin/python # # $Revision:: 88 $ # $Date:: 2013-06-08 18:26:06 -0400 (Sat, 08 Jun 2013) $ # $Author:: wkumari $ # $HeadURL:: svn+ssh://svn.kumari.net/data/svn/code/python#$ # Copyright: Warren Kumari (warren@kumari.net) -- 2013 # from scapy.all import * class PaddedDestOpt(Packet): name =3D "Padded IPv6 Destination Option Header" fields_desc =3D [ ByteEnumField("nh", 59, ipv6nh), FieldLenField("len", None, length_of=3D"padding", = fmt=3D"B", adjust =3D lambda pkt,x: (x+2+7)/8-1), # Stuff in a PadN header ByteField("otype", 0x01), FieldLenField("optlen", None, length_of=3D"padding", = fmt=3D"B"), StrLenField("padding", "", length_from =3D lambda pkt: pkt.optlen - = 2) ] overload_fields =3D {IPv6: { "nh": 60 }} def SupportsEH(name): try: response=3Dsr1(IPv6(dst=3Dname)/TCP(dport=3D80)/'GET / = HTTP/1.0\r\n\r\n', timeout=3D2, verbose=3D0) except socket.gaierror: print 'Cannot resolve %s' % name return (False, False) if packet: response=3Dsr1(IPv6(dst=3Dname)/IPv6ExtHdrDestOpt()/TCP(dport=3D80)/'G= ET / HTTP/1.0\r\n\r\n', timeout=3D4, verbose=3D0) if response: if response.haslayer(ICMPv6DestUnreach): print '### %s returned an ICMPv6 Destination Unreachable ###' % = name return (True, False) elif response.haslayer(ICMPv6TimeExceeded): print '!!! %s returned an ICMPv6 TTL Exceeded !!!' % name return (True, False) elif response.haslayer(TCP): print '*** %s works with extension headers! ***' % name return (True, True) else: print 'We got some other sort of error from %s. Packet:' % site response.show() return (True, False) else: print '%s does not work if there is a Destination Option Extension = Header' % name return (True, False) else: print '%s does NOT seem to work on IPv6' % name return (False, False) def ReadSiteList(filename): sites=3D[] for line in open(filename).read().splitlines(): try: site =3D line.split()[0] except IndexError: pass sites.append(site) return sites def main(): v6_sites=3D[] eh_sites=3D[] count =3D 0 # From: = http://www.employees.org/~dwing/aaaa-stats/ipv6-aaaa.2013-06-07_0800.txt sites =3D ReadSiteList('ipv6-aaaa.2013-06-07_0800.txt') #sites =3D ReadSiteList('ipv6_eh_sites.txt') for site in sites: count +=3D1 (v6, eh) =3D SupportsEH(site) if v6: v6_sites.append(site) if eh: eh_sites.append(site) if not count % 20: print 'Progress: Processed %d sites, %f work with extension = headers\n' % (count, = float(len(eh_sites)) / len(v6_sites) * 100.0) print 'Working V6 sites: %d, Working v6 sites with EH: %d. Percent: = %f' % (len(v6_sites), len (eh_sites), float(len(eh_sites)) / = len(v6_sites) * 100.0) print '\n\n' print '-'*60 print 'Working EH sites:' print '\n'.join([site for site in eh_sites]) =20 if __name__ =3D=3D '__main__': main() >=20 >>=20 >> That to me would suggest far more brokenness than simply that the L4 >> header had moved a small amount beyond the limit of the 'n' first = bytes >> of the packet (where 'n' is limited due to bandwidth limitations to = the >> ASIC), because 8 bytes is the absolute minimum a L4 header can be >> displaced. Your test traffic would certainly not constitute an >> abnormally long extension header chain IMHO. e.g. It might be that = there >> were problems with a broken parser not finding the L4 header at an = exact >> fixed location where it expected it, a filter that had been = configured, >> or some additional configuration to say drop all destination options. >=20 > Yup, the *huge* majority of the "brokenness" was probably filters like = the below - if you don't apply any filters / hashing / load-balancing = the router is only looking at the IP header. >=20 > term discard-ext-header-packets { > from { > next-header-except [ tcp udp icmpv6 ]; > } > then { > count discarded-packets-with-headers; > discard; > } > } > } >=20 >=20 > But, as we say in: = http://tools.ietf.org/html/draft-wkumari-long-headers-00 >=20 > "In one widely deployed router architecture, if there are any > extension headers between the IPv6 header and the upper-layer = header, > the forwarding logic never sees the upper-layer header, and so is = not > able to filter on it." >=20 > and=20 >=20 > "Network operators may filter traffic with extention header, because > of the lack of fixed extention header size, the complexity of > following header chains, and the inability of deployed routers to > look sufficently deep into packets to see the upper-layer header." >=20 > But, as a [ web / content ] operator, why would you allow in any = traffic that seems suspicious?=20 >=20 > We have an updated version of this draft sitting in an edit buffer = (and a corresponding recommendation draft), which we intend to submit in = a few days (as soon as we figure out who has the most recent revision, = why they didn't check it into svn, and who exactly was supposed to post = it=85 :-P)=20 >=20 >=20 >> Speaking entirely selfishly: accelerating fragment headers, and = AH+ESP >> through firewalls that examine L4 data would be the two use-cases I'd >> want to see most supported. >=20 > So, yes, there *are* extensions that are useful -- ESP, AH / Mobility = spring to mind. >=20 > One of the updates to the draft suggests that devices be designed to = be able to look N bytes into the packet to find the L4 info (where N is = 64 / 128 / 256). This seems like a good compromise between extensibility = and cost. Most *sites* on the Internet will continue to only allow = traffic in that they are expecting though. >=20 > As it is "hard" for machines / applications to know if they are = emitting a packet that will traverse the big-I Internet they should = assume that there will be a filter that will barf on EH headers and so = not emit them. >=20 > "For this reason, appplications and IPv6 stacks should avoid the use > of extention headers whenever possaible, and applications should be > designed to deal with the posibility that packets containing > extention headers may not be delivered." >=20 > What flavor of kink you get up to in the privacy of your own network = is (largely) your own decision, but keep in mind that: > 1: hardware is designed for the majority / profitable cases. > 2: adding complexity to the protocol has a cost to all (bugs per kloc, = limited developer resources, edge cases and operational considerations, = endless threads on v6ops@ ). >=20 >>=20 >> Or is the IPv6 Internet "web only"? >>=20 >=20 > Nope. No-one said that, but sometimes it does seem that way, doesn't = it? :-).=20 >=20 > W >=20 >> regards, >> RayH >>=20 >=20 > --=20 > With Feudalism, it's your Count that votes. >=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 fgont@si6networks.com Sat Jun 8 21:34:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0DD21F918F for ; Sat, 8 Jun 2013 21:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+kQOdDdTBOk for ; Sat, 8 Jun 2013 21:34:58 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9252D21F915B for ; Sat, 8 Jun 2013 21:34:57 -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 1UlXL8-0006aq-UF; Sun, 09 Jun 2013 06:34:52 +0200 Message-ID: <51B3C9A1.7010409@si6networks.com> Date: Sun, 09 Jun 2013 02:17:37 +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: Warren Kumari References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> In-Reply-To: <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 04:34:59 -0000 On 06/08/2013 02:22 AM, Warren Kumari wrote: > Someone (it may have been Ron Bonica, hopefully he doesn't mind me > mentioning it) suggested reordering the header chain so that it goes > IP -> HBH -> L4 / Payload -:> Dest Options. This is not a stupid > idea…. The problem is that if the destination system doesn't support the corresponding transport protocol, it cannot process the Destination Options (because transport protocol do not have a fixed TLV syntax). -- 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 Sat Jun 8 21:35:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF5521F91AB for ; Sat, 8 Jun 2013 21:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.874, 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 cEamGdHDDNE2 for ; Sat, 8 Jun 2013 21:35: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 462ED21F8EB2 for ; Sat, 8 Jun 2013 21:35:21 -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 1UlXLS-0006b0-Lc; Sun, 09 Jun 2013 06:35:11 +0200 Message-ID: <51B3E674.1040701@si6networks.com> Date: Sun, 09 Jun 2013 04:20: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: Brian E Carpenter References: <51B2BB07.2040208@gmail.com> In-Reply-To: <51B2BB07.2040208@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 04:35:23 -0000 On 06/08/2013 07:03 AM, Brian E Carpenter wrote: > > Has the Security Area actually reviewed this document? If not, > IMHO they certainly need to, PDQ. FWIW, I was meaning to review this document (as an individual), but it was unclear how we were supposed to do such reviews. 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 Sat Jun 8 21:48:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9721F91B1 for ; Sat, 8 Jun 2013 21:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBMSwabgmL8M for ; Sat, 8 Jun 2013 21:48:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1557621F91B0 for ; Sat, 8 Jun 2013 21:48:03 -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 1UlXXr-0006vR-05; Sun, 09 Jun 2013 06:48:00 +0200 Message-ID: <51B408EC.7000801@si6networks.com> Date: Sun, 09 Jun 2013 06:47:40 +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: Warren Kumari References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> In-Reply-To: <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 04:48:04 -0000 Hi, Warren, On 06/09/2013 01:58 AM, Warren Kumari wrote: > > And, while doing this (which I think I finally got to work right) I > discovered that I had an embarrassingly stupid bug in my initial > code -- I was only checking to make sure that I got *some* response > from the site, but not what the response was. This means that I was > counting sites that returned e.g. an ICMPv6DestUnreach as though they > worked. Question: Do you actually send the HTTP GET? If you're just probing with TCP SYN or ICMPv6 ech, you could use the tcp6 and icmp6 tools at: , which let you send fancy packets easily. If you're really sending the HTTP GET, then, if interested, I can add support to send arbitrary application-layer payloads to our tcp6 tool, such that this (and other) test are feasible. > The view of the world after fixing this (code below) is *very* > different -- one site (www.sapo.pt) works with extension headers, but > only sporadically - I'm guessing there is a LB and one node is > missing filters / there is ECMP and one path is missing filters. Only one? > This is 0.09% of tested sites. This is more like what I would have > expected -- I'm paranoid and so expect others to be as well, and to > discard / reject packets that don't start with [TCP/UDP/ICMP]. What about fragmentation support? 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 tjc@ecs.soton.ac.uk Sun Jun 9 01:34:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884F821F8FA4 for ; Sun, 9 Jun 2013 01:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_75=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 n972-MSiNDND for ; Sun, 9 Jun 2013 01:34:40 -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 59D1221F8F85 for ; Sun, 9 Jun 2013 01:34:40 -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 r598YV3P015472; Sun, 9 Jun 2013 09:34:31 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r598YV3P015472 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1370766871; bh=3SI8A4E4Ok9c2JEtY7585tzdfZw=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=ZIqMBNrOvsQeIsZ5ZO9Tt2CoM1owf6jeZL3y6dRYGYnsxV2kDAtNH19S2kRvler6T TTzK5ZycSmpEWT3Kl4/N22+782XvgflBEmcE9slFd3mdr/FroSrgakftWDnMZhm3K9 rvKKV4WZ4o++KFplQCJOXT6tj2OQYD6HCdMM9gkE= 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 p589YV0430607544Jw ret-id none; Sun, 09 Jun 2013 09:34:31 +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 r598XCKT008181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Jun 2013 09:33:13 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <51B2BB07.2040208@gmail.com> Date: Sun, 9 Jun 2013 09:33:11 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p589YV043060754400; tid=p589YV0430607544Jw; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r598YV3P015472 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 08:34:41 -0000 I agree with Brian's comments. I would also add that a document structure that was split into threats = that are equivalent to or have a parallel to IPv4 threats, and threats = that are IPv6-specific, would be useful to most readers. Do we know who the authors are, or who is producing the document? Tim On 8 Jun 2013, at 06:03, Brian E Carpenter = wrote: > Scott, >=20 > Has the Security Area actually reviewed this document? If not, > IMHO they certainly need to, PDQ. >=20 > A few things that caught my eye in a very quick scan: >=20 >> 7.3.1 Security threats and countermeasures >=20 >> Threat 7: A Network Address Translation (NAT) device is >> commonly deployed on a border of a network and translates >> either source or destination IP addresses of a packet in >> order to bridge two different types of networks such as >> private-global networks and IPv4-IPv6 networks. Particularly, >> NAT66, so-called NAT and port translation version 6 (NPTv6), >> translates IP addresses of packets between two distinct IPv6 >> networks >=20 > That is wrong. The IETF has not defined NAT66. A correct > statement would be: >=20 > IPv6-to-IPv6 Network Prefix Translation (NPTv6) translates > the prefixes of the addresses of packets between two > distinct IPv6 networks, but does not translate the interface > identifiers and port numbers. This is an Experimental > protocol, not on the standards track. >=20 > (the reference is RFC 6296) >=20 > Aside: if this is typical of the document's thoroughness and > accuracy, that is rather worrying. >=20 >> Measure 7: IETF is discussing stateless NAT66 (without a=20 >> state table) function. >=20 > As far as I know this is an untrue statement. >=20 >> Measure 8: To minimize the security risk by forged RA=20 >> messages, it is recommended that each host discard all RA=20 >> messages with an extremely short lifetime. >=20 > "Extremely short" isn't actionable. (Also, Measure 10 seems more > to the point.) >=20 >> Measure 18: IDSs have to support the decapsulation function=20 >> of the encapsulated IPv6 packets and 6to4 packets over 6to4. >=20 > Why is this limited to 6to4 tunnels? Any form of IPv6-in-IPv4 > tunnel has this risk. There are other risks specific to tunnels, > e.g. RFC 6324. >=20 > There are also many other security issues with 6to4 (RFC 3964) > and a number of guidelines about how to deploy it and how *not* > to deploy it (RFC 6343). >=20 > There are relevant documents that are listed in the references > but are not mentioned in the text - surely the important points > in them should be mentioned? At the moment, the document is an > incomplete story, and a reader might be confused into thinking > it covers everything there is to know. >=20 > In general I was surprised how short this document is. For > example,there is absolutely no discussion of scanning attacks, > DoS, or of the very real problems that firewalls face in > handling legitimate IPv6 extension headers at line speed. > Serious efforts such as Fernando Gont's are hundreds of pages long. >=20 > I'm no security expert, so again: it needs a serious review by > somebody who is one. >=20 > Regards > Brian Carpenter >=20 > On 08/06/2013 00:00, Scott Mansfield wrote: >>=20 >> From: Scott Mansfield Sent: Friday, June 07, 2013 5:22 AM To: >> 'saag@ietf.org' Subject: ITU-T Recommendation ITU-T X.1037,=20 >> Technical security guideline on deploying IPv6 >>=20 >> https://datatracker.ietf.org/liaison/1255/ >>=20 >> Further information on this document. X.1037 is in an ITU=20 >> approval process called AAP. The deadline for comments on=20 >> the document is 12 June 2013. There are a number of comments >> on the document already submitted by an ITU sector member,=20 >> so the document will have to be reviewed and modified before >> it can move forward. The next step in the process would be >> something call additional review. In additional review,=20 >> comments are accepted only on the parts of the document that=20 >> were modified, no new substantive comments on the rest of the >> document are accepted. So, if there are comments anyone=20 >> would like to make on the document, please send them to be=20 >> before 12 June. >>=20 >> Regards, -scott. >>=20 >> Scott Mansfield Ericsson Inc. +1 724 931 9316 >>=20 >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ v6ops mailing >> list v6ops@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Sun Jun 9 02:15:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35E621F8FEB for ; Sun, 9 Jun 2013 02:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_75=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 p4WVSWH6rGen for ; Sun, 9 Jun 2013 02:15:18 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65621F8AE8 for ; Sun, 9 Jun 2013 02:15:18 -0700 (PDT) Received: from [98.139.215.141] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 09 Jun 2013 09:15:17 -0000 Received: from [98.139.212.225] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 09 Jun 2013 09:15:17 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 09 Jun 2013 09:15:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 585163.56836.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 96935 invoked by uid 60001); 9 Jun 2013 09:15:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1370769317; bh=P8CO9lUpmKvSmZxIiwa/SF9jcAvcJSDuhuiNKJMkkY8=; 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=lYHU8A07QexdSoiSzbZGuQgp3Pq7iYbJQ55eQrPYeF2p2eio03y9XMeSbtqcts1Xzd2KIeauw+7ev3rYe7yPJdbmdVEW0Je0jc0ssSa0ueiXudOx/46D6PWwkWeJLQlwj8sXQ+WOGOKmpS5S5Df/F3X0hlG0YfXBxT48/qOLKDI= 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=P2XKUWk7POl3G2UvjQc3+PidEMVUIluZLeyqrM1UuD548oeJM2WtjYiUQCBKZlRyZzD3H8WXaXtUyxawsnxty9FVd/KDnd+DbuOTdS29ItnvpJoPemr0kdCRoR0U+hEZPc1JZEg/lAOZo0q5HWEoe4PVH1gOAhhcDpcDGLahC1M=; X-YMail-OSG: zWrzX2kVM1nVp0Ej5JmPjRo3lLsVn6EpZaHWbU9gEtm0RT7 Q_2KAfEAmeJH8cuTaVOlm_pA.rwZLy8Hcv1wywUU8De3lHhf8AH2rYINn040 IkEnuh.OzAu2w92KiaQhH6YJicqlCY.B0E56wDoMtXiAqUs6woL65IWvwNTc ONKd6LlfO25mvvJiE5mQj9h4y7e1RGgwdK.AYb0K5MrSOpDrimxx8J5_bpDE r4X8ml.JuJlEVgZRGKzmw22pHxgCb5zIlyIQvAhbbUsvg0roGxeWgZM3WECG i_4h4SkiDhHk60cTIspwOFOgtyxxdTalHFJ97zUh2jNAoqIiG1Y3DoHQOywO bCm4hDvdnsKfAJWAzh24_fAgQx7qeb65CNXA6GZM9mYc5FsDbCRLg.6igyi_ huvngeZxXORC3pPwggfpD1qKXh8Ob90.yg2sKujGlVF9Rg.4Kixsaur0JP1s zwWezF10IH1JS9nVCfy1xIz3k_jtXX88JxvT1o0.vy2bR7aPhB0mRvUxRKH5 QKNTjc8LnVAX9S5BT0IvlrwRTNBlYux7E.MzAGuabpPHyqHav7ZaVtGNulC. eMqYzQHlH Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Sun, 09 Jun 2013 02:15:17 PDT X-Rocket-MIMEInfo: 002.001, SGVyZSBpcyB0aGUgTGlhc2lvbiBzdGF0ZW1lbnQgZnJvbSB0aGUgSVRVOgoKaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyNTUvCgoKCgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBUaW0gQ2hvd24gPHRqY0BlY3Muc290b24uYWMudWs.Cj4gVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPjsgU2NvdHQgTWFuc2ZpZWxkIDxzY290dC5tYW5zZmllbGQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> Message-ID: <1370769317.75211.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Sun, 9 Jun 2013 02:15:17 -0700 (PDT) From: Mark Smith To: Tim Chown , Brian E Carpenter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 09:15:24 -0000 Here is the Liasion statement from the ITU:=0A=0Ahttps://datatracker.ietf.o= rg/liaison/1255/=0A=0A=0A=0A=0A=0A=0A----- Original Message -----=0A> From:= Tim Chown =0A> To: Brian E Carpenter =0A> Cc: "v6ops@ietf.org" ; Scott Mansfield =0A> Sent: Sunday, 9 June 2013 6:33 PM=0A> Subj= ect: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security= guideline on deploying IPv6=0A> =0A> I agree with Brian's comments.=0A> = =0A> I would also add that a document structure that was split into threats= that are =0A> equivalent to or have a parallel to IPv4 threats, and threat= s that are =0A> IPv6-specific, would be useful to most readers.=0A> =0A> Do= we know who the authors are, or who is producing the document?=0A> =0A> Ti= m=0A> =0A> On 8 Jun 2013, at 06:03, Brian E Carpenter =0A> wrote:=0A> =0A>> Scott,=0A>> =0A>> Has the Security Area ac= tually reviewed this document? If not,=0A>> IMHO they certainly need to, P= DQ.=0A>> =0A>> A few things that caught my eye in a very quick scan:=0A>> = =0A>>> 7.3.1 Security threats and countermeasures=0A>> =0A>>> Threat 7: A= Network Address Translation (NAT) device is=0A>>> commonly deployed on a = border of a network and translates=0A>>> either source or destination IP a= ddresses of a packet in=0A>>> order to bridge two different types of netwo= rks such as=0A>>> private-global networks and IPv4-IPv6 networks. Particul= arly,=0A>>> NAT66, so-called NAT and port translation version 6 (NPTv6),= =0A>>> translates IP addresses of packets between two distinct IPv6=0A>>> = networks=0A>> =0A>> That is wrong. The IETF has not defined NAT66. A corr= ect=0A>> statement would be:=0A>> =0A>> =A0 IPv6-to-IPv6 Network Prefix T= ranslation (NPTv6) translates=0A>> =A0 the prefixes of the addresses of pa= ckets between two=0A>> =A0 distinct IPv6 networks, but does not translate = the interface=0A>> =A0 identifiers and port numbers. This is an Experiment= al=0A>> =A0 protocol, not on the standards track.=0A>> =0A>> (the referen= ce is RFC 6296)=0A>> =0A>> Aside: if this is typical of the document's tho= roughness and=0A>> accuracy, that is rather worrying.=0A>> =0A>>> Measure= 7: IETF is discussing stateless NAT66 (without a =0A>>> state table) func= tion.=0A>> =0A>> As far as I know this is an untrue statement.=0A>> =0A>>>= Measure 8: To minimize the security risk by forged RA =0A>>> messages, i= t is recommended that each host discard all RA =0A>>> messages with an ext= remely short lifetime.=0A>> =0A>> "Extremely short" isn't actionable. (Als= o, Measure 10 seems =0A> more=0A>> to the point.)=0A>> =0A>>> Measure 18:= IDSs have to support the decapsulation function =0A>>> of the encapsulate= d IPv6 packets and 6to4 packets over 6to4.=0A>> =0A>> Why is this limited = to 6to4 tunnels? Any form of IPv6-in-IPv4=0A>> tunnel has this risk. There= are other risks specific to tunnels,=0A>> e.g. RFC 6324.=0A>> =0A>> Ther= e are also many other security issues with 6to4 (RFC 3964)=0A>> and a numb= er of guidelines about how to deploy it and how *not*=0A>> to deploy it (R= FC 6343).=0A>> =0A>> There are relevant documents that are listed in the r= eferences=0A>> but are not mentioned in the text - surely the important po= ints=0A>> in them should be mentioned? At the moment, the document is an= =0A>> incomplete story, and a reader might be confused into thinking=0A>> = it covers everything there is to know.=0A>> =0A>> In general I was surpri= sed how short this document is. For=0A>> example,there is absolutely no di= scussion of scanning attacks,=0A>> DoS, or of the very real problems that = firewalls face in=0A>> handling legitimate IPv6 extension headers at line = speed.=0A>> Serious efforts such as Fernando Gont's are hundreds of pages = long.=0A>> =0A>> I'm no security expert, so again: it needs a serious revi= ew by=0A>> somebody who is one.=0A>> =0A>> Regards=0A>> =A0 Brian Carpen= ter=0A>> =0A>> On 08/06/2013 00:00, Scott Mansfield wrote:=0A>>> =0A>>> F= rom: Scott Mansfield Sent: Friday, June 07, 2013 5:22 AM To:=0A>>> 'saag@i= etf.org' Subject: ITU-T Recommendation ITU-T X.1037, =0A>>> Technical secu= rity guideline on deploying IPv6=0A>>> =0A>>> https://datatracker.ietf.org= /liaison/1255/=0A>>> =0A>>> Further information on this document.=A0 X.103= 7 is in an ITU =0A>>> approval process called AAP.=A0 The deadline for com= ments on =0A>>> the document is 12 June 2013.=A0 There are a number of com= ments=0A>>> on the document already submitted by an ITU sector member, =0A= >>> so the document will have to be reviewed and modified before=0A>>> it= can move forward.=A0 The next step in the process would be=0A>>> somethin= g call additional review.=A0 In additional review, =0A>>> comments are acc= epted only on the parts of the document that =0A>>> were modified, no new = substantive comments on the rest of the=0A>>> document are accepted.=A0 So= , if there are comments anyone =0A>>> would like to make on the document, = please send them to be =0A>>> before 12 June.=0A>>> =0A>>> Regards, -scot= t.=0A>>> =0A>>> Scott Mansfield Ericsson Inc. +1 724 931 9316=0A>>> =0A>>>= =0A>>> =0A>>> =0A>>> =0A> ------------------------------------------------= ------------------------=0A>>> =0A>>> =0A>>> =0A>>> =0A>>> =0A>>> ________= _______________________________________ v6ops mailing=0A>>> list v6ops@iet= f.org =0A>>> https://www.ietf.org/mailman/listinfo/v6ops=0A>> ___________= ____________________________________=0A>> v6ops mailing list=0A>> v6ops@i= etf.org=0A>> https://www.ietf.org/mailman/listinfo/v6ops=0A> =0A> ________= _______________________________________=0A> v6ops mailing list=0A> v6ops@ie= tf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From nick@inex.ie Sun Jun 9 03:21:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0509221F92B7 for ; Sun, 9 Jun 2013 03:21:27 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_75=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 nGeu0Skx-Bha for ; Sun, 9 Jun 2013 03:21:26 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E7C6021F918F for ; Sun, 9 Jun 2013 03:21:20 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r59ALDZg014883 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 9 Jun 2013 11:21:13 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51B45718.7030907@inex.ie> Date: Sun, 09 Jun 2013 11:21:12 +0100 From: Nick Hilliard 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: Brian E Carpenter References: <51B2BB07.2040208@gmail.com> In-Reply-To: <51B2BB07.2040208@gmail.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 10:21:27 -0000 > In general I was surprised how short this document is. For > example,there is absolutely no discussion of scanning attacks, > DoS, or of the very real problems that firewalls face in > handling legitimate IPv6 extension headers at line speed. > Serious efforts such as Fernando Gont's are hundreds of pages long. > > I'm no security expert, so again: it needs a serious review by > somebody who is one. i had a quick flick through the document and concur. There are several howlers other than the ones you pointed out, and the document is clearly not written by anyone with any real working knowledge of ipv6. Would there be any value in writing an ID in v6ops to cover this topic more comprehensively? I guess it would go out of date very quickly. Nick From fgont@si6networks.com Sun Jun 9 07:11:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3149821F9473 for ; Sun, 9 Jun 2013 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.373, 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 VaVDCJOxIfqk for ; Sun, 9 Jun 2013 07:11:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC3621F9362 for ; Sun, 9 Jun 2013 07:11:13 -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 1UlgKr-0002fG-Pk; Sun, 09 Jun 2013 16:11:10 +0200 Message-ID: <51B47E92.1090107@si6networks.com> Date: Sun, 09 Jun 2013 15:09:38 +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: Nick Hilliard References: <51B2BB07.2040208@gmail.com> <51B45718.7030907@inex.ie> In-Reply-To: <51B45718.7030907@inex.ie> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 14:11:15 -0000 On 06/09/2013 12:21 PM, Nick Hilliard wrote: > > Would there be any value in writing an ID in v6ops to cover this topic more > comprehensively? I guess it would go out of date very quickly. We've doing that in separate documents, and different wgs (6man, opsec, and v6ops). Most of the documents are based on the large IPv6 security document I produced some time ago... and then published pieces of such document as stand-alone documents, so that they would be easier to move forward. For example, the one for ND is here: -- this one being the largest. And others can be found by searching my last name at an/or at: . 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 Sun Jun 9 07:13:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E2421F96E9 for ; Sun, 9 Jun 2013 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.158, 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 mXNmb+nApV6u for ; Sun, 9 Jun 2013 07:13:00 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id ED00F21F96D9 for ; Sun, 9 Jun 2013 07:12: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 1UlgMa-0002gR-Tf; Sun, 09 Jun 2013 16:12:57 +0200 Message-ID: <51B48A51.4020604@si6networks.com> Date: Sun, 09 Jun 2013 15:59: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: Scott Mansfield References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 14:13:00 -0000 Scott, Broad and (possibly) stupid question: What's the objective of this sort of liason? For example, the liason () claims that they are aware about all the work of the SEC area regarding IPv6 security, but I'd argue that most, if not all, such work happens in the Internet Area, or the O&A Area. Additionally, if there is no specified way for IETFers to provide feedback (even if it's eventually disregarded), then why should the IETF care about what ITU is doing? Cheers, Fernando On 06/07/2013 04:25 PM, Scott Mansfield wrote: > > > Here is the link to the document > > https://datatracker.ietf.org/documents/LIAISON/liaison-2013-05-07-itu-t-sg-17-sec-lso-on-the-itu-t-recommendation-itu-t-x1037-technical-security-guideline-on-deploying-ipv6-to-ietf-security-are-attachment-1.pdf > > > > > > > regards, > > -scott. > > > > > > > > *From:*fgont.si6networks.nexus@gmail.com > [mailto:fgont.si6networks.nexus@gmail.com] *On Behalf Of *Fernando > Gont *Sent:* Friday, June 07, 2013 10:13 AM *To:* Scott Mansfield > *Cc:* v6ops@ietf.org *Subject:* Re: [v6ops] FW: ITU-T Recommendation > ITU-T X.1037, Technical security guideline on deploying IPv6 > > > > Can anyone provide the url for the actual document? > > Thanks! Fernando > > On Jun 7, 2013 2:14 PM, "Scott Mansfield" > > > wrote: > > > > > > *From:*Scott Mansfield *Sent:* Friday, June 07, 2013 5:22 AM *To:* > 'saag@ietf.org ' *Subject:* ITU-T > Recommendation ITU-T X.1037, Technical security guideline on > deploying IPv6 > > > > https://datatracker.ietf.org/liaison/1255/ > > > > Further information on this document. X.1037 is in an ITU approval > process called AAP. The deadline for comments on the document is 12 > June 2013. There are a number of comments on the document already > submitted by an ITU sector member, so the document will have to be > reviewed and modified before it can move forward. The next step in > the process would be something call additional review. In additional > review, comments are accepted only on the parts of the document that > were modified, no new substantive comments on the rest of the > document are accepted. So, if there are comments anyone would like > to make on the document, please send them to be before 12 June. > > > > Regards, > > -scott. > > > > Scott Mansfield > > Ericsson Inc. > > +1 724 931 9316 > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tom.taylor.stds@gmail.com Sun Jun 9 09:44:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C1921F8EAE for ; Sun, 9 Jun 2013 09:44: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 Ym-zfFowyGPu for ; Sun, 9 Jun 2013 09:44:14 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 152F721F85F7 for ; Sun, 9 Jun 2013 09:44:14 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id u16so14538287iet.22 for ; Sun, 09 Jun 2013 09:44: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0Jgu+dgN0pv01+y1S5ZJVKBaxOxYOjv6BMqtZn1YAxE=; b=sLJmcx3DO5TrDlgurNQ4fnMO8WctuN0YQ1BJHzd+wtpd7NShYjxwRJSo7qYumua5ql QmS0B99hPlD+UrvnLzRWE0jGoisS5O1Ag17z7g6lxWUYqK11zIQ01BGsyuIh+uevqbRe N2nEqNpYhayvvKAF5FvY6BzSWrA9gmgnvs/sDWraazFy3pLRA/ouwuWjj7PLNYkPruwh W5uqJzdCEZUdUbjP4WfTzzpYlm9fB3744fehG+E4jtqsSXwSxLWJCyQoYM14wYDIZMXR g4XL2cuP0SfJlGnSHQUCaodmVYMqgmjVBUusHXY8sPTQCmPtaw9zW760C4yp42hYarko uGuQ== X-Received: by 10.50.114.161 with SMTP id jh1mr2590594igb.112.1370796250899; Sun, 09 Jun 2013 09:44:10 -0700 (PDT) Received: from [192.168.1.64] ([216.254.162.169]) by mx.google.com with ESMTPSA id d9sm5393688igr.4.2013.06.09.09.44.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 09:44:10 -0700 (PDT) Message-ID: <51B4B0D9.5000104@gmail.com> Date: Sun, 09 Jun 2013 12:44:09 -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: Tim Chown References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 16:44:14 -0000 On 09/06/2013 4:33 AM, Tim Chown wrote: > I agree with Brian's comments. > > I would also add that a document structure that was split into threats that are equivalent to or have a parallel to IPv4 threats, and threats that are IPv6-specific, would be useful to most readers. > > Do we know who the authors are, or who is producing the document? > > Tim > ... ITU-T documents have an assigned editor while they are in process, but are modified on the basis of written contributions from any interested party. The contributions are reviewed at meetings and the accepted parts are folded in by the editor. As an X-series document, this is being produced by Study Group 17. Last Call ends June 12, so Scott has to get the IETF response in before then. The editor is Koji Nakao and the Rapporteur (equivalent to WG Chair) is Patrick Mwe Sigwa . You can pull all this out of the Study Group 17 page at http://www.itu.int/en/ITU-T/studygroups/2013-2016/17/Pages/default.aspx. Tom From fgont@si6networks.com Sun Jun 9 10:49:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9C221F9420 for ; Sun, 9 Jun 2013 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.361, 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 kwASqJVQpPjX for ; Sun, 9 Jun 2013 10:49: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 AE16F21F940D for ; Sun, 9 Jun 2013 10:48: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 1UljjW-0007X0-SD; Sun, 09 Jun 2013 19:48:52 +0200 Message-ID: <51B4B8BE.3020006@si6networks.com> Date: Sun, 09 Jun 2013 19:17: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: Tom Taylor References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> In-Reply-To: <51B4B0D9.5000104@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 17:49:03 -0000 On 06/09/2013 06:44 PM, Tom Taylor wrote: > As an X-series document, this is being produced by Study Group 17. Last > Call ends June 12, so Scott has to get the IETF response in before then. > The editor is Koji Nakao and the Rapporteur > (equivalent to WG Chair) is Patrick Mwe Sigwa . You > can pull all this out of the Study Group 17 page at > http://www.itu.int/en/ITU-T/studygroups/2013-2016/17/Pages/default.aspx. Put another way: Who should we fire our feedback to? All of the above? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tom.taylor.stds@gmail.com Sun Jun 9 14:19:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E1921F8E9D for ; Sun, 9 Jun 2013 14:19:44 -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 f4x2hN3ueG5b for ; Sun, 9 Jun 2013 14:19:43 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ECACF21F8E2C for ; Sun, 9 Jun 2013 14:19:42 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id aq17so14373948iec.5 for ; Sun, 09 Jun 2013 14:19:41 -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=F/p7Wq+rT+3m5o5QaB+BbAtS3uEPDbHilfky+mmKdTc=; b=kfLMGT3gK2Ul2tR3c34lKWDHRZ/KvQex9/KGMKisOZtKmajeLSnEzKY9MtLagUZeZu M7v2tilZOAOKSl7PCkw04itgJNc8SjD6HA0lLSNQ3wchAXpLjmVozGyiXdDeaEIA3Bn9 tRrSzMjLrJeAD8xs1SZO4Z8BGqGb7nFgqrCFMmkFTHFbGu0pSFsTTtxzXyUdEmolauIV IL6HUq3+xBGZQaczM8T0lljI5J6edIGCAcgYxJMV0Jelt7y8Lu0KOjTx33S+X1eEcsyj dt+G2TJOYspD/vlQaCEE58iS91brs+zfYISc4lkv+LUg8fAJ4TjVJH6evQwEjzRnGHyL xFOQ== X-Received: by 10.50.11.72 with SMTP id o8mr2889519igb.44.1370812781045; Sun, 09 Jun 2013 14:19:41 -0700 (PDT) Received: from [192.168.1.64] ([216.254.162.169]) by mx.google.com with ESMTPSA id d7sm5767047igx.5.2013.06.09.14.19.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 14:19:40 -0700 (PDT) Message-ID: <51B4F16B.1010100@gmail.com> Date: Sun, 09 Jun 2013 17:19:39 -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: Fernando Gont References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> In-Reply-To: <51B4B8BE.3020006@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 21:19:44 -0000 On 09/06/2013 1:17 PM, Fernando Gont wrote: > On 06/09/2013 06:44 PM, Tom Taylor wrote: >> As an X-series document, this is being produced by Study Group 17. Last >> Call ends June 12, so Scott has to get the IETF response in before then. >> The editor is Koji Nakao and the Rapporteur >> (equivalent to WG Chair) is Patrick Mwe Sigwa . You >> can pull all this out of the Study Group 17 page at >> http://www.itu.int/en/ITU-T/studygroups/2013-2016/17/Pages/default.aspx. > > Put another way: Who should we fire our feedback to? All of the above? > > Thanks, > Very briefly, the formal channel is the liaison Scott has to write up. That has to indicate all the points that need fixing, at least in summary form, but actual new text is preferred. I'll volunteer to help create that document if necessary. The relevant procedural text is: During the last call, should any Member State or Sector Member be of the opinion that the draft new or revised Recommendation should not be approved, they should advise their reasons for disapproving and indicate the possible changes that would facilitate further consideration and approval of the draft new or revised Recommendation. TSB will make the comments available to the membership of ITU-T. I'm a little rusty, but I think the IETF is considered the equivalent of a Sector Member. Informally you can send E-mails to the Rapporteur and his two associates. His Associate Rapporteurs are Dmitry Kostrov and Heung Ryong Oh . Reconsidering, I think the Rapporteur's last name is Mwesigwa without the space. Tom Taylor From chsharp@cisco.com Sun Jun 9 15:34:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E000121F8E8C for ; Sun, 9 Jun 2013 15:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEvSHzVY9AgV for ; Sun, 9 Jun 2013 15:34:45 -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 37ABD21F85E0 for ; Sun, 9 Jun 2013 15:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2474; q=dns/txt; s=iport; t=1370817285; x=1372026885; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XbJXvtMvBp8OwbYoZJ88BhBI8EL7jsV0XjkRoXKP5tE=; b=mmEsDJgaTatApf7mck24NleRWt/mojsTArw7iw3QHx5NTPW9t3WjW9Jf QIB0CUcHfujitt69qWkq7/oz9D4oW0dAVKeP7hDNcDee55BCQRw5rWudw 8YkMF2UlQbxINSp7JgzBYXo0dKa9Jx/lSKG+30qUVncQ5cwOp529kxgzP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAMkBtVGtJV2b/2dsb2JhbABZgwkwSb4+ehZ0giMBAQEDAQEBATc0CwULAgEIGAoUECEGCxwJAgQBDQUIh3MDCQYMsAgNiFKMW4IqAjEHgn9hA5VZjgWFJIFYgTeCJw X-IronPort-AV: E=Sophos;i="4.87,833,1363132800"; d="scan'208";a="220645273" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jun 2013 22:34:44 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r59MYiID003251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Jun 2013 22:34:44 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.211]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Sun, 9 Jun 2013 17:34:44 -0500 From: "Chip Sharp (chsharp)" To: Tom Taylor , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: AQHOZTCcMwV4aF0eKUCpeRA66gqmwJkt8/kAgABDkICAABT6gA== Date: Sun, 9 Jun 2013 22:34:43 +0000 Message-ID: <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> In-Reply-To: <51B4F16B.1010100@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.248.187] Content-Type: text/plain; charset="us-ascii" Content-ID: <3950A3EEFA180445AB2C8513433AAF4F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Fernando Gont , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 22:34:50 -0000 My $.02, Sending a liaison at the end of the process, when the SG is about to send a= document into the approval process is not indicative of collaboration. Study Groups should send the liaison when they start the work and with each= draft developed. Also, only ITU-T Members can submit comments during AAP. So the Rapporteu= rs are not obligated to consider comments sent to them by non-Members. ISOC is a Sector Member. Chip On Jun 9, 2013, at 11:19 PM, Tom Taylor wrote: > On 09/06/2013 1:17 PM, Fernando Gont wrote: >> On 06/09/2013 06:44 PM, Tom Taylor wrote: >>> As an X-series document, this is being produced by Study Group 17. Last >>> Call ends June 12, so Scott has to get the IETF response in before then= . >>> The editor is Koji Nakao and the Rapporteur >>> (equivalent to WG Chair) is Patrick Mwe Sigwa . Yo= u >>> can pull all this out of the Study Group 17 page at >>> http://www.itu.int/en/ITU-T/studygroups/2013-2016/17/Pages/default.aspx= . >>=20 >> Put another way: Who should we fire our feedback to? All of the above? >>=20 >> Thanks, >>=20 >=20 > Very briefly, the formal channel is the liaison Scott has to write up. Th= at has to indicate all the points that need fixing, at least in summary for= m, but actual new text is preferred. I'll volunteer to help create that doc= ument if necessary. The relevant procedural text is: >=20 > >=20 > During the last call, should any Member State or Sector Member be of the = opinion that the draft new or revised Recommendation should not be approved= , they should advise their reasons for disapproving and indicate the possib= le changes that would facilitate further consideration and approval of the = draft new or revised Recommendation. TSB will make the comments available t= o the membership of ITU-T. >=20 > >=20 > I'm a little rusty, but I think the IETF is considered the equivalent of = a Sector Member. >=20 > Informally you can send E-mails to the Rapporteur and his two associates.= His Associate Rapporteurs are Dmitry Kostrov and H= eung Ryong Oh . >=20 > Reconsidering, I think the Rapporteur's last name is Mwesigwa without the= space. >=20 > Tom Taylor > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From arturo.servin@gmail.com Sun Jun 9 16:44:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE2F21F8DDD for ; Sun, 9 Jun 2013 16:44:39 -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.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_75=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 4y8Te99qrfG8 for ; Sun, 9 Jun 2013 16:44:38 -0700 (PDT) Received: from mail-gh0-x234.google.com (mail-gh0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id A87A221F85F4 for ; Sun, 9 Jun 2013 16:44:38 -0700 (PDT) Received: by mail-gh0-f180.google.com with SMTP id f18so507344ghb.25 for ; Sun, 09 Jun 2013 16:44:35 -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=t01VZ5blQRb9RN6FEEZHtGVxrqDsl8xWRN8T4fnX5CA=; b=Vs7PUHbwjV/Y+JzbU54DaqW0Pekt87KU+KvoWwLiBGFd2i1ZdUtRlkpriqLnJNV1Jz pORMADkoisK1Qqms2UNZCZBPWL92bwkjtPn8lt8RbunIvXUe4915LbD8sHgVi/graIw/ fHuY8ux13uisNqEQ/jr4RXZ/4uXvGuKE/O8FneBZSisYfHgkbusaswwa/9pDfjAms7P5 yT+sNe2RjBUppenmF6KM2yaNmC0q9MlfYmbsLzOAe+aosCk1JRqVbE8+P6ihN1Fl+Tvn aeZahGfDD650GxZY+5eUZgqYXeeFJUomd2H9teZOrlXHou+2oSgK/ybkwIhMZdgwZtDJ 3z2w== X-Received: by 10.236.41.14 with SMTP id g14mr3146891yhb.69.1370821475418; Sun, 09 Jun 2013 16:44:35 -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 v28sm954822yhv.17.2013.06.09.16.44.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 16:44:34 -0700 (PDT) Message-ID: <51B5135D.30203@gmail.com> Date: Sun, 09 Jun 2013 20:44:29 -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: Nick Hilliard References: <51B2BB07.2040208@gmail.com> <51B45718.7030907@inex.ie> In-Reply-To: <51B45718.7030907@inex.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 23:44:39 -0000 Nick, About IPv6 Security? There is one in opsec: http://tools.ietf.org/html/draft-ietf-opsec-v6-02 /as On 6/9/13 7:21 AM, Nick Hilliard wrote: >> In general I was surprised how short this document is. For >> example,there is absolutely no discussion of scanning attacks, >> DoS, or of the very real problems that firewalls face in >> handling legitimate IPv6 extension headers at line speed. >> Serious efforts such as Fernando Gont's are hundreds of pages long. >> >> I'm no security expert, so again: it needs a serious review by >> somebody who is one. > > i had a quick flick through the document and concur. There are several > howlers other than the ones you pointed out, and the document is clearly > not written by anyone with any real working knowledge of ipv6. > > Would there be any value in writing an ID in v6ops to cover this topic more > comprehensively? I guess it would go out of date very quickly. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fgont@si6networks.com Sun Jun 9 18:04:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5349921F8EB2 for ; Sun, 9 Jun 2013 18:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 cjmgzvdnEbR3 for ; Sun, 9 Jun 2013 18:04: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 BFA7921F8EAE for ; Sun, 9 Jun 2013 18:04:22 -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 1UlqWt-0001qr-Dq; Mon, 10 Jun 2013 03:04:17 +0200 Message-ID: <51B50594.7040303@si6networks.com> Date: Mon, 10 Jun 2013 00:45:40 +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: "Chip Sharp (chsharp)" References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> In-Reply-To: <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 01:04:23 -0000 On 06/10/2013 12:34 AM, Chip Sharp (chsharp) wrote: > My $.02, Sending a liaison at the end of the process, when the SG is > about to send a document into the approval process is not indicative > of collaboration. It's hard to collaborate when the rules are not clear. -- At the very least, I'd have expected that it was straightforward who we were supposed to send our feedback to, if it was possible to have public discussion of the feedback, etc > Also, only ITU-T Members can submit comments during AAP. So the > Rapporteurs are not obligated to consider comments sent to them by > non-Members. ISOC is a Sector Member. Does that mean that anyone belonging to an ISOC chapter can submit? Or.. what are the requirements? Are there "ISOC representatives" at ITU? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From niall.oreilly@ucd.ie Mon Jun 10 02:50:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1549C21F8956 for ; Mon, 10 Jun 2013 02:50:41 -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=[AWL=-1.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 B6NYge-O2X9v for ; Mon, 10 Jun 2013 02:50:40 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0148721F86FB for ; Mon, 10 Jun 2013 02:50:38 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k13so2911773wgh.0 for ; Mon, 10 Jun 2013 02:50:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Bp71nWiMQXbEIOUpkDt36YtGfxHd/Iy7bbTyyp+yNvM=; b=kHWzfIXQ7CmhT7FtQDO7pAI++uc70XVYpp4Fs10KnP1SBj+7WrptqjlfVUhtKN5ESA 6baCElO5zJFsxAk61iPQtzeFLQfCghY4l8R3vT8lSje1Yr1+Bb6oZJ4mccWvtMPcm77J M2D6XzucsSuU27qnBrcnTRffvE3m2kA6gRnUoIlG3lWAI7tOq/fCY8RqWLMKUN9vDGPM d2ay9R5oQIagSHequmYs6awo2tOHZDEKzbmoTIYAeR8as2SKpYhDxAcpHMgHedv1QNS3 PckDbax2AbJT3tLoI5+Rd0sv9+dTmjiOIgv1gnXvBPzMjykVaeWMa/lrOQjS0kSAP3Kj /hPw== X-Received: by 10.180.109.84 with SMTP id hq20mr4283593wib.11.1370857838292; Mon, 10 Jun 2013 02:50:38 -0700 (PDT) Received: from dhcp-c101a88b.ucd.ie (dhcp-c101a88b.ucd.ie. [193.1.168.139]) by mx.google.com with ESMTPSA id x13sm10150748wib.3.2013.06.10.02.50.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 02:50:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: "Niall O'Reilly" In-Reply-To: <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> Date: Mon, 10 Jun 2013 10:50:35 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> To: " WG" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmy1TZE9xwB1/0J0EaIm8wX1gk4ysLaky1psmTZlF0XlqyRNF5FbfzWJX/JeiqF/imqnLWj Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 09:50:41 -0000 On 9 Jun 2013, at 23:34, Chip Sharp (chsharp) wrote: > ISOC is a Sector Member. As are the RIRs, with the apparent exception of LACNIC. Niall O'Reilly From bill.jouris@insidethestack.com Mon Jun 10 07:13:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EB521F84CA for ; Mon, 10 Jun 2013 07:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 wSrhLN0CJ0v0 for ; Mon, 10 Jun 2013 07:13:47 -0700 (PDT) Received: from nm30.access.bullet.mail.sp2.yahoo.com (nm30.access.bullet.mail.sp2.yahoo.com [98.139.44.157]) by ietfa.amsl.com (Postfix) with ESMTP id B5F7921F84CD for ; Mon, 10 Jun 2013 07:13:47 -0700 (PDT) Received: from [98.139.44.103] by nm30.access.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2013 14:13:47 -0000 Received: from [98.139.44.86] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2013 14:13:47 -0000 Received: from [127.0.0.1] by omp1023.access.mail.sp2.yahoo.com with NNFMP; 10 Jun 2013 14:13:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 338404.99126.bm@omp1023.access.mail.sp2.yahoo.com Received: (qmail 21307 invoked by uid 60001); 10 Jun 2013 14:13:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370873626; bh=duw8/WFGLFWWru9l2mczVvU8JppzxO/1vaxdG9sRbLs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=GCvi3zAtT8kPiO3knx+LoIRt7gl6NmNwCOQpvqJRf3uIDtywxRdVyi2+hlspfCBa++dwJFoLbhXGhgrNqPWIyJhad3oSuux3AYxRdymq0xLaD1JoI0gWrXET/yTeTllThH4H5/5v7W9ystZdeBr34HeDS2Fi3U756pn3vy4dY3U= X-YMail-OSG: LZLgROMVM1l5s4Dl8gzVAzCG.nF46JbsGP9PpMwC8ejn9EN 5E1qZhG0Putm9mAAgkvbcOolxEA2AE7gvmYe.6IhFzS4tx5ufSyvBBa9mGPN eYX77AGNorBlWbHNHrXUjBvCJdjmDL_iaVs6DG3crZmjI.0d2fi9EkCugmur sQ1Hi0syvM8iYx9DHNWcrJx454Z7CjLuJtFoIxieCFqr.8_Mp_grG5w6ESbg GPfETHm7j_f34MBTnxtd2C.ldVm3AULw8DBA.SU4li7BrCcHbCLKV.oj0OR5 _r_Ar3Su.oFzm.yX0Xe3addN1.EidSxS0z9l02lz12A57_nfZ97HRWHUXzpA iX5ATjfnt_JxqdFtOtVc8fCSIVIxQIsWpGYlR8t4Ck.T2CXFCJwRRMM8Z0lR W7JLl4J0bZlDa296Ak0lY7owcLlVJbTzxaIVPQyhbcuS70G5XmstynOzAaBg 33utp6aQv9_PzuAU8Xn99zRMAfg_GOQosC8Ev8yGbGv3aWTPrQkMx8_jtB89 AW7uBz6kYmU04lBV57uqDNfRBZJ1i09N5dXWTswzJ4DG7NbDCUUuWMWlu0Cq vkHc3.VTQ2S5xHQow7L.tMmbTguQETfwnH_ODAPpMyD9j7thEfE69W6_d3rM QOHrov.Zi.oEZi.Rf7l7v_mxkkQ-- Received: from [50.143.174.186] by web2802.biz.mail.ne1.yahoo.com via HTTP; Mon, 10 Jun 2013 07:13:46 PDT X-Rocket-MIMEInfo: 002.001, TGV0IG1lIHNlY29uZCBGZXJuYW5kbydzIGNvbW1lbnRzLsKgIA0KDQpVbmxlc3Mgc29tZW9uZSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgYSByZWFzb24gd2h5IHRoZSBwcm9jZWR1cmVzIGZvciBjb2xsYWJvcmF0aW9uIHNob3VsZCBOT1QgYmUgc2hhcmVkL3B1YmxpYyAuIC4gLiAuIA0KDQpCaWxsIEpvdXJpcw0KSW5zaWRlIFByb2R1Y3RzLCBJbmMuDQp3d3cuaW5zaWRldGhlc3RhY2suY29tDQo4MzEtNjU5LTgzNjANCjkyNS04NTUtOTUxMiAoZGlyZWN0KQ0KDQoNCi0tLSBPbiBTdW4sIDYvOS8xMywgRmVybmEBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.146.552 Message-ID: <1370873626.19718.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> Date: Mon, 10 Jun 2013 07:13:46 -0700 (PDT) From: Bill Jouris To: "v6ops@ietf.org" In-Reply-To: <51B50594.7040303@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-1245911596-1370873626=:19718" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:13:52 -0000 ---153701192-1245911596-1370873626=:19718 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Let me second Fernando's comments.=A0=20 Unless someone would like to suggest a reason why the procedures for collab= oration should NOT be shared/public . . . .=20 Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Sun, 6/9/13, Fernando Gont wrote: From: Fernando Gont Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical secu= rity guideline on deploying IPv6 To: "Chip Sharp (chsharp)" Cc: "v6ops@ietf.org" , "Scott Mansfield" Date: Sunday, June 9, 2013, 3:45 PM On 06/10/2013 12:34 AM, Chip Sharp (chsharp) wrote: > My $.02, Sending a liaison at the end of the process, when the SG is > about to send a document into the approval process is not indicative > of collaboration.=20 It's hard to collaborate when the rules are not clear. -- At the very least, I'd have expected that it was straightforward who we were supposed to send our feedback to, if it was possible to have public discussion of the feedback, etc > Also, only ITU-T Members can submit comments during AAP.=A0=A0=A0So the > Rapporteurs are not obligated to consider comments sent to them by > non-Members. ISOC is a Sector Member. Does that mean that anyone belonging to an ISOC chapter can submit? Or.. what are the requirements? Are there "ISOC representatives" at ITU? Cheers, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ---153701192-1245911596-1370873626=:19718 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Let me second Fernando's comments. 
    =
    Unless someone would like to suggest a reason why the procedures for co= llaboration should NOT be shared/public . . . .

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


    --- On= Sun, 6/9/13, Fernando Gont <fgont@si6networks.com> wro= te:

    From: Fernando Gont <fgont@si6networ= ks.com>
    Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, = Technical security guideline on deploying IPv6
    To: "Chip Sharp (chsharp)= " <chsharp@cisco.com>
    Cc: "v6ops@ietf.org" <v6ops@ietf.org>,= "Scott Mansfield" <scott.mansfield@ericsson.com>
    Date: Sunday, Ju= ne 9, 2013, 3:45 PM

    On 06/10/2013 12:34 AM, Chip= Sharp (chsharp) wrote:
    > My $.02, Sending a liaison at the end of th= e process, when the SG is
    > about to send a document into the approva= l process is not indicative
    > of collaboration.

    It's hard to = collaborate when the rules are not clear. -- At the very
    least, I'd have= expected that it was straightforward who we were
    supposed to send our f= eedback to, if it was possible to have public
    discussion of the feedback= , etc


    > Also, only ITU-T Members can submit comments during A= AP.   So the
    > Rapporteurs are not obligated to consid= er comments sent to them by
    > non-Members. ISOC is a Sector Member.
    Does that mean that anyone belonging to an ISOC chapter can submit?
    Or.. what are the requirements? Are there "ISOC representatives" at I= TU?

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




    _________________= ______________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    =
    ---153701192-1245911596-1370873626=:19718-- From warren@kumari.net Mon Jun 10 12:09:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CF521F95D7 for ; Mon, 10 Jun 2013 12:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[AWL=0.870, 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 44RNfQPr0XQT for ; Mon, 10 Jun 2013 12:09:07 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31DB11E80A5 for ; Mon, 10 Jun 2013 12:09:05 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id 01DE01B401CE; Mon, 10 Jun 2013 15:09:03 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <51B408EC.7000801@si6networks.com> Date: Mon, 10 Jun 2013 15:09:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1503) Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:09:12 -0000 On Jun 9, 2013, at 12:47 AM, Fernando Gont = wrote: > Hi, Warren, >=20 > On 06/09/2013 01:58 AM, Warren Kumari wrote: >>=20 >> And, while doing this (which I think I finally got to work right) I >> discovered that I had an embarrassingly stupid bug in my initial >> code -- I was only checking to make sure that I got *some* response >> from the site, but not what the response was. This means that I was >> counting sites that returned e.g. an ICMPv6DestUnreach as though they >> worked. >=20 > Question: Do you actually send the HTTP GET? Yup. I do the following: 1: Send 'GET / HTTP/1.0\r\n\r\n' to port 80. If the site responds, I classify it as "working" for IPv6 and = continue. 2: Send 'GET / HTTP/1.0\r\n\r\n' to port 80, with an empty Destination = Option (simply padding). If the site sends back an ICMPv6DestUnreach or a ICMPv6TimeExceeded I = classify it as not working with extension headers and abort. If the site replies with a TCP payload I classify it as working with = Extension Headers. Otherwise I assume it is some other error and print the packet -- this = hasn't happened. >=20 > If you're just probing with TCP SYN or ICMPv6 ech, you could use the > tcp6 and icmp6 tools at: = , > which let you send fancy packets easily. >=20 > If you're really sending the HTTP GET, then, if interested, I can add > support to send arbitrary application-layer payloads to our tcp6 tool, > such that this (and other) test are feasible. >=20 Yes please. >=20 >=20 >> The view of the world after fixing this (code below) is *very* >> different -- one site (www.sapo.pt) works with extension headers, but >> only sporadically - I'm guessing there is a LB and one node is >> missing filters / there is ECMP and one path is missing filters. >=20 > Only one? Only one site seems to support EH packets, and that only sporadically. I = tried hitting it a few times (ten or so) and it only responded correctly = twice. >>> working=3D0 >>> for count in range (1,200): ... = b=3Dsr1(IPv6(dst=3D'www.sapo.pt')/IPv6ExtHdrDestOpt()/TCP(dport=3D80)/'GET= / HTTP/1.0\r\n\r\n', timeout=3D2, verbose=3D0) ... if b: ... working +=3D1 >>> working 16 So, 16 in 200 connections got back a response. Maybe 12-13 machines = behind a LB? I could fingerprint further, but=85. >=20 >=20 >> This is 0.09% of tested sites. This is more like what I would have >> expected -- I'm paranoid and so expect others to be as well, and to >> discard / reject packets that don't start with [TCP/UDP/ICMP]. >=20 > What about fragmentation support? Didn't test, but many sites drop fragments: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 >=20 > Thanks! >=20 Nah, thank you! W > 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 Eagles soar but a weasel will never get sucked into a jet engine=20 From touch@isi.edu Mon Jun 10 12:19:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE9921F9A3A for ; Mon, 10 Jun 2013 12:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=-0.550, 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 xnLtsTFjb0oz for ; Mon, 10 Jun 2013 12:19:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE3E21F9A30 for ; Mon, 10 Jun 2013 12:19:17 -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 r5AJID9A015362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 12:18:13 -0700 (PDT) Message-ID: <51B62669.3030605@isi.edu> Date: Mon, 10 Jun 2013 12:18:01 -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: Warren Kumari References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> In-Reply-To: <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , "v6ops@ietf.org" , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:19:21 -0000 Hi, Warren, For sites where you got a response, can you let us know whether the ICMP destination unreachable was from an intermediate router or the final destination? Based on the info below, it's clear that the option you tested fails, but not where or why. It could as easily be endpoint failure. And if the error is at the endpoints, then any solution that presumes an endpoint fix could just as easily assume correcting this flaw... Joe On 6/10/2013 12:09 PM, Warren Kumari wrote: > > On Jun 9, 2013, at 12:47 AM, Fernando Gont wrote: > >> Hi, Warren, >> >> On 06/09/2013 01:58 AM, Warren Kumari wrote: >>> >>> And, while doing this (which I think I finally got to work right) I >>> discovered that I had an embarrassingly stupid bug in my initial >>> code -- I was only checking to make sure that I got *some* response >>> from the site, but not what the response was. This means that I was >>> counting sites that returned e.g. an ICMPv6DestUnreach as though they >>> worked. >> >> Question: Do you actually send the HTTP GET? > > Yup. > > I do the following: > 1: Send 'GET / HTTP/1.0\r\n\r\n' to port 80. > If the site responds, I classify it as "working" for IPv6 and continue. > > 2: Send 'GET / HTTP/1.0\r\n\r\n' to port 80, with an empty Destination Option (simply padding). > If the site sends back an ICMPv6DestUnreach or a ICMPv6TimeExceeded I classify it as not working with extension headers and abort. > If the site replies with a TCP payload I classify it as working with Extension Headers. > Otherwise I assume it is some other error and print the packet -- this hasn't happened. > >> >> If you're just probing with TCP SYN or ICMPv6 ech, you could use the >> tcp6 and icmp6 tools at: , >> which let you send fancy packets easily. >> >> If you're really sending the HTTP GET, then, if interested, I can add >> support to send arbitrary application-layer payloads to our tcp6 tool, >> such that this (and other) test are feasible. >> > > Yes please. > >> >> >>> The view of the world after fixing this (code below) is *very* >>> different -- one site (www.sapo.pt) works with extension headers, but >>> only sporadically - I'm guessing there is a LB and one node is >>> missing filters / there is ECMP and one path is missing filters. >> >> Only one? > > Only one site seems to support EH packets, and that only sporadically. I tried hitting it a few times (ten or so) and it only responded correctly twice. > >>>> working=0 >>>> for count in range (1,200): > ... b=sr1(IPv6(dst='www.sapo.pt')/IPv6ExtHdrDestOpt()/TCP(dport=80)/'GET / HTTP/1.0\r\n\r\n', timeout=2, verbose=0) > ... if b: > ... working +=1 >>>> working > 16 > > So, 16 in 200 connections got back a response. Maybe 12-13 machines behind a LB? I could fingerprint further, but…. > >> >> >>> This is 0.09% of tested sites. This is more like what I would have >>> expected -- I'm paranoid and so expect others to be as well, and to >>> discard / reject packets that don't start with [TCP/UDP/ICMP]. >> >> What about fragmentation support? > > Didn't test, but many sites drop fragments: > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 > > >> >> Thanks! >> > > Nah, thank you! > > W > >> Best regards, >> -- >> 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 Mon Jun 10 13:50:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0594221E8098 for ; Mon, 10 Jun 2013 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[AWL=0.761, 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 Gg2qQb2vqL3P for ; Mon, 10 Jun 2013 13:50:11 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AA321E8056 for ; Mon, 10 Jun 2013 13:50:08 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id CE9F61B401CE; Mon, 10 Jun 2013 16:50:06 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <51B62669.3030605@isi.edu> Date: Mon, 10 Jun 2013 16:50:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: Fernando Gont , "v6ops@ietf.org" , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:50:15 -0000 On Jun 10, 2013, at 3:18 PM, Joe Touch wrote: > Hi, Warren, >=20 > For sites where you got a response, can you let us know whether the = ICMP destination unreachable was from an intermediate router or the = final destination? They all came from intermediate routers - I removed the *.uol.com.br = site, where were all of the form: ### www.xpg.uol.com.br (2804:49c:319:430::292) sent an ICMPv6 = Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### ### www.automobile.it (2001:67c:2d0:4200::33) sent an ICMPv6 Destination = Unreachable from 2001:67c:2d0:114::2 ### ### www.automobile.fr (2001:67c:2d0:4200::30) sent an ICMPv6 Destination = Unreachable from 2001:67c:2d0:114::2 ### ### www.cms.gov (2607:f028:0:400:146:123:140:205) sent an ICMPv6 = Destination Unreachable from 2607:f028:0:80::4 ### ### www.clixboom.com (2001:1528:1:2100:250:56ff:fea1:2d17) sent an = ICMPv6 Destination Unreachable from 2001:1528:1:2100:250:56ff:fea1:2d17 = ### ### www.harvard.edu (2607:fb60:100:210::e6) sent an ICMPv6 Destination = Unreachable from 2607:fb60:0:1:1b::2 ### ### www.indosat.com (2407:0:1000:2::2) sent an ICMPv6 Destination = Unreachable from 2407::6 ### !!! www.ed.gov (2604:b300:ad02:1::4a54:db99) returned an ICMPv6 TTL = Exceeded from 2607:f758:2200::4 !!! ### www.medicare.gov (2607:f028:0:400:146:123:140:204) sent an ICMPv6 = Destination Unreachable from 2607:f028:0:80::4 ### ### www.mobile.de (2001:67c:2d0:4200::25) sent an ICMPv6 Destination = Unreachable from 2001:67c:2d0:110::2 ### ### www.mobile.ro (2001:67c:2d0:4200::24) sent an ICMPv6 Destination = Unreachable from 2001:67c:2d0:114::2 ### ### www.radardedescontos.com.br (2804:49c:319:430::359) sent an ICMPv6 = Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### ### www.ripe.net (2001:67c:2e8:22::c100:68b) sent an ICMPv6 Destination = Unreachable from 2001:7f8:1::a500:3333:2 ### ### www.tportal.hr (2a00:c30:fffd:2::2) sent an ICMPv6 Destination = Unreachable from 2a00:c30:b000::113 ### ### www.uolhost.com.br (2804:49c:319:430::358) sent an ICMPv6 = Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### ### www.turkcell.com.tr (2a02:4e0:101:1101::14) sent an ICMPv6 = Destination Unreachable from 2001:470:15:109::2 ### >=20 > Based on the info below, it's clear that the option you tested fails, = but not where or why. It could as easily be endpoint failure. It is being caused by router (and possibly, though unlikely LB / = firewall) filters. Letting unknown traffic into your network is just = asking for trouble, and so it is established practice to only allow = known and expected traffic in through your edge filters.=20 Some folk configure the filters to 'discard' the traffic (silent drop), = some to 'reject' it (ICMP Dest Unreachable, Communication with = destination administratively prohibited). Discard is often viewed as = friendlier, as it stops you sending streams of ICMP replies at spoofed = destinations. >=20 > And if the error is at the endpoints, then any solution that presumes = an endpoint fix could just as easily assume correcting this flaw=85 Assuming that the network operator wanted to accept the traffic=85. W >=20 > Joe >=20 > On 6/10/2013 12:09 PM, Warren Kumari wrote: >>=20 >> On Jun 9, 2013, at 12:47 AM, Fernando Gont = wrote: >>=20 >>> Hi, Warren, >>>=20 >>> On 06/09/2013 01:58 AM, Warren Kumari wrote: >>>>=20 >>>> And, while doing this (which I think I finally got to work right) I >>>> discovered that I had an embarrassingly stupid bug in my initial >>>> code -- I was only checking to make sure that I got *some* response >>>> from the site, but not what the response was. This means that I was >>>> counting sites that returned e.g. an ICMPv6DestUnreach as though = they >>>> worked. >>>=20 >>> Question: Do you actually send the HTTP GET? >>=20 >> Yup. >>=20 >> I do the following: >> 1: Send 'GET / HTTP/1.0\r\n\r\n' to port 80. >> If the site responds, I classify it as "working" for IPv6 and = continue. >>=20 >> 2: Send 'GET / HTTP/1.0\r\n\r\n' to port 80, with an empty = Destination Option (simply padding). >> If the site sends back an ICMPv6DestUnreach or a ICMPv6TimeExceeded = I classify it as not working with extension headers and abort. >> If the site replies with a TCP payload I classify it as working = with Extension Headers. >> Otherwise I assume it is some other error and print the packet -- = this hasn't happened. >>=20 >>>=20 >>> If you're just probing with TCP SYN or ICMPv6 ech, you could use the >>> tcp6 and icmp6 tools at: = , >>> which let you send fancy packets easily. >>>=20 >>> If you're really sending the HTTP GET, then, if interested, I can = add >>> support to send arbitrary application-layer payloads to our tcp6 = tool, >>> such that this (and other) test are feasible. >>>=20 >>=20 >> Yes please. >>=20 >>>=20 >>>=20 >>>> The view of the world after fixing this (code below) is *very* >>>> different -- one site (www.sapo.pt) works with extension headers, = but >>>> only sporadically - I'm guessing there is a LB and one node is >>>> missing filters / there is ECMP and one path is missing filters. >>>=20 >>> Only one? >>=20 >> Only one site seems to support EH packets, and that only = sporadically. I tried hitting it a few times (ten or so) and it only = responded correctly twice. >>=20 >>>>> working=3D0 >>>>> for count in range (1,200): >> ... = b=3Dsr1(IPv6(dst=3D'www.sapo.pt')/IPv6ExtHdrDestOpt()/TCP(dport=3D80)/'GET= / HTTP/1.0\r\n\r\n', timeout=3D2, verbose=3D0) >> ... if b: >> ... working +=3D1 >>>>> working >> 16 >>=20 >> So, 16 in 200 connections got back a response. Maybe 12-13 machines = behind a LB? I could fingerprint further, but=85. >>=20 >>>=20 >>>=20 >>>> This is 0.09% of tested sites. This is more like what I would have >>>> expected -- I'm paranoid and so expect others to be as well, and to >>>> discard / reject packets that don't start with [TCP/UDP/ICMP]. >>>=20 >>> What about fragmentation support? >>=20 >> Didn't test, but many sites drop fragments: >> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 >>=20 >>=20 >>>=20 >>> Thanks! >>>=20 >>=20 >> Nah, thank you! >>=20 >> W >>=20 >>> Best regards, >>> -- >>> 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 >=20 --=20 Eagles soar but a weasel will never get sucked into a jet engine=20 From touch@isi.edu Mon Jun 10 14:00:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5570921F9A33 for ; Mon, 10 Jun 2013 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.112 X-Spam-Level: X-Spam-Status: No, score=-103.112 tagged_above=-999 required=5 tests=[AWL=-0.513, 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 v1iluIpLtrG8 for ; Mon, 10 Jun 2013 14:00:50 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0621F8618 for ; Mon, 10 Jun 2013 14:00:50 -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 r5AKxtZ0006654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 13:59:55 -0700 (PDT) Message-ID: <51B63E3F.7080700@isi.edu> Date: Mon, 10 Jun 2013 13:59:43 -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: Warren Kumari References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , "v6ops@ietf.org" , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:00:56 -0000 On 6/10/2013 1:50 PM, Warren Kumari wrote: > > On Jun 10, 2013, at 3:18 PM, Joe Touch wrote: > >> Hi, Warren, >> >> For sites where you got a response, can you let us know whether the ICMP destination unreachable was from an intermediate router or the final destination? > > They all came from intermediate routers - I removed the *.uol.com.br site, where were all of the form: > ### www.xpg.uol.com.br (2804:49c:319:430::292) sent an ICMPv6 Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### > > ### www.automobile.it (2001:67c:2d0:4200::33) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:114::2 ### > ### www.automobile.fr (2001:67c:2d0:4200::30) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:114::2 ### > ### www.cms.gov (2607:f028:0:400:146:123:140:205) sent an ICMPv6 Destination Unreachable from 2607:f028:0:80::4 ### > ### www.clixboom.com (2001:1528:1:2100:250:56ff:fea1:2d17) sent an ICMPv6 Destination Unreachable from 2001:1528:1:2100:250:56ff:fea1:2d17 ### > ### www.harvard.edu (2607:fb60:100:210::e6) sent an ICMPv6 Destination Unreachable from 2607:fb60:0:1:1b::2 ### > ### www.indosat.com (2407:0:1000:2::2) sent an ICMPv6 Destination Unreachable from 2407::6 ### > !!! www.ed.gov (2604:b300:ad02:1::4a54:db99) returned an ICMPv6 TTL Exceeded from 2607:f758:2200::4 !!! > ### www.medicare.gov (2607:f028:0:400:146:123:140:204) sent an ICMPv6 Destination Unreachable from 2607:f028:0:80::4 ### > ### www.mobile.de (2001:67c:2d0:4200::25) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:110::2 ### > ### www.mobile.ro (2001:67c:2d0:4200::24) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:114::2 ### > ### www.radardedescontos.com.br (2804:49c:319:430::359) sent an ICMPv6 Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### > ### www.ripe.net (2001:67c:2e8:22::c100:68b) sent an ICMPv6 Destination Unreachable from 2001:7f8:1::a500:3333:2 ### > ### www.tportal.hr (2a00:c30:fffd:2::2) sent an ICMPv6 Destination Unreachable from 2a00:c30:b000::113 ### > ### www.uolhost.com.br (2804:49c:319:430::358) sent an ICMPv6 Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### > ### www.turkcell.com.tr (2a02:4e0:101:1101::14) sent an ICMPv6 Destination Unreachable from 2001:470:15:109::2 ### > >> >> Based on the info below, it's clear that the option you tested fails, but not where or why. It could as easily be endpoint failure. > > It is being caused by router (and possibly, though unlikely LB / > firewall) filters. Letting unknown traffic into your network is just > asking for trouble, and so it is established practice to only allow > known and expected traffic in through your edge filters. Sure, but existing defined end-host options are not "unknown traffic". ... >> And if the error is at the endpoints, then any solution that presumes an endpoint fix could just as easily assume correcting this flaw… > > Assuming that the network operator wanted to accept the traffic…. Seems like a "teachable moment". If network operators consider such options "unknown", it's time to inform them otherwise. Joe From cb.list6@gmail.com Mon Jun 10 15:18:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950DA21F8F6D for ; Mon, 10 Jun 2013 15:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 r-5Ja-TLcxHL for ; Mon, 10 Jun 2013 15:18:35 -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 BCED121F880F for ; Mon, 10 Jun 2013 15:18:34 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so5266331wes.38 for ; Mon, 10 Jun 2013 15:18: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=miQC6LXrSR3F5BVpNP24x6ujZ2YpCP0bOhPFKVH4PUo=; b=P4RsZkSes7ZXZDBCVyFgPhb2l3NVr539wMwAzOLzMpiGB304EOc/Kjkv9NEgymaBjk bNuI/QkBJBIQGKvC4CNdM111wkLzd7SHHgng7zUXyIjJ/I2CVVTUnKW6gln4iG8zvOq/ 74JUAAYW5cjs1/uSGSzxgX2cEjetb0tQVF03qCePvDONMGZac6jpeGlyYyLcZDgn3TJS AsFGu7CJudPyXkb0Fg9tlqxFkzQLB3BwGfR8ZokKyVJP1Bl9uMwIowPc+23cMoQ7QJBF /J1kd2bRfV0db4kegcGzcvZObD9ANOJ2EWWVIk3/oJESs7f0O9RdBpUVccQnk1Hpet8V UDUA== MIME-Version: 1.0 X-Received: by 10.194.84.74 with SMTP id w10mr6828149wjy.52.1370902713739; Mon, 10 Jun 2013 15:18:33 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 15:18:33 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 15:18:33 -0700 (PDT) In-Reply-To: <51B63E3F.7080700@isi.edu> References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> <51B63E3F.7080700@isi.edu> Date: Mon, 10 Jun 2013 15:18:33 -0700 Message-ID: From: "cb.list6" To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bf0ca0246335a04ded42924 Cc: Fernando Gont , IPv6 Ops WG , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:18:36 -0000 --047d7bf0ca0246335a04ded42924 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Jun 10, 2013 2:01 PM, "Joe Touch" wrote: > > > > On 6/10/2013 1:50 PM, Warren Kumari wrote: >> >> >> On Jun 10, 2013, at 3:18 PM, Joe Touch wrote: >> >>> Hi, Warren, >>> >>> For sites where you got a response, can you let us know whether the ICMP destination unreachable was from an intermediate router or the final destination? >> >> >> They all came from intermediate routers - I removed the *.uol.com.brsite= , where were all of the form: >> ### www.xpg.uol.com.br (2804:49c:319:430::292) sent an ICMPv6 Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### >> >> ### www.automobile.it (2001:67c:2d0:4200::33) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:114::2 ### >> ### www.automobile.fr (2001:67c:2d0:4200::30) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:114::2 ### >> ### www.cms.gov (2607:f028:0:400:146:123:140:205) sent an ICMPv6 Destination Unreachable from 2607:f028:0:80::4 ### >> ### www.clixboom.com (2001:1528:1:2100:250:56ff:fea1:2d17) sent an ICMPv6 Destination Unreachable from 2001:1528:1:2100:250:56ff:fea1:2d17 ### >> ### www.harvard.edu (2607:fb60:100:210::e6) sent an ICMPv6 Destination Unreachable from 2607:fb60:0:1:1b::2 ### >> ### www.indosat.com (2407:0:1000:2::2) sent an ICMPv6 Destination Unreachable from 2407::6 ### >> !!! www.ed.gov (2604:b300:ad02:1::4a54:db99) returned an ICMPv6 TTL Exceeded from 2607:f758:2200::4 !!! >> ### www.medicare.gov (2607:f028:0:400:146:123:140:204) sent an ICMPv6 Destination Unreachable from 2607:f028:0:80::4 ### >> ### www.mobile.de (2001:67c:2d0:4200::25) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:110::2 ### >> ### www.mobile.ro (2001:67c:2d0:4200::24) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:114::2 ### >> ### www.radardedescontos.com.br (2804:49c:319:430::359) sent an ICMPv6 Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### >> ### www.ripe.net (2001:67c:2e8:22::c100:68b) sent an ICMPv6 Destination Unreachable from 2001:7f8:1::a500:3333:2 ### >> ### www.tportal.hr (2a00:c30:fffd:2::2) sent an ICMPv6 Destination Unreachable from 2a00:c30:b000::113 ### >> ### www.uolhost.com.br (2804:49c:319:430::358) sent an ICMPv6 Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### >> ### www.turkcell.com.tr (2a02:4e0:101:1101::14) sent an ICMPv6 Destination Unreachable from 2001:470:15:109::2 ### >> >>> >>> Based on the info below, it's clear that the option you tested fails, but not where or why. It could as easily be endpoint failure. >> >> >> It is being caused by router (and possibly, though unlikely LB / >> firewall) filters. Letting unknown traffic into your network is just >> asking for trouble, and so it is established practice to only allow >> known and expected traffic in through your edge filters. > > > Sure, but existing defined end-host options are not "unknown traffic". > > ... > >>> And if the error is at the endpoints, then any solution that presumes an endpoint fix could just as easily assume correcting this flaw=85 >> >> >> Assuming that the network operator wanted to accept the traffic=85. > > > Seems like a "teachable moment". If network operators consider such options "unknown", it's time to inform them otherwise. > > Joe > I think Warren's data has shown that networks operators and gear implementers are seizing the momemt to teach the ietf that these packets types should be depricated to avoid future misunderstandings and to keep the standars relevant. The experiment with kinky EH is over. Take the results and move on CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7bf0ca0246335a04ded42924 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


    On Jun 10, 2013 2:01 PM, "Joe Touch" <touch@isi.edu> wrote:
    >
    >
    >
    > On 6/10/2013 1:50 PM, Warren Kumari wrote:
    >>
    >>
    >> On Jun 10, 2013, at 3:18 PM, Joe Touch <touch@isi.edu> wrote:
    >>
    >>> Hi, Warren,
    >>>
    >>> For sites where you got a response, can you let us know whethe= r the ICMP destination unreachable was from an intermediate router or the f= inal destination?
    >>
    >>
    >> They all came from intermediate routers - I removed the *.uol.com.br site, where were all of the form:
    >> ### www.xpg.uol.com.br (= 2804:49c:319:430::292) sent an ICMPv6 Destination Unreachable from 2001:12f= f:aaaa::37:737:2 ###
    >>
    >> ### www.automobile.it (20= 01:67c:2d0:4200::33) sent an ICMPv6 Destination Unreachable from 2001:67c:2= d0:114::2 ###
    >> ### www.automobile.fr (20= 01:67c:2d0:4200::30) sent an ICMPv6 Destination Unreachable from 2001:67c:2= d0:114::2 ###
    >> ### www.cms.gov (2607:f028:0:40= 0:146:123:140:205) sent an ICMPv6 Destination Unreachable from 2607:f028:0:= 80::4 ###
    >> ### www.clixboom.com (2001= :1528:1:2100:250:56ff:fea1:2d17) sent an ICMPv6 Destination Unreachable fro= m 2001:1528:1:2100:250:56ff:fea1:2d17 ###
    >> ### www.harvard.edu (2607:f= b60:100:210::e6) sent an ICMPv6 Destination Unreachable from 2607:fb60:0:1:= 1b::2 ###
    >> ### www.indosat.com (2407:0= :1000:2::2) sent an ICMPv6 Destination Unreachable from 2407::6 ###
    >> !!! www.ed.gov (2604:b300:ad02:1= ::4a54:db99) returned an ICMPv6 TTL Exceeded from 2607:f758:2200::4 !!!
    >> ### www.medicare.gov (2607= :f028:0:400:146:123:140:204) sent an ICMPv6 Destination Unreachable from 26= 07:f028:0:80::4 ###
    >> ### www.mobile.de (2001:67c:2= d0:4200::25) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:110::= 2 ###
    >> ### www.mobile.ro (2001:67c:2= d0:4200::24) sent an ICMPv6 Destination Unreachable from 2001:67c:2d0:114::= 2 ###
    >> ### www.radardedesc= ontos.com.br (2804:49c:319:430::359) sent an ICMPv6 Destination Unreach= able from 2001:12ff:aaaa::37:737:2 ###
    >> ### www.ripe.net (2001:67c:2e8= :22::c100:68b) sent an ICMPv6 Destination Unreachable from 2001:7f8:1::a500= :3333:2 ###
    >> ### www.tportal.hr (2a00:c30= :fffd:2::2) sent an ICMPv6 Destination Unreachable from 2a00:c30:b000::113 = ###
    >> ### www.uolhost.com.br (= 2804:49c:319:430::358) sent an ICMPv6 Destination Unreachable from 2001:12f= f:aaaa::37:737:2 ###
    >> ### www.turkcell.com.tr= (2a02:4e0:101:1101::14) sent an ICMPv6 Destination Unreachable from 2001:4= 70:15:109::2 ###
    >>
    >>>
    >>> Based on the info below, it's clear that the option you te= sted fails, but not where or why. It could as easily be endpoint failure. >>
    >>
    >> It is being caused by router (and possibly, though unlikely LB / >> firewall) filters. Letting unknown traffic into your network is ju= st
    >> asking for trouble, and so it is established practice to only allo= w
    >> known and expected traffic in through your edge filters.
    >
    >
    > Sure, but existing defined end-host options are not "unknown traf= fic".
    >
    > ...
    >
    >>> And if the error is at the endpoints, then any solution that p= resumes an endpoint fix could just as easily assume correcting this flaw=85=
    >>
    >>
    >> Assuming that the network operator wanted to accept the traffic=85= .
    >
    >
    > Seems like a "teachable moment". If network operators consid= er such options "unknown", it's time to inform them otherwise= .
    >
    > Joe
    >

    I think Warren's data has shown that networks operators = and gear implementers are seizing the momemt to teach the ietf that these p= ackets types should be depricated to avoid future misunderstandings and to = keep the standars relevant.

    The experiment with kinky EH is over.

    Take the results and move on

    CB

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

    --047d7bf0ca0246335a04ded42924-- From touch@isi.edu Mon Jun 10 15:25:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1121F99E7 for ; Mon, 10 Jun 2013 15:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.08 X-Spam-Level: X-Spam-Status: No, score=-103.08 tagged_above=-999 required=5 tests=[AWL=-0.481, 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 0m+2kMoosTuB for ; Mon, 10 Jun 2013 15:25:35 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 94D5F21F99DC for ; Mon, 10 Jun 2013 15:25:29 -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 r5AMORaL002147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 15:24:28 -0700 (PDT) Message-ID: <51B6520F.9050101@isi.edu> Date: Mon, 10 Jun 2013 15:24:15 -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: "cb.list6" References: <51B0F45A.6020406@gmail.com> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> <51B63E3F.7080700@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , IPv6 Ops WG , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:25:41 -0000 On 6/10/2013 3:18 PM, cb.list6 wrote: ... > I think Warren's data has shown that networks operators and gear > implementers are seizing the momemt to teach the ietf that these packets > types should be depricated to avoid future misunderstandings and to keep > the standars relevant. As with the rest of the Internet, what the operators will learn is that their lack of support for these extensions will force us to tunnel, which will kill their ability to see transport headers. Fine with me... Joe From joelja@bogus.com Mon Jun 10 15:49:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18BE21F93D2 for ; Mon, 10 Jun 2013 15:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 Q44-TW8uktQ2 for ; Mon, 10 Jun 2013 15:49:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BA21F9399 for ; Mon, 10 Jun 2013 15:49:50 -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 r5AMnB9R030028 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 22:49:16 GMT (envelope-from joelja@bogus.com) Message-ID: <51B657E2.7090205@bogus.com> Date: Tue, 11 Jun 2013 00:49:06 +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: Joe Touch , "cb.list6" References: <51B0F45A.6020406@gmail.com> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> <51B63E3F.7080700@isi.edu> <51B6520F.9050101@isi.edu> In-Reply-To: <51B6520F.9050101@isi.edu> 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 22:49:20 +0000 (UTC) Cc: Fernando Gont , IPv6 Ops WG , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:49:50 -0000 On 6/11/13 12:24 AM, Joe Touch wrote: > > > On 6/10/2013 3:18 PM, cb.list6 wrote: > ... >> I think Warren's data has shown that networks operators and gear >> implementers are seizing the momemt to teach the ietf that these packets >> types should be depricated to avoid future misunderstandings and to keep >> the standars relevant. > > As with the rest of the Internet, what the operators will learn is > that their lack of support for these extensions will force us to > tunnel, which will kill their ability to see transport headers. Fine > with me... Dumb network, smart endpoints oddly I'm not unreceptive to that. Remember I'm an end user though and I still need to see the transport header. > > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From touch@isi.edu Mon Jun 10 16:41:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2202A21F9701 for ; Mon, 10 Jun 2013 16:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.052 X-Spam-Level: X-Spam-Status: No, score=-103.052 tagged_above=-999 required=5 tests=[AWL=-0.453, 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 3J4-RcuQuM-8 for ; Mon, 10 Jun 2013 16:41:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 49FC421F9619 for ; Mon, 10 Jun 2013 16:41:19 -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 r5ANeRTG013179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 16:40:27 -0700 (PDT) Message-ID: <51B663DF.3080609@isi.edu> Date: Mon, 10 Jun 2013 16:40:15 -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: joel jaeggli References: <51B0F45A.6020406@gmail.com> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> <51B63E3F.7080700@isi.edu> <51B6520F.9050101@isi.edu> <51B657E2.7090205@bogus.com> In-Reply-To: <51B657E2.7090205@bogus.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: Fernando Gont , IPv6 Ops WG , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:41:25 -0000 On 6/10/2013 3:49 PM, joel jaeggli wrote: > On 6/11/13 12:24 AM, Joe Touch wrote: >> >> >> On 6/10/2013 3:18 PM, cb.list6 wrote: >> ... >>> I think Warren's data has shown that networks operators and gear >>> implementers are seizing the momemt to teach the ietf that these packets >>> types should be depricated to avoid future misunderstandings and to keep >>> the standars relevant. >> >> As with the rest of the Internet, what the operators will learn is >> that their lack of support for these extensions will force us to >> tunnel, which will kill their ability to see transport headers. Fine >> with me... > Dumb network, smart endpoints oddly I'm not unreceptive to that. > Remember I'm an end user though and I still need to see the transport > header. If you want to see the transport header, convince the router guys not to drop well-formed IPv6 packets just because it's "hard". Otherwise, I assure you the endpoints *will* tunnel - if the alternative is to have their packets dropped. Joe From touch@isi.edu Mon Jun 10 16:48:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ADB21F9050 for ; Mon, 10 Jun 2013 16:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-0.428, 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 6x1EWyFZjJYL for ; Mon, 10 Jun 2013 16:48:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id EF69121F8BC0 for ; Mon, 10 Jun 2013 16:48:47 -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 r5ANlcx0014755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 16:47:38 -0700 (PDT) Message-ID: <51B6658E.70303@isi.edu> Date: Mon, 10 Jun 2013 16:47: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: joel jaeggli References: <51B0F45A.6020406@gmail.com> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> <51B63E3F.7080700@isi.edu> <51B6520F.9050101@isi.edu> <51B657E2.7090205@bogus.com> In-Reply-To: <51B657E2.7090205@bogus.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: Fernando Gont , IPv6 Ops WG , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:48:54 -0000 One other point, below... On 6/10/2013 3:49 PM, joel jaeggli wrote: > On 6/11/13 12:24 AM, Joe Touch wrote: >> >> >> On 6/10/2013 3:18 PM, cb.list6 wrote: >> ... >>> I think Warren's data has shown that networks operators and gear >>> implementers are seizing the momemt to teach the ietf that these packets >>> types should be depricated to avoid future misunderstandings and to keep >>> the standars relevant. >> >> As with the rest of the Internet, what the operators will learn is >> that their lack of support for these extensions will force us to >> tunnel, which will kill their ability to see transport headers. Fine >> with me... > > Dumb network, smart endpoints oddly I'm not unreceptive to that. It's more than that. You think you're running a network, but I'll just start treating it like a link layer. Which means less opportunity for services for you (filtering, port-based forwarding, etc.), and pushes what you consider the "Internet" towards being irrelevant. I'm OK with that, though, too. Joe From marka@isc.org Mon Jun 10 17:13:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B94821F8613 for ; Mon, 10 Jun 2013 17:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_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 zOs9wAkGgd-b for ; Mon, 10 Jun 2013 17:13:32 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41421F81FF for ; Mon, 10 Jun 2013 17:13:32 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 3A567C9476; Tue, 11 Jun 2013 00:13:21 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1370909611; bh=rDDWIl7xjQoySM0krVGON2f0atpkCqxA1O5IpXZET/o=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Z9HXEKpY1S3srDjaYG8W+1/bOGym4gwDodCEaWYsEwVC/9oIHw6T+XQVIT8yrNxwY ALU0XTVP8pvUOY/40DMnGcZrmJ6Q4bDaEDdYOCmk4Q7FdBilrKGbgnfIMNl90UcqFg f3dlVwCepk087VVS6B5timjvB47Lhu+m3UxNqpDk= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 11 Jun 2013 00:13:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C0D48216C40; Tue, 11 Jun 2013 00:13:07 +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 D917D35B0B9C; Tue, 11 Jun 2013 10:13:03 +1000 (EST) To: "cb.list6" From: Mark Andrews References: <51B0F45A.6020406@gmail.com> <20130606.225854.41650275.sthaug@nethelp.no> <51B0FC4C.2020808@isi.edu> <20130606.233657.225564173.he@uninett.no> <51B10208.9060204@isi.edu> <51B13FCB.60107@joelhalpern.com> <1370578991.30963.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1370624846.64794.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B21F57.2000705@isi.edu> <1370647124.51536.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B26D6C.8050706@isi.edu> <1370649590.98588.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <58371F96-B0CC-4385-880D-CF13F005B9D8@kumari.net> <51B2C394.1080508@globis.net> <4BF0620A-DEAD-402A-B423-F744BD1BDC0C@kumari.net> <5666420F-9606-42B9-91FE-2EBAB4C937BA@kumari.net> <51B408EC.7000801@si6networks.com> <30D072E6-8481-4BF5-B2BA-09ABA7092ED9@kumari.net> <51B62669.3030605@isi.edu> <51B63E3F.7080700@isi.edu> In-reply-to: Your message of "Mon, 10 Jun 2013 15:18:33 -0700." Date: Tue, 11 Jun 2013 10:13:03 +1000 Message-Id: <20130611001303.D917D35B0B9C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Fernando Gont , IPv6 Ops WG , Ray Hunter Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 00:13:34 -0000 In message , "cb.list6" writes: > --===============5004857423208636513== > Content-Type: multipart/alternative; boundary=047d7bf0ca0246335a04ded42924 > > --047d7bf0ca0246335a04ded42924 > Content-Type: text/plain; charset=windows-1252 > Content-Transfer-Encoding: quoted-printable > > On Jun 10, 2013 2:01 PM, "Joe Touch" wrote: > > > > > > > > On 6/10/2013 1:50 PM, Warren Kumari wrote: > >> > >> > >> On Jun 10, 2013, at 3:18 PM, Joe Touch wrote: > >> > >>> Hi, Warren, > >>> > >>> For sites where you got a response, can you let us know whether the > ICMP destination unreachable was from an intermediate router or the final > destination? > >> > >> > >> They all came from intermediate routers - I removed the *.uol.com.brsite= > , where were all of the form: > >> ### www.xpg.uol.com.br (2804:49c:319:430::292) sent an ICMPv6 > Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### > >> > >> ### www.automobile.it (2001:67c:2d0:4200::33) sent an ICMPv6 Destination > Unreachable from 2001:67c:2d0:114::2 ### > >> ### www.automobile.fr (2001:67c:2d0:4200::30) sent an ICMPv6 Destination > Unreachable from 2001:67c:2d0:114::2 ### > >> ### www.cms.gov (2607:f028:0:400:146:123:140:205) sent an ICMPv6 > Destination Unreachable from 2607:f028:0:80::4 ### > >> ### www.clixboom.com (2001:1528:1:2100:250:56ff:fea1:2d17) sent an > ICMPv6 Destination Unreachable from 2001:1528:1:2100:250:56ff:fea1:2d17 ### > >> ### www.harvard.edu (2607:fb60:100:210::e6) sent an ICMPv6 Destination > Unreachable from 2607:fb60:0:1:1b::2 ### > >> ### www.indosat.com (2407:0:1000:2::2) sent an ICMPv6 Destination > Unreachable from 2407::6 ### > >> !!! www.ed.gov (2604:b300:ad02:1::4a54:db99) returned an ICMPv6 TTL > Exceeded from 2607:f758:2200::4 !!! > >> ### www.medicare.gov (2607:f028:0:400:146:123:140:204) sent an ICMPv6 > Destination Unreachable from 2607:f028:0:80::4 ### > >> ### www.mobile.de (2001:67c:2d0:4200::25) sent an ICMPv6 Destination > Unreachable from 2001:67c:2d0:110::2 ### > >> ### www.mobile.ro (2001:67c:2d0:4200::24) sent an ICMPv6 Destination > Unreachable from 2001:67c:2d0:114::2 ### > >> ### www.radardedescontos.com.br (2804:49c:319:430::359) sent an ICMPv6 > Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### > >> ### www.ripe.net (2001:67c:2e8:22::c100:68b) sent an ICMPv6 Destination > Unreachable from 2001:7f8:1::a500:3333:2 ### > >> ### www.tportal.hr (2a00:c30:fffd:2::2) sent an ICMPv6 Destination > Unreachable from 2a00:c30:b000::113 ### > >> ### www.uolhost.com.br (2804:49c:319:430::358) sent an ICMPv6 > Destination Unreachable from 2001:12ff:aaaa::37:737:2 ### > >> ### www.turkcell.com.tr (2a02:4e0:101:1101::14) sent an ICMPv6 > Destination Unreachable from 2001:470:15:109::2 ### > >> > >>> > >>> Based on the info below, it's clear that the option you tested fails, > but not where or why. It could as easily be endpoint failure. > >> > >> > >> It is being caused by router (and possibly, though unlikely LB / > >> firewall) filters. Letting unknown traffic into your network is just > >> asking for trouble, and so it is established practice to only allow > >> known and expected traffic in through your edge filters. > > > > > > Sure, but existing defined end-host options are not "unknown traffic". > > > > ... > > > >>> And if the error is at the endpoints, then any solution that presumes > an endpoint fix could just as easily assume correcting this flaw=85 > >> > >> > >> Assuming that the network operator wanted to accept the traffic=85. > > > > > > Seems like a "teachable moment". If network operators consider such > options "unknown", it's time to inform them otherwise. > > > > Joe > > > > I think Warren's data has shown that networks operators and gear > implementers are seizing the momemt to teach the ietf that these packets > types should be depricated to avoid future misunderstandings and to keep > the standars relevant. > > The experiment with kinky EH is over. > > Take the results and move on > > CB > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > No. Equipment vendors take whatever shortcuts they think they can get away with regardless of the impact they have because no one calls them to account for it. Other vendors then need to work around the breakages they cause. As a DNS vendor I need to work around firewalls that think all DNS/UDP packets are all <= 512 bytes of payload. I need to work around firewall that drop fragmented packets. I need to work around firewalls that drop ICMP packets. I need to work around firewalls/servers that drop EDNS packets. I need to work around firewalls/servers that drop unknown query types. I need to work around firewalls/servers that refuse to pass/answer what should be known query types. True routers are quite able to pass fragmented UDP extend DNS packets. Oh goolly gee, this packet is fragmented. The poor defenceless host can't be allowed to see this naughty packet it might hurt itself. This is despite the same boxes running exposed to the raw internet fine elsewhere. 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 Mon Jun 10 19:21:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A4C21F9953 for ; Mon, 10 Jun 2013 19:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRPK3bzeD-RR for ; Mon, 10 Jun 2013 19:21:23 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CFE5421F9950 for ; Mon, 10 Jun 2013 19:21:21 -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 1UmECx-0006Ab-5g; Tue, 11 Jun 2013 04:21:15 +0200 Message-ID: <51B5EC5B.9050601@si6networks.com> Date: Mon, 10 Jun 2013 17:10: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: Arturo Servin References: <51B2BB07.2040208@gmail.com> <51B45718.7030907@inex.ie> <51B5135D.30203@gmail.com> In-Reply-To: <51B5135D.30203@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:21:23 -0000 On 06/10/2013 01:44 AM, Arturo Servin wrote: > Nick, > > About IPv6 Security? > > There is one in opsec: > > http://tools.ietf.org/html/draft-ietf-opsec-v6-02 There are *many* in opsec -- all of which the ITU document apparently ignored. 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 Mon Jun 10 19:21:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: "cb.list6" To: Fernando Gont Content-Type: multipart/alternative; boundary=089e01184dd4eada1004ded86549 Cc: IPv6 Ops WG , 6man@ietf.org Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:34:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c248f0a9d73004ded8b8bf Cc: Fernando Gont , IPv6 Ops WG , 6man@ietf.org Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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" 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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: From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8f642b58e5b7da04ded941e3 Cc: Fernando Gont , IPv6 Ops WG , 6man@ietf.org Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 internet-drafts@ietf.org Tue Jun 11 02:12:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878D021F86D5; Tue, 11 Jun 2013 02:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, 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 y32IhhYm5T5r; Tue, 11 Jun 2013 02:12:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D15D21F8916; Tue, 11 Jun 2013 02:12:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p1 Message-ID: <20130611091218.19167.3867.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2013 02:12:18 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:12:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobi= le Devices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-04.txt Pages : 17 Date : 2013-06-11 Abstract: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jared@puck.nether.net Tue Jun 11 02:50:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 fernando@gont.com.ar Tue Jun 11 05:42:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 nalini.elkins@insidethestack.com Tue Jun 11 05:57:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FBA21F998B 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.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.116, 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 H6ufCdLl78JK for ; Tue, 11 Jun 2013 05:56:56 -0700 (PDT) Received: from nm12.access.bullet.mail.mud.yahoo.com (nm12.access.bullet.mail.mud.yahoo.com [66.94.237.213]) by ietfa.amsl.com (Postfix) with ESMTP id 2A33521F9983 for ; Tue, 11 Jun 2013 05:56:56 -0700 (PDT) Received: from [66.94.237.200] by nm12.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 12:56:55 -0000 Received: from [66.94.237.117] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 12:56:55 -0000 Received: from [127.0.0.1] by omp1022.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 12:56:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 144679.68939.bm@omp1022.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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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 Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDAF21F9A00 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.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.383, 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 lCIGO8wwrLir for ; Tue, 11 Jun 2013 08:37:15 -0700 (PDT) Received: from nm18-vm0.access.bullet.mail.sp2.yahoo.com (nm18-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0214821F99BD for ; Tue, 11 Jun 2013 08:37:14 -0700 (PDT) Received: from [98.139.44.100] by nm18.access.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jun 2013 15:37:14 -0000 Received: from [98.139.44.71] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jun 2013 15:37:14 -0000 Received: from [127.0.0.1] by omp1008.access.mail.sp2.yahoo.com with NNFMP; 11 Jun 2013 15:37:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 240242.84437.bm@omp1008.access.mail.sp2.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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C0921F965B 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.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, 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 PcAU9cFHQjCD for ; Tue, 11 Jun 2013 08:45:02 -0700 (PDT) Received: from nm9.access.bullet.mail.mud.yahoo.com (nm9.access.bullet.mail.mud.yahoo.com [66.94.237.210]) by ietfa.amsl.com (Postfix) with ESMTP id AED0921F97E6 for ; Tue, 11 Jun 2013 08:45:01 -0700 (PDT) Received: from [66.94.237.196] by nm9.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:45:01 -0000 Received: from [66.94.237.104] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:45:01 -0000 Received: from [127.0.0.1] by omp1009.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:45:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 404087.75274.bm@omp1009.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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 nick@inex.ie Tue Jun 11 08:45:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CEC21F994A for ; Tue, 11 Jun 2013 08:45:43 -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 19Q7YB0JnYiv for ; Tue, 11 Jun 2013 08:45:42 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2847521F996C for ; Tue, 11 Jun 2013 08:45:40 -0700 (PDT) X-Envelope-To: Received: from pancake.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r5BFjTGv030029 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 11 Jun 2013 16:45:29 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <51B74619.5010602@inex.ie> Date: Tue, 11 Jun 2013 16:45:29 +0100 From: Nick Hilliard 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: v6ops@ietf.org 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> In-Reply-To: X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:45:43 -0000 On 11/06/2013 16:17, Randy Bush wrote: >> 2008? RH0? >> Dudes, have we not moved beyond this? > > Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension Header(64), ext_hd=0 > > welcome to the operational internet I had a look at the ipfw2 code yesterday. In fact it handles extension headers in the kernel code, but I have no idea how you might configure this from userland because it sure as hell ain't documented. Best wishes to anyone who can figure this out. Please document it somewhere if you figure it. EHs are supported on OpenBSD PF, but not on the version that ships with freebsd. The configuration mechanism for this is fine. linux iptables supports EHs, and is as easy to configure from the command line as any other iptables command (that is not a compliment, btw). Cisco ASA also supports extension headers and only allows frag and HBH by default - everything else is dropped. Despite the documentation on the cisco web site, I eventually figured out how to change this behaviour. Apparently, you need to configure up a policy map of type "inspect ipv6", then hook that into whatever service inspection profile you're using for that traffic. In other words, this forces packets with EHs to run through the PIXOS inspection engine which is lulzerrifically slow, and can be used as a simple denial of service mechanism. I didn't look at anything else because this all made me a sad bunny and I had real work to do. Nick From warren@kumari.net Tue Jun 11 09:15:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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 Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 brian.e.carpenter@gmail.com Tue Jun 11 13:32:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216E021F9A27 for ; Tue, 11 Jun 2013 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 9nOv-YMIIcrG for ; Tue, 11 Jun 2013 13:32:13 -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 5015921F9A21 for ; Tue, 11 Jun 2013 13:32:13 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so8993574pdi.25 for ; Tue, 11 Jun 2013 13:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EjaVxmhcAmdfYBQB1ZelGj5QXFdRgpmk3AbhXw7olis=; b=QBo0HbkGdZhKruSSrjfwxvqJ9Y5TeGBOuZhKMxoy9Pg9YQwgQcjy5p3kLptu4f+Wnh 7X3SfTsZjv5m1lgZZtKjH8jheAhSPWQgcLn2xJL88WrBROA+ZPcoOcu+RF6MtD7ugYkA rguHqF60aN1jO9zGzguwg+8VCArYnQheBWDsT+DRGTcBMeOfvOUEFJau9oXxZKQFdN6/ BdKmJOCIZDfqtuSYrSk/jJs6zrwXeWlP6E8gHEj3jJ4EEKtYAIGbi6ZmyhTxdBnd1K61 cvbnrFUgU5c5NiEWc+Av50ffcBsVn9o3/JC/+jNwGEqSm5TAwO/bDyClRuGw3CU7LCOO vIzw== X-Received: by 10.69.2.228 with SMTP id br4mr16334979pbd.91.1370982733149; Tue, 11 Jun 2013 13:32:13 -0700 (PDT) Received: from [192.168.1.2] (13.162.252.27.dyn.cust.vf.net.nz. [27.252.162.13]) by mx.google.com with ESMTPSA id ig4sm15992913pbc.18.2013.06.11.13.32.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Jun 2013 13:32:12 -0700 (PDT) Message-ID: <51B7894E.6080203@gmail.com> Date: Wed, 12 Jun 2013 08:32:14 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard 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> <51B74619.5010602@inex.ie> In-Reply-To: <51B74619.5010602@inex.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:32:19 -0000 On 12/06/2013 03:45, Nick Hilliard wrote: > EHs are supported on OpenBSD PF, but not on the version that ships with > freebsd. The configuration mechanism for this is fine. just FYI, I'm in touch with Bjoern Zeeb, one of the FreeBSD maintainers, on this topic. The next version of draft-ietf-6man-ext-transmit will take account of his comments. From sander@steffann.nl Tue Jun 11 16:59:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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> 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 touch@isi.edu Wed Jun 12 10:45:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Cc: 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) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 fgont@si6networks.com Wed Jun 12 10:47:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5411E8101 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 s231WLpxMluV 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 06F3D11E8104 for ; Wed, 12 Jun 2013 10:49:10 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 90AFE609F9 for ; 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 6207260834 for ; 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 touch@isi.edu Wed Jun 12 10:59:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Cc: Fernando Gont , 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) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:59:41 -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 gert@space.net Wed Jun 12 11:30:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4FD11E80CC 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: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 ieFPH+PDAD8j 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 09FCB21F960D for ; 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 461BE60A15 for ; 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 2BD26609F9 for ; 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 kre@munnari.OZ.AU Wed Jun 12 11:46:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 touch@isi.edu Wed Jun 12 12:56:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A1111E80F0 for ; Wed, 12 Jun 2013 13:40:25 -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 DwX-SuyAlMAc for ; Wed, 12 Jun 2013 13:40:25 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1F11E8108 for ; 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 7C4BA60863 for ; 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 658A260834 for ; 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:40:25 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: [v6ops] Discussion about header chains (was Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066A111E8110 for ; Wed, 12 Jun 2013 15:08:06 -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 PiGm2guaYVgP for ; Wed, 12 Jun 2013 15:08:05 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 32DA711E8115 for ; Wed, 12 Jun 2013 15:07:52 -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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:08:06 -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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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> Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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\)) 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, fgont@si6networks.com Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 touch@isi.edu Wed Jun 12 17:00:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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> 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 Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 Subject: Re: [v6ops] Discussion about header chains (was Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 prvs=7873e4bb42=scott.mansfield@ericsson.com Mon Jun 10 04:04:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AAD21F88D8 for ; Mon, 10 Jun 2013 04:04:03 -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 KmyR+NeI5VjF for ; Mon, 10 Jun 2013 04:03:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0628421F86C0 for ; Mon, 10 Jun 2013 04:03:55 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-02-51b5b29bef22 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6E.1F.17537.B92B5B15; Mon, 10 Jun 2013 13:03:55 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 07:03:53 -0400 From: Scott Mansfield To: Fernando Gont , "Chip Sharp (chsharp)" Thread-Topic: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: Ac5jYIPck0d+2CUNT3Sp/Yo0Bb4r3gAFgdfAACwcDIAAOaFYgAARJZWAAAEtJwAACHIDgAACnyaAAABh5gAAEN9BYA== Date: Mon, 10 Jun 2013 11:03:52 +0000 Message-ID: References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> In-Reply-To: <51B50594.7040303@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPuO7sTVsDDc4el7GYc6uL1eLJqjds FhfW/2KxOH1sL7MDi8eU3xtZPXbOusvusWTJTyaPD4d62ANYorhtkhJLyoIz0/P07RK4M+5t qi5oEq9ofz+LqYFxnVAXIyeHhICJROfffiYIW0ziwr31bF2MXBxCAkcZJW7+ns0K4SxnlNiz 9wYrSBUbUMfWXdMZQWwRgXCJQ5f3soHYzAK+Et+O3QaLCwvkSqxdMJMdoiZPYuOjWcwQdpbE re/PwGpYBFQlbm1cyQJi8wL19n5+xgKx7DmzROeWVWAncQroS3Ttfw9WxAh03vdTa5gglolL 3HoyH+psAYkle84zQ9iiEi8f/2OFsJUlvs95xAJRryOxYPcnqEO1JZYtfM0MsVhQ4uTMJywT GMVmIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmSwiREYUcck2HR3MO55aXmIUZqDRUmcV413 caCQQHpiSWp2ampBalF8UWlOavEhRiYOThDBJdXA2LBcLtk2TmxHg1fBzkPbDWZ+P/i/oXFV m98pOf9ePeXdOdX7GDqSP82Ylf7umP63yz2Np6PsRJ8q5DnPnlb1Xpyn6Y/JhwNcFRfKP4QK zGf2VPVZbyn7Nyb+pE6R8YyN3/w2r9Nc/nLd33Mdz7a+FXyzS9R+0sfjvxhTLugLTNjWnlrS 53fWQ4mlOCPRUIu5qDgRAIjeZ0h7AgAA X-Mailman-Approved-At: Thu, 13 Jun 2013 01:05:57 -0700 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:04:04 -0000 A couple of things... 1) ISOC is a sector member, therefore they can submit comments. 2) The ITU-T send the document to the IETF for comment. Therefore, the IET= F can either liaise comments. 3) Any individual contributor to the IETF talk to a ISOC to have ISOC submi= t comments on their behalf -- but then ISOC (obviously) needs to agree with= the comments.=20 4) Any other ITU-T member can submit comments as well, so If you know a sec= tor member that agrees with your concerns about the liaised document, then = the AAP comments can be submitted that way. Now this is just my opinion.... If you aren't a Sector Member, it would be better to have a sector member s= ubmit your comments especially if they can be relied upon to participate in= the any review/explanation of the comments. This is an opportunity to provide input to the ITU-T security work. The do= cument already has some Last Call comments, so the document has to go throu= gh an "additional review", but that process is different than doing another= last call as would be done in the IETF. During Additional Review, only co= mments on the modified sections of the document are allowed. Bottom line is, the ITU-T sent a document for review, we can liaise comment= s that the Sec AD's and WG Chairs agree to, or a Sector member of the ITU-T= can submit comments. We have until Wed Jun 12 to submit AAP comments. Chip, on your point, I agree that this isn't the best indication of true co= llaborative work, but it is what we have. So my suggestion is that if we h= ave anything of substance, we should send in AAP comments from a sector mem= ber. Regards, -scott. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: Sunday, June 09, 2013 6:46 PM To: Chip Sharp (chsharp) Cc: Tom Taylor; v6ops@ietf.org; Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical secur= ity guideline on deploying IPv6 On 06/10/2013 12:34 AM, Chip Sharp (chsharp) wrote: > My $.02, Sending a liaison at the end of the process, when the SG is=20 > about to send a document into the approval process is not indicative=20 > of collaboration. It's hard to collaborate when the rules are not clear. -- At the very least= , I'd have expected that it was straightforward who we were supposed to sen= d our feedback to, if it was possible to have public discussion of the feed= back, etc > Also, only ITU-T Members can submit comments during AAP. So the > Rapporteurs are not obligated to consider comments sent to them by=20 > non-Members. ISOC is a Sector Member. Does that mean that anyone belonging to an ISOC chapter can submit? Or.. what are the requirements? Are there "ISOC representatives" at ITU? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From prvs=78749e5f6f=scott.mansfield@ericsson.com Tue Jun 11 06:41:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9D021F99A5 for ; Tue, 11 Jun 2013 06:41:53 -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 pt3YYCf0Wlq1 for ; Tue, 11 Jun 2013 06:41:47 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BBAF021F99A1 for ; Tue, 11 Jun 2013 06:41:47 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-0c-51b7291a8013 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D7.B7.17537.A1927B15; Tue, 11 Jun 2013 15:41:47 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 09:41:46 -0400 From: Scott Mansfield To: Fernando Gont , Arturo Servin Thread-Topic: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: Ac5jYIPck0d+2CUNT3Sp/Yo0Bb4r3gAFgdfAACwcDIAAPWcWAABLcmuKABe8HKA= Date: Tue, 11 Jun 2013 13:41:45 +0000 Message-ID: References: <51B2BB07.2040208@gmail.com> <51B45718.7030907@inex.ie> <51B5135D.30203@gmail.com> <51B5EC5B.9050601@si6networks.com> In-Reply-To: <51B5EC5B.9050601@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPiK605vZAg+kfmSxu7TrOZvFk1Rs2 i5WXDzFZnD62l9mBxWPnrLvsHkuW/GTy+HdjPrPHh0M97AEsUdw2SYklZcGZ6Xn6dgncGUfn bmIqOMJWsfz6a6YGxgWsXYycHBICJhL3t5xhg7DFJC7cWw9kc3EICRxllLg5YzcLhLOcUeLY 5t3MIFVsQB1bd01nBLFFBEIk9lx6xQJiMws4S2xqnAc2VVggV2LtgpnsEDV5EhsfzWKGsP0k Pl2cC1TDwcEioCrxrK8AJMwr4CvxYf0+qMXHGSXOHmgFm88poC+xbu9SsF5GoOu+n1rDBLFL XOLWk/lMEFcLSCzZc54ZwhaVePn4H9RnyhJLnuyHuk1HYsHuT2wQtrbEsoWvmSEWC0qcnPmE ZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDYxAiPqmASb7g7GPS8tDzFKc7AoifOq 8S4OFBJITyxJzU5NLUgtii8qzUktPsTIxMEJIrikGhjDLT39tq2WWBe/KY3zQND0dG43vUtP Tu+fPJP7eSD/zuZUdcY3LNuSH70Ou8VwOVR0mnqpuF3bnqrPJ6S2sD88uZm1a3Lx31+HvvWt EWAJLeKt3eXyInv+mhdnPwVe4DYPOG7JqmO8dOkV0RDJMLVNj0NurKqefergv4qwX9XzJi2X XNn3a6WvEktxRqKhFnNRcSIAldsMRnsCAAA= X-Mailman-Approved-At: Thu, 13 Jun 2013 01:05:57 -0700 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:41:53 -0000 Liaising a list back would be interesting. If you have a list, I could cre= ate a liaison. Regards, -scott. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: Monday, June 10, 2013 11:10 AM To: Arturo Servin Cc: Nick Hilliard; v6ops@ietf.org; Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical secur= ity guideline on deploying IPv6 On 06/10/2013 01:44 AM, Arturo Servin wrote: > Nick, >=20 > About IPv6 Security? >=20 > There is one in opsec: >=20 > http://tools.ietf.org/html/draft-ietf-opsec-v6-02 There are *many* in opsec -- all of which the ITU document apparently ignor= ed. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From hansvelez@gmail.com Tue Jun 11 22:49:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101E921F9C07 for ; Tue, 11 Jun 2013 22:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ-dK+VAYMNk for ; Tue, 11 Jun 2013 22:49:46 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1567121F9AA2 for ; Tue, 11 Jun 2013 22:49:45 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so6621385wes.29 for ; Tue, 11 Jun 2013 22:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Q1YREYSo2H+Z1MDl3XqUaW2I6cf9N5wD9Z2+LnPictQ=; b=raIUbAZ9dxBF6cra87Hc1ZOXXU1mVmwkujaGKO0VOpHognrHJS3HfzJkt4k0gLEeWB kTPxTXRP78dcPs6lTYiK+r3IKB/HY6ZsGFDuXb94dHGbTTvlAeuZ8oKCh8mK/z/elckZ Nlanz9pfJLDgmYQrlgGZrLBZTdvjKKYBTHuT4DiITNy/SpOrUrv5gy1FA3YhpCC8W0ws 4VVRsRMx81IIHcqEMPpXEUBGgmVJmBbhvQildHsz73hXvjeljAWI4M4CD93SHT5zHte1 KYLLJvPpZ2IOaAizQ4kTQmpl16ivImMLkO40LdzK/P0H5XvPGLR85mBl2Rr3sRNRUTCw aL9w== X-Received: by 10.194.176.41 with SMTP id cf9mr10464651wjc.66.1371016185261; Tue, 11 Jun 2013 22:49:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.42.134 with HTTP; Tue, 11 Jun 2013 22:49:24 -0700 (PDT) From: =?ISO-8859-1?Q?Hans_V=E8lez?= Date: Wed, 12 Jun 2013 00:49:24 -0500 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=089e013d1022b4358004deee9432 X-Mailman-Approved-At: Thu, 13 Jun 2013 01:05:57 -0700 Subject: [v6ops] IPv6 Operational Guidelines for DC draft-lopez-v6ops-dc-ipv6-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 05:49:47 -0000 --089e013d1022b4358004deee9432 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi authors, I found it very good compilation that lead so far on the draft, the issues are quite aligned with most experiences we have in the field of Data center and virtualization. I would refer to points: *2.3.2 EXTENDED DUAL STACK OS / HYPERVISORS* This is important since the growth of virtualized resources in data centers, since this increases the number of hypervisors in the same way also creating a complex management state that extends to the same security level, creating a point where IT managers will have a space to develop security plans that go hand in hand with the implementation of IPv6 hypervisor level, these schemes virtualization security quite large areas that are called *Virtual Security* where there are already several manufacturers have developed products that are designed to address these issues. *3.2 MANAGEMENT SYSTEMS AND APPLICATIONS.* Just put in the opinion of the authors this contribution since it is a perception more about what we have been working in the area of data centers and virtualization. In schemes where multiple data centers interconnections live under their geographical separation is given to our perception a good practice to have OBB network schemes (out of band), which may enable an autonomous and safe for the management of data centers as entities belong to a cloud, which is also considered the deployment of IPv6 for thes part. Thank you very much and good work. --=20 Hans V=E8lez S. Medellin - Antioquia. --089e013d1022b4358004deee9432 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi authors,
    I found it very good compilatio= n that lead so far on the draft, the issues are quite aligned with most exp= eriences we have in the field of Data center and virtualization.

    I would refer to points:

    2.3.2 E= XTENDED DUAL STACK =A0OS / HYPERVISORS

    This is= important since the growth of virtualized resources in data centers, since= this increases the number of hypervisors in the same way also creating a c= omplex management state that extends to the same security level, creating a= point where IT managers will have a space to develop security plans that g= o hand in hand with the implementation of IPv6 hypervisor level, these sche= mes virtualization security quite large areas that are called Virtual= Security where there are already several manufacturers have develo= ped products that are designed to address these issues.

    3.2 MANAGEMENT SYSTEMS AND APPLICATIONS.

    Just put in the opinion of the authors this contribution = since it is a perception more about what we have been working in the area o= f data centers and virtualization. In schemes where multiple data centers i= nterconnections live under their geographical separation is given to our pe= rception a good practice to have OBB network schemes (out of band), which m= ay enable an autonomous and safe for the management of data centers as enti= ties belong to a cloud,=A0which is also considered the deployment of IPv6 f= or thes part.


    Thank you very much and good work.
    =

    --
    Hans V=E8lez S.
    Medellin - Antioquia.
    --089e013d1022b4358004deee9432-- From randy@psg.com Thu Jun 13 01:18:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 nick@inex.ie Thu Jun 13 03:57:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1994821F99F0 for ; Thu, 13 Jun 2013 03:57:42 -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 fuHFKfCP4C7N for ; Thu, 13 Jun 2013 03:57:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6022C21F9976 for ; Thu, 13 Jun 2013 03:57:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from pancake.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r5DAvZoA043390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 11:57:35 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <51B9A59F.1060109@inex.ie> Date: Thu, 13 Jun 2013 11:57:35 +0100 From: Nick Hilliard 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: Scott Mansfield References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 10:57:42 -0000 On 10/06/2013 12:03, Scott Mansfield wrote: > During Additional Review, only comments on the modified sections of the > document are allowed. Scott, This document is of sufficiently poor quality that in order to make it useful, it would need to be substantially rewritten by someone with a significantly better understanding of both ipv6 and security. I don't think that its problems can be rectified by submitting limited comments on prespecified sections, and if the IETF does this, it could be construed as giving its imprimatur to the document. I believe that this could reflect badly on the IETF and on that basis I think it would be a bad idea for the IETF to submit comments. Nick From fgont@si6networks.com Thu Jun 13 04:58:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B921F9A3A for ; Thu, 13 Jun 2013 04:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 Cb1JcRTyVNiU for ; Thu, 13 Jun 2013 04:58: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 0AD6D21F9A39 for ; Thu, 13 Jun 2013 04:58:37 -0700 (PDT) Received: from pd95c600c.dip0.t-ipconnect.de ([217.92.96.12] helo=[192.168.0.57]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Un6Ak-0000VL-8M; Thu, 13 Jun 2013 13:58:34 +0200 Message-ID: <51B9B3AF.8080009@si6networks.com> Date: Thu, 13 Jun 2013 13:57:35 +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: Nick Hilliard References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> In-Reply-To: <51B9A59F.1060109@inex.ie> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 11:58:38 -0000 On 06/13/2013 12:57 PM, Nick Hilliard wrote: > On 10/06/2013 12:03, Scott Mansfield wrote: >> During Additional Review, only comments on the modified sections of the >> document are allowed. > > Scott, > > This document is of sufficiently poor quality that in order to make it > useful, it would need to be substantially rewritten by someone with a > significantly better understanding of both ipv6 and security. I don't > think that its problems can be rectified by submitting limited comments on > prespecified sections, and if the IETF does this, it could be construed as > giving its imprimatur to the document. I believe that this could reflect > badly on the IETF and on that basis I think it would be a bad idea for the > IETF to submit comments. +1 (although I have no idea if the problem is who the document was written by, whether they didn't do the homework to see what e.g. the IETF has been doing in this area, both, or what). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From prvs=58769aba3b=scott.mansfield@ericsson.com Thu Jun 13 06:04:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B77621F9385 for ; Thu, 13 Jun 2013 06:04:04 -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 yZGS3Vb8uaOi for ; Thu, 13 Jun 2013 06:03:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C535021F9732 for ; Thu, 13 Jun 2013 06:03:45 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-95-51b9c331bf72 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E8.48.05617.133C9B15; Thu, 13 Jun 2013 15:03:45 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Thu, 13 Jun 2013 09:03:44 -0400 From: Scott Mansfield To: Fernando Gont , Nick Hilliard Thread-Topic: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: Ac5jYIPck0d+2CUNT3Sp/Yo0Bb4r3gAFgdfAACwcDIAAOaFYgAARJZWAAAEtJwAACHIDgAACnyaAAABh5gAAEN9BYACfkGeAAAIYcYAABh7coA== Date: Thu, 13 Jun 2013 13:03:43 +0000 Message-ID: References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> In-Reply-To: <51B9B3AF.8080009@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXRPrK7h4Z2BBoeXC1s8WfWGzWLl5UNM FqeP7WV2YPZYsuQnk8e/G/OZPT4c6mEPYI7itklKLCkLzkzP07dL4M74uce54BRvxa3nS9ga GN9zdTFyckgImEgsf9DJBGGLSVy4t56ti5GLQ0jgKKPE7xv3GSGc5YwSm5fOYwWpYgPq2Lpr OiOILSLgLnFlxgaWLkYODmYBVYnZf/hBwsICuRJrF8xkhyjJk9j4aBYzSImIQJ3E5TMGIGEW oOoTc86D7eUV8JVYcnw5mC0k8JpF4ssnCRCbU0Bf4vzP02wgNiPQbd9PrQGrYRYQl7j1ZD7U zQISS/acZ4awRSVePv7HCmErSyx5sp8Fol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2Cwk Y2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAuPmmASb4w7GBZ8sDzFKc7AoifOaL90ZKCSQ nliSmp2aWpBaFF9UmpNafIiRiYMTRHBJNTDuWPKvPdKgbtXB6sTaHSbeDduXs2ezLC6OFf/y M3/trG19dzWlZTwEdt9rXT1Dv+nMd17RsnmylUtZnt9c9Xs1f+NZT4HJNXc3HHoYzxKo1vvm nkHR/do5hkaL4001LC9deiw0vbW7s739VsaTK/Kzy2Y8bD8QNueRnr7DjJ2HZv/9pzzh7b0d SizFGYmGWsxFxYkAac3YXW4CAAA= Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:04:06 -0000 I think a nice liaison to the next SG17 meeting is in order that lists the = work that Sec Area is doing. Something that would provide an FYI for futur= e work. That is exactly what an informational liaison is for. Anyone up f= or helping craft such an overview? =20 Regards, -scott. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: Thursday, June 13, 2013 7:58 AM To: Nick Hilliard Cc: Scott Mansfield; v6ops@ietf.org Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical secur= ity guideline on deploying IPv6 On 06/13/2013 12:57 PM, Nick Hilliard wrote: > On 10/06/2013 12:03, Scott Mansfield wrote: >> During Additional Review, only comments on the modified sections of=20 >> the document are allowed. >=20 > Scott, >=20 > This document is of sufficiently poor quality that in order to make it=20 > useful, it would need to be substantially rewritten by someone with a=20 > significantly better understanding of both ipv6 and security. I don't=20 > think that its problems can be rectified by submitting limited=20 > comments on prespecified sections, and if the IETF does this, it could=20 > be construed as giving its imprimatur to the document. I believe that=20 > this could reflect badly on the IETF and on that basis I think it=20 > would be a bad idea for the IETF to submit comments. +1 (although I have no idea if the problem is who the document was written by,= whether they didn't do the homework to see what e.g. the IETF has been doi= ng in this area, both, or what). Cheers, -- 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 Thu Jun 13 06:27:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: From: "cb.list6" To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c2289a78b9c904df091731 Cc: Fernando Gont , IPv6 Ops WG , Internet Area , IPv6 Deployment Prevention Subject: Re: [v6ops] [Int-area] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 fgont@si6networks.com Thu Jun 13 09:59:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6899F21F883B for ; Thu, 13 Jun 2013 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDwB-MJ3OTSh for ; Thu, 13 Jun 2013 09:59:40 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D24EB21F8831 for ; Thu, 13 Jun 2013 09:59:39 -0700 (PDT) Received: from [2001:5c0:1400:a::2f] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UnAs2-0007Vh-Dy; Thu, 13 Jun 2013 18:59:34 +0200 Message-ID: <51B9FA64.2040206@si6networks.com> Date: Thu, 13 Jun 2013 18:59:16 +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: Scott Mansfield References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , 6man-ads@tools.ietf.org, opsec-ads@tools.ietf.org Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:59:40 -0000 On 06/13/2013 03:03 PM, Scott Mansfield wrote: > I think a nice liaison to the next SG17 meeting is in order that > lists the work that Sec Area is doing. Something that would provide > an FYI for future work. That is exactly what an informational > liaison is for. Anyone up for helping craft such an overview? FWIW, most of the IPv6 security work is done in the Internet Area and the Operations area. That aside, I'm curious about the objetive of a liason such as the current one -- I hope nobody reads it as the IETF having somehow rubber-stamped the document that ITU-T will eventually publish. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From prvs=58769aba3b=scott.mansfield@ericsson.com Thu Jun 13 10:12:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BBF21F9A14 for ; Thu, 13 Jun 2013 10:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 JxBNqb6L66Zy for ; Thu, 13 Jun 2013 10:12:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E3CBB21F97CA for ; Thu, 13 Jun 2013 10:12:32 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-33-51b9fd8094c5 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9D.88.05617.08DF9B15; Thu, 13 Jun 2013 19:12:32 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Thu, 13 Jun 2013 13:12:31 -0400 From: Scott Mansfield To: Fernando Gont Thread-Topic: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: Ac5jYIPck0d+2CUNT3Sp/Yo0Bb4r3gAFgdfAACwcDIAAOaFYgAARJZWAAAEtJwAACHIDgAACnyaAAABh5gAAEN9BYACfkGeAAAIYcYAABh7coAAEamYAAAhOEaA= Date: Thu, 13 Jun 2013 17:12:31 +0000 Message-ID: References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51B9FA64.2040206@si6networks.com> In-Reply-To: <51B9FA64.2040206@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXSPt27D352BBhP2y1ocf/qE2eLJqjds FisvH2KyWPFyC4vF6WN7mR1YPZYs+cnk8e/GfGaPD4d62D2+XP7MFsASxW2TlFhSFpyZnqdv l8CdseHWeraCRsGK8023mBsY7/J2MXJySAiYSHx88p8VwhaTuHBvPRuILSRwlFHi0Bb2LkYu IHs5o8Tb01OZQRJsQA1bd01nBLFFBDQl5j4/wgRSxCywmVHi5fffYJOEBXIl1i6YyQ5RlCex 8dEsZpAiEYEuRolFW++CJVgEVCVe9e0AW8cr4Cux9fM6Foh1V1glJm5eDJbgFNCX2HTiC9hq RqD7vp9awwRiMwuIS9x6Mp8J4m4BiSV7zjND2KISLx//g/pHWWLJk/0sEPU6Egt2f2KDsLUl li18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLiJERhfxyTYHHcw LvhkeYhRmoNFSZzXfOnOQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJLqoGRTUNfv05A7+B5 UT3Z6Oq0O74KO4SuRcke/3fvlInxdT4ZCc1zc3c/7fU+GFy+scBjElNzy+TULJ7bASd819uf OFtrqmbZ4cwhXRcfM1vq0Arb3DUV5/6v4jka/Ymv018/UWv/+Yz45ryvldUf0z8sTz074fx6 R6Yfz6pWcLzdydrzjOHApHolluKMREMt5qLiRAD//HKMggIAAA== Cc: "v6ops@ietf.org" , "6man-ads@tools.ietf.org" <6man-ads@tools.ietf.org>, "opsec-ads@tools.ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 17:12:43 -0000 The objective of the liaison in question was to inform the IETF community w= hat is going on in SG17. Since the working documents are not open to the p= ublic, non ITU members have to rely on this type of liaison from the ITU in= order to see the documents as they are progressing through the process. = It is important to be aware of how various individuals/institutions/governm= ents interpret the liaisons that fly back and forth, however, controlling t= hat interpretation is difficult. So, (in my opinion), the best way to hand= le situations like this is evaluate if it is worth assisting to make the li= aised document better, or if the situation warrants simply providing pointe= rs to related work that will help raise awareness of existing work to help = their work moving forward. This situation seems to fall into the latter ca= se. If there is interest in creating material that individuals think would= be of use to SG17, I can help formulate that material into an informationa= l liaison. Regards, -scott. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: Thursday, June 13, 2013 12:59 PM To: Scott Mansfield Cc: Nick Hilliard; v6ops@ietf.org; 6man-ads@tools.ietf.org; opsec-ads@tools= .ietf.org Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical secur= ity guideline on deploying IPv6 On 06/13/2013 03:03 PM, Scott Mansfield wrote: > I think a nice liaison to the next SG17 meeting is in order that lists=20 > the work that Sec Area is doing. Something that would provide an FYI=20 > for future work. That is exactly what an informational liaison is=20 > for. Anyone up for helping craft such an overview? FWIW, most of the IPv6 security work is done in the Internet Area and the O= perations area. That aside, I'm curious about the objetive of a liason such as the current = one -- I hope nobody reads it as the IETF having somehow rubber-stamped the= document that ITU-T will eventually publish. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nick@inex.ie Thu Jun 13 10:19:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1875B21F99EF; Thu, 13 Jun 2013 10:19:28 -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 aQ5gSutTn47y; Thu, 13 Jun 2013 10:19:27 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5D44E21F99EE; Thu, 13 Jun 2013 10:19:26 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r5DHJJQ3045229 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 18:19:21 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <51B9FF17.9060401@inex.ie> Date: Thu, 13 Jun 2013 18:19:19 +0100 From: Nick Hilliard 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: SM References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <6.2.5.6.2.20130613073150.0c9c49a8@resistor.net> In-Reply-To: <6.2.5.6.2.20130613073150.0c9c49a8@resistor.net> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, v6ops , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 17:19:28 -0000 On 13/06/2013 15:56, SM wrote: > The IETF cannot say that the document is of poor quality. Indeed not: for the record, my comments were solely a reflection of my personal opinion on the contents of the document. Nick From touch@isi.edu Thu Jun 13 13:19:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 , Fernando Gont Subject: Re: [v6ops] Discussion about header chains (was Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 brian.e.carpenter@gmail.com Thu Jun 13 13:19:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5121F9AA9 for ; Thu, 13 Jun 2013 13:19:35 -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 uC0ClmkMfbbd for ; Thu, 13 Jun 2013 13:19:34 -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 82A2E21F9A9F for ; Thu, 13 Jun 2013 13:19:34 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so7588528pad.2 for ; Thu, 13 Jun 2013 13:19: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=DJ32xEPLYxZ45eW/Pg8pzXPjE6yp+RScj0n7ALhOXmY=; b=ESeiY1diMfBxyEH51rXy8dsooxGZP/yqHkxYk0DS8SULZc0UeUOpUoBfi5lfBE8ClP 6EOy6NfWxECpoJycLXY9goIvjnJYINbUnGmStaEgGEeBRMQa4hJ5pk2mgEjCCHOYqZgZ XiHPpglurCg0ElBJAwLvovDLkkWTi9o6Y01wf3FgF5m2lfBKABdWdpflCV2+t1vprHrL owWHgrEwi7LN9mmhFHECxTOibOhkvlEvMkA10/NLjr4o3Yn8NFaCdMYA4X9IPwPVBCOx kFVAbp5qB0Jz3XuscD7hyflqhDsRbncbLy7pJ99YB/DE+SV9fFADBXrKTuOV7NRFTuvu Y7Og== X-Received: by 10.66.163.200 with SMTP id yk8mr4368460pab.170.1371154773716; Thu, 13 Jun 2013 13:19:33 -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 so3sm27137379pac.14.2013.06.13.13.19.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Jun 2013 13:19:33 -0700 (PDT) Message-ID: <51BA295B.30504@gmail.com> Date: Fri, 14 Jun 2013 08:19:39 +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 References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> In-Reply-To: <51B9B3AF.8080009@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 20:19:35 -0000 On 13/06/2013 23:57, Fernando Gont wrote: > On 06/13/2013 12:57 PM, Nick Hilliard wrote: >> On 10/06/2013 12:03, Scott Mansfield wrote: >>> During Additional Review, only comments on the modified sections of the >>> document are allowed. >> Scott, >> >> This document is of sufficiently poor quality that in order to make it >> useful, it would need to be substantially rewritten by someone with a >> significantly better understanding of both ipv6 and security. I don't >> think that its problems can be rectified by submitting limited comments on >> prespecified sections, and if the IETF does this, it could be construed as >> giving its imprimatur to the document. I believe that this could reflect >> badly on the IETF and on that basis I think it would be a bad idea for the >> IETF to submit comments. > > +1 > > (although I have no idea if the problem is who the document was written > by, whether they didn't do the homework to see what e.g. the IETF has > been doing in this area, both, or what). That's why Scott's *positive* suggestion is a good one - generate a new liaison document describing current IETF work (not a reply to the liaison document from them). And Fernando... you are better placed than most people to provide the technical content of that liaison. As far as X.1037 itself is concerned, it really should not proceed in its current state, but I don't know whether a liaison reply is allowed to say that. Perhaps our liaison document should be entitled "Alternative formulation of technical security guidelines on deploying IPv6", which would make our opinion pretty clear. Brian From jeroen@massar.ch Thu Jun 13 13:54:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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 , Fernando Gont Subject: Re: [v6ops] Discussion about header chains (was Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 , Fernando Gont Subject: Re: [v6ops] Discussion about header chains (was Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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 , Fernando Gont Subject: Re: [v6ops] Discussion about header chains (was Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 fgont@si6networks.com Thu Jun 13 15:16:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C6121F9AFE for ; Thu, 13 Jun 2013 15:16:29 -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_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 0H6MULMVsv-V for ; Thu, 13 Jun 2013 15:16: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 DE64221F8EC3 for ; Thu, 13 Jun 2013 15:16:28 -0700 (PDT) Received: from [2001:5c0:1400:a::3d] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UnFoe-00078O-UE; Fri, 14 Jun 2013 00:16:25 +0200 Message-ID: <51BA44B7.4040707@si6networks.com> Date: Fri, 14 Jun 2013 00:16:23 +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 References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> In-Reply-To: <51BA295B.30504@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 22:16:29 -0000 Hi, Brian, On 06/13/2013 10:19 PM, Brian E Carpenter wrote: > On 13/06/2013 23:57, Fernando Gont wrote: >> >> (although I have no idea if the problem is who the document was written >> by, whether they didn't do the homework to see what e.g. the IETF has >> been doing in this area, both, or what). > > That's why Scott's *positive* suggestion is a good one - generate a new > liaison document describing current IETF work (not a reply to the liaison > document from them). And Fernando... you are better placed than most > people to provide the technical content of that liaison. I volunteer to help in that area. What I'm wondering (since I don't know much about "liasons" in general) is what the "administrative" content should be. For example, the current liason talks about "continue cooperation with the IETF Sec Area". This makes me wonder about (among others), these things: * It looks like this kind fo liason should be with the IETF as a whole -- because some topics can fall in many different areas. For example, I've done IPv6 security stuff on v6ops & opsec (OPS area) and 6man (INT area). I'd bet there's more IPv6 security stuff in INT are or OPS area than in SEC area, for instance. So I guess the IETF as a whole (or at least INT area, OPS area, and SEC area) should be involved. * There should be clear procedures regarding how cooperation would work. When I asked how one was supposed to help in this effort the mechanism was unclear. As a result of the above, I guess ITU-T can claim that their document is a product of their cooperation with the IETF, where most IETFers seem to think the document is far from good. I don't care about this particular document. But I think these aspects should be improved for any future liasons of this sort. > As far as X.1037 itself is concerned, it really should not proceed in its > current state, but I don't know whether a liaison reply is allowed to say > that. Perhaps our liaison document should be entitled "Alternative formulation > of technical security guidelines on deploying IPv6", which would make > our opinion pretty clear. At which point, one would ask "why have the liason, anyway?". P.S.: FWIW, I'm always keen to cooperate with anyone/any organization. Discussion an cooperation can always help all parties improve their understanding of a topic. The problem here is that it is not clear whether real cooperation was intended on teh part of ITU, and, in such case, how it was supposed to happen. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From sm@resistor.net Thu Jun 13 16:06:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D37821F99C5 for ; Thu, 13 Jun 2013 16:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 KL63FQri6lc4 for ; Thu, 13 Jun 2013 16:06:00 -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 2F4F921F99BC for ; Thu, 13 Jun 2013 16:05:59 -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 r5DN5lvg010039; Thu, 13 Jun 2013 16:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371164752; bh=NdqeahJ1kd2B9migE/Dia4oOov3Udo+Gd7LwwnwPs6g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OZoB0eWjhUO3+9Z2ZPjvXQvOgGEYVS44MkaxTi+ZJW1hDxCZ46857Vk+Wtjpycb/b 3YdPvOBBKyQvrA/xmS+5s1X+g3hkNRPX2Xxjr669GMq7P1C0NMGUAk9WMN0jXKOe/Z ttm7Oa8YvfJCCexrfABdrLk7xFQDoSxFSv1imdk8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371164752; i=@resistor.net; bh=NdqeahJ1kd2B9migE/Dia4oOov3Udo+Gd7LwwnwPs6g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PN8x2wMh8BTEFlOaq6+cZC5+r7nrLx4qXC/OMrYPLWzAJNSZgBRko3rc9jbUw/moC F7dKK2sel0jIUkPcHnluGrESMvsWT/ZqxdJHdIaiXsHd8yCRULD3yigDWIIXQr5Jlr lHFRT+9Uct9E38ucCCRdM55SO0kM6ewkxwQj+W3A= Message-Id: <6.2.5.6.2.20130613154308.0c475f08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Jun 2013 16:03:28 -0700 To: Fernando Gont From: SM In-Reply-To: <51BA44B7.4040707@si6networks.com> References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org, Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 23:06:01 -0000 Hi Fernando, At 15:16 13-06-2013, Fernando Gont wrote: >What I'm wondering (since I don't know much about "liasons" in general) >is what the "administrative" content should be. > >For example, the current liason talks about "continue cooperation with >the IETF Sec Area". This makes me wonder about (among others), these things: If a person is not familiar with the IETF and the person is working on security he or she would pick the Security Area. >* It looks like this kind fo liason should be with the IETF as a whole >-- because some topics can fall in many different areas. For example, >I've done IPv6 security stuff on v6ops & opsec (OPS area) and 6man (INT >area). I'd bet there's more IPv6 security stuff in INT are or OPS area >than in SEC area, for instance. So I guess the IETF as a whole (or at >least INT area, OPS area, and SEC area) should be involved. The liaison might point out the appropriate area (see comment above). This topic has been raised on three IETF mailing lists. Most people in INT or OPS have likely seen some parts of the discussion. >* There should be clear procedures regarding how cooperation would work. >When I asked how one was supposed to help in this effort the mechanism >was unclear. A Security Area Director, in an individual capacity, commented about this. I thought that you saw that message. Scott Mansfield explained the procedures too. There was a call for comments last year about the cooperation. People might not have paid attention to it as it is process stuff. It's too late to do much on this one. >As a result of the above, I guess ITU-T can claim that their document is >a product of their cooperation with the IETF, where most IETFers seem to >think the document is far from good. Yes. >At which point, one would ask "why have the liason, anyway?". It's to help the two organizations interact with each other. >understanding of a topic. The problem here is that it is not clear >whether real cooperation was intended on teh part of ITU, and, in such >case, how it was supposed to happen. There is some politics. Regards, -sm From bs7652@att.com Thu Jun 13 16:46:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A536521F9B31 for ; Thu, 13 Jun 2013 16:46:44 -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 q5YNhDMjsw05 for ; Thu, 13 Jun 2013 16:46:37 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1921F9AFF for ; Thu, 13 Jun 2013 16:46:37 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id dd95ab15.77e59940.525973.00-594.1487000.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 13 Jun 2013 23:46:37 +0000 (UTC) X-MXL-Hash: 51ba59dd34a1904f-64430e0119b0ca10fa9cf190edabda853598aa92 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 8d95ab15.0.525945.00-254.1486919.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 13 Jun 2013 23:46:36 +0000 (UTC) X-MXL-Hash: 51ba59dc47143ab2-3bbf2948811a3f134d77fff520312d0934e52819 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5DNkUJA006600; Thu, 13 Jun 2013 19:46:31 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5DNkO37006589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 19:46:24 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 13 Jun 2013 23:46:12 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0342.003; Thu, 13 Jun 2013 19:46:18 -0400 From: "STARK, BARBARA H" To: SM , Fernando Gont Thread-Topic: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: AQHOaIqirqRnvWa33EigSQvt73F20Zk0RmEA Date: Thu, 13 Jun 2013 23:46:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302DF11A@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com> <6.2.5.6.2.20130613154308.0c475f08@resistor.net> In-Reply-To: <6.2.5.6.2.20130613154308.0c475f08@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.198.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=YOAoP26x c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=YChYc9clJBcA:10 a=ffbEND5Md98A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=sWl440SQt6UA:10 a=tRidg3-W1svJ0hsmn_kA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 23:46:44 -0000 As someone who's been tasked in the past to write numerous liaison statemen= ts to IETF and to ITU-T, and who has some experience with IETF and read thr= ough the IETF liaison process doc (RFC 4052), but who has little understand= ing of IPv6 security issues and isn't subscribed to any of the other lists = where this is being discussed, I would like to offer some friendly advice o= n what I would probably do to create a positive outcome in this case. 1. Do not assume that they have bad intentions or are trying to work in a c= losed manner or be disrespectful towards IETF. Assume rather that they real= ly would appreciate comments from IETF.=20 2. Do not assume they have an in depth understanding of how IETF works. 3. Note that the 3 contacts are from Japan and Uganda and recognize that yo= u may be dealing with both language barriers and cultural differences. It's= also useful to understand that the Japanese have found ITU-T to be a good = place for them to do standards work. 4. Have someone with knowledge of the IETF concerns reach out to the listed= co-editor (cc to rapporteur and chair) and say that many individuals in IE= TF have concerns, and that it might be good to have a one-on-one conversati= on between the IETF someone and the co-editor. As individuals. During the c= onversation, step through the document and discuss concerns. Then discuss w= hat sort of liaison response would be helpful for the co-editor to achieve = the desired outcome for influencing the document. 5. The IETF someone then crafts the response based on what was agreed durin= g that discussion. Further IETF processes as described in RFC 4052 ensue. W= hich also means the IETF someone should probably be selected by a WG chair,= AD or other IETF leadership person, as per RFC 4052. I've done liaisons in the past from BBF to ITU-T SGs where the ITU-T docume= nt editors were Japanese and they were wanting comments from BBF. When I fi= rst saw the document they were writing, I had this same sort of "OMG what t= he heck is this?" response that I'm seeing here. What I describe above is w= hat I did (substitute IETF with BBF). It worked. Yes, there are formalities= that need to get followed. But the best results were achieved by agreeing = on the formal response as a result of informal one-on-one discussion. And i= t was worth the effort. Barbara From fgont@si6networks.com Thu Jun 13 17:39:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35821F9B41 for ; Thu, 13 Jun 2013 17:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 E6bMCgmNHhpn for ; Thu, 13 Jun 2013 17:39:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DD55F21F9B4A for ; Thu, 13 Jun 2013 17:39:02 -0700 (PDT) Received: from [2001:5c0:1400:a::3d] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UnI2a-0002ci-U2; Fri, 14 Jun 2013 02:38:57 +0200 Message-ID: <51BA661F.8080703@si6networks.com> Date: Fri, 14 Jun 2013 02:38:55 +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: SM References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com> <6.2.5.6.2.20130613154308.0c475f08@resistor.net> In-Reply-To: <6.2.5.6.2.20130613154308.0c475f08@resistor.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 00:39:14 -0000 On 06/14/2013 01:03 AM, SM wrote: >> >> For example, the current liason talks about "continue cooperation with >> the IETF Sec Area". This makes me wonder about (among others), these >> things: > > If a person is not familiar with the IETF and the person is working on > security he or she would pick the Security Area. But I bet the IETF has a say there, right? >> * There should be clear procedures regarding how cooperation would work. >> When I asked how one was supposed to help in this effort the mechanism >> was unclear. > > A Security Area Director, in an individual capacity, commented about > this. I thought that you saw that message. IMO, the process wasn't straightforward. Besides, reading Barbara's recent post, it looks like we need to get consensus on the actual response (or something similar to that). Thanks, -- 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 13 18:07:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E07821F9B66 for ; Thu, 13 Jun 2013 18:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, 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 O99xE9LOIQ80 for ; Thu, 13 Jun 2013 18:07:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B20ED21F9B4B for ; Thu, 13 Jun 2013 18:07:03 -0700 (PDT) Received: from [2001:5c0:1400:a::3d] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UnITe-0003JL-Bv; Fri, 14 Jun 2013 03:06:54 +0200 Message-ID: <51BA6508.3020003@si6networks.com> Date: Fri, 14 Jun 2013 02:34:16 +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: "STARK, BARBARA H" References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com> <6.2.5.6.2.20130613154308.0c475f08@resistor.net> <2D09D61DDFA73D4C884805CC7865E611302DF11A@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302DF11A@GAALPA1MSGUSR9L.ITServices.sbc.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 01:07:04 -0000 On 06/14/2013 01:46 AM, STARK, BARBARA H wrote: > As someone who's been tasked in the past to write numerous liaison > statements to IETF and to ITU-T, and who has some experience with > IETF and read through the IETF liaison process doc (RFC 4052), but > who has little understanding of IPv6 security issues and isn't > subscribed to any of the other lists where this is being discussed, I > would like to offer some friendly advice on what I would probably do > to create a positive outcome in this case. [...] FWIW, I haven't assumed anything (nor do I have any reasons to do so). However, I do believe that these issues should be clearer to us (how to contribute, etc., etc.), and if cooperation is expected, we shouldn't need to find an ITU-T member that relays our comments... because that rather discourages reviews and cooperation. P.S.: As noted before, I don't know much about the liason process -- so my opinions might reflect that. 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 Ted.Lemon@nominum.com Thu Jun 13 18:25:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E3721F9B34 for ; Thu, 13 Jun 2013 18:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 wfUE7lqHO++t for ; Thu, 13 Jun 2013 18:25:34 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 146C921F9983 for ; Thu, 13 Jun 2013 18:25:33 -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 DSNKUbpxDbJXTH1ZV1m/5N03MfkoZgzDxOnk@postini.com; Thu, 13 Jun 2013 18:25: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 02F511B81D2 for ; Thu, 13 Jun 2013 18:25:33 -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 E1B1819005D; Thu, 13 Jun 2013 18:25:32 -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, 13 Jun 2013 18:25:26 -0700 From: Ted Lemon To: Fernando Gont Thread-Topic: [v6ops] ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 Thread-Index: AQHOaJ4MLHivdB++00exAsYkcDhXzQ== Date: Fri, 14 Jun 2013 01:25:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D6DD1@mbx-01.win.nominum.com> References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com> <6.2.5.6.2.20130613154308.0c475f08@resistor.net> <2D09D61DDFA73D4C884805CC7865E611302DF11A@GAALPA1MSGUSR9L.ITServices.sbc.com> <51BA6508.3020003@si6networks.com> In-Reply-To: <51BA6508.3020003@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4E80AD61C466094AAE9F84D8F0E7597F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 01:25:41 -0000 On Jun 13, 2013, at 8:34 PM, Fernando Gont wrote: > However, I do believe that these issues should be clearer to us (how to > contribute, etc., etc.), and if cooperation is expected, we shouldn't > need to find an ITU-T member that relays our comments... because that > rather discourages reviews and cooperation. The way issues get clearer is by doing what Barbara did, or by listening to= Barbara tell you what she did. There isn't somebody whose job it is to m= ake this work. ITU people have no obligation to cooperate with us. We h= ave no obligation to cooperate with them. We do it because we think it's = worthwhile. As a general principle, IMHO, Barbara's attitude here is the right one. I= t does matter whether the ITU-T publishes bogus documents, because people w= ill write laws referencing those documents, and in many cases they _can't_ = write laws referencing our documents=97in many countries around the world, = what SDO's documents can be referenced in law is codified, and typically th= e IETF isn't an organization that's codified. So when the ITU-T makes a s= tandard that says the wrong stuff, it can have a really significant impact. This is not to say that it's your problem to fix this, but what Barbara is = proposing here is very good advice, and it would be good if _someone_ here = followed it. I can't, for lack of time, but maybe someone can. From fernando@gont.com.ar Thu Jun 13 19:38:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C782421F99E8 for ; Thu, 13 Jun 2013 19:38: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 Cr7N5vQnRjoo for ; Thu, 13 Jun 2013 19:38: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 4029F21F99D1 for ; Thu, 13 Jun 2013 19:38:14 -0700 (PDT) Received: from [2001:5c0:1400:a::3d] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UnJtu-0006G4-6v; Fri, 14 Jun 2013 04:38:06 +0200 Message-ID: <51BA820D.8090207@gont.com.ar> Date: Fri, 14 Jun 2013 04:38: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: Scott Mansfield References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 02:38:15 -0000 On 06/13/2013 03:03 PM, Scott Mansfield wrote: > I think a nice liaison to the next SG17 meeting is in order that > lists the work that Sec Area is doing. Something that would provide > an FYI for future work. That is exactly what an informational > liaison is for. Anyone up for helping craft such an overview? If the liason is about v6 security, you should really consider what we're ding in OPS and INT, too. I can help, if needed. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian.e.carpenter@gmail.com Thu Jun 13 21:52:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F331721F9AFB for ; Thu, 13 Jun 2013 21:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.039 X-Spam-Level: X-Spam-Status: No, score=-103.039 tagged_above=-999 required=5 tests=[AWL=0.560, 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 XrYw1UJuyZR8 for ; Thu, 13 Jun 2013 21:51:54 -0700 (PDT) Received: from mail-ye0-f171.google.com (mail-ye0-f171.google.com [209.85.213.171]) by ietfa.amsl.com (Postfix) with ESMTP id 00DB821F9B0C for ; Thu, 13 Jun 2013 21:51:53 -0700 (PDT) Received: by mail-ye0-f171.google.com with SMTP id q14so49117yen.2 for ; Thu, 13 Jun 2013 21:51: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=Qziepfw1xyKBS3SvpNieVXC9eAPHEMv6dhdBNxvh2Fs=; b=yCiYWkjon3AVB1F1WdpsBVcgrDPq9UrVgrYzSkojcXAM0xLys9lKuw93kFzmGceVdl j479eGIuC/f4CRa7mqn2vVrHFv3UVLqUjQ9GdCYh7mPjcz5GzUNbjLMZuR0AVauF3rvu M/1bAURQPeAvdT1ywSTorBmcqwnSk1I9Pyyyfs3v4oG1YnmaGH3uiqMQSrhicq+4Tvu5 DwKvUgWJOHin8e+TMJrc66AteZwg5aE28/VoqzTTRqhAVpviqUGbFBFONOBJ6wsEwMjT r1+qM+UYML1U/pkE6TalSiXvpDRHcO5hdFBlkrhzsak3uMTlo7Z8D/HYFainW68v8XyX vyZQ== X-Received: by 10.236.18.233 with SMTP id l69mr380528yhl.201.1371185513366; Thu, 13 Jun 2013 21:51: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 g39sm1277564yhb.13.2013.06.13.21.51.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Jun 2013 21:51:52 -0700 (PDT) Message-ID: <51BAA170.5060501@gmail.com> Date: Fri, 14 Jun 2013 16:52:00 +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 References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com> <6.2.5.6.2.20130613154308.0c475f08@resistor.net> <2D09D61DDFA73D4C884805CC7865E611302DF11A@GAALPA1MSGUSR9L.ITServices.sbc.com> <51BA6508.3020003@si6networks.com> In-Reply-To: <51BA6508.3020003@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 04:52:00 -0000 On 14/06/2013 12:34, Fernando Gont wrote: > On 06/14/2013 01:46 AM, STARK, BARBARA H wrote: >> As someone who's been tasked in the past to write numerous liaison >> statements to IETF and to ITU-T, and who has some experience with >> IETF and read through the IETF liaison process doc (RFC 4052), but >> who has little understanding of IPv6 security issues and isn't >> subscribed to any of the other lists where this is being discussed, I >> would like to offer some friendly advice on what I would probably do >> to create a positive outcome in this case. > [...] > > FWIW, I haven't assumed anything (nor do I have any reasons to do so). > > However, I do believe that these issues should be clearer to us (how to > contribute, etc., etc.), and if cooperation is expected, we shouldn't > need to find an ITU-T member that relays our comments... because that > rather discourages reviews and cooperation. Nevertheless, there is no choice: only an ITU-T member, such as a sector member (an institution, not a person) can contribute. Barbara is 100% correct, and Scott is our channel. But don't expect dialogue. Don't worry about the admin part, that is cut-and-paste at the end. If you provide technical text and precise references, that is the hard work done. Brian From ietfc@btconnect.com Fri Jun 14 02:12:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1F121F9C4F for ; Fri, 14 Jun 2013 02:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj57W5xaWXlV for ; Fri, 14 Jun 2013 02:12:33 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id C118821F9C00 for ; Fri, 14 Jun 2013 02:12:19 -0700 (PDT) Received: from mail160-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Jun 2013 09:12:12 +0000 Received: from mail160-ch1 (localhost [127.0.0.1]) by mail160-ch1-R.bigfish.com (Postfix) with ESMTP id 178042E00A2; Fri, 14 Jun 2013 09:12:12 +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: -18 X-BigFish: PS-18(zzd79chbb2dI98dI9371I103dK542I1432I62a3Idbf2idbb0izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail160-ch1 (localhost.localdomain [127.0.0.1]) by mail160-ch1 (MessageSwitch) id 137120113074455_2419; Fri, 14 Jun 2013 09:12:10 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail160-ch1.bigfish.com (Postfix) with ESMTP id 0FE5C12034A; Fri, 14 Jun 2013 09:12:10 +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: <00cb01ce68df$55899a00$4001a8c0@gateway.2wire.net> From: t.petch To: Fernando Gont References: <51B2BB07.2040208@gmail.com><612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk><51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com><51B4F16B.1010100@gmail.com><6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com><51B50594.7040303@si6networks.com><51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com><51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com><6.2.5.6.2.20130613154308.0c475f08@resistor.net><2D09D61DDFA73D4C884805CC7865E611302DF11A@GAALPA1MSGUSR9L.ITServices.sbc.com> <51BA6508.3020003@si6networks.com> Date: Fri, 14 Jun 2013 10:09:56 +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 Cc: v6ops@ietf.org, Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 09:12:39 -0000 ----- Original Message ----- From: "Fernando Gont" To: "STARK, BARBARA H" Cc: ; "Scott Mansfield" Sent: Friday, June 14, 2013 1:34 AM > On 06/14/2013 01:46 AM, STARK, BARBARA H wrote: > > As someone who's been tasked in the past to write numerous liaison > > statements to IETF and to ITU-T, and who has some experience with > > IETF and read through the IETF liaison process doc (RFC 4052), but > > who has little understanding of IPv6 security issues and isn't > > subscribed to any of the other lists where this is being discussed, I > > would like to offer some friendly advice on what I would probably do > > to create a positive outcome in this case. > [...] > > FWIW, I haven't assumed anything (nor do I have any reasons to do so). > > However, I do believe that these issues should be clearer to us (how to > contribute, etc., etc.), and if cooperation is expected, we shouldn't > need to find an ITU-T member that relays our comments... because that > rather discourages reviews and cooperation. Fernando Think of the ITU-T as the political wing of standards making. Just as you cannot walk into the United Nations and address the Security Council, so you have to go through the approved paths in order to get material before the ITU-T. Just as they think that the Security Area is the right contact, so we might think that a particular Question of a particular Study Group is the right forum for our ideas, but what do we know? Hence the existence of a nominated Liaison within the IETF whom we have to use. Liaisons are listed at http://datatracker.ietf.org/liaison/ and it is no coincidence how many of them involve MPLS and SG15 (which work I tracked). Current liaisons are at http://www.ietf.org/liaison/managers.html Think of them as an application gateway, but like anyone in the IETF, a volunteer with a limit on the time available to perform this valuable function. We produce something that fulfils our processes, such as an I-D with consensus, and the gateway turns that into the ITU-T equivalent. The ITU-T make heavy use of Word, PDF and such like, sometimes with more advanced versions thereof than I can decipher (just as the IETF web site defeats me with its use of TLS), but that usually gets taken care of. If you can lead the production of the technical content, showing the breadth of work on IPv6 security within the IETF, then I am confident that the rest will get taken care of. Tom Petch > P.S.: As noted before, I don't know much about the liason process -- so > my opinions might reflect that. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From sm@resistor.net Fri Jun 14 02:43:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5789421F9B57 for ; Fri, 14 Jun 2013 02:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 6zmK7hW1Ej3i for ; Fri, 14 Jun 2013 02:43:36 -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 4946221F9B2A for ; Fri, 14 Jun 2013 02:43:36 -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 r5E9hMDr024134; Fri, 14 Jun 2013 02:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371203010; bh=CEmnP6WUP66/mVw1Ks5ScIufSgasKWbNqE6PymIOzkc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1aUg2al7ODl3xhWKqjUszhMmRuqfyeia3wMi6vtcTW7PLMMxGjsKfaeqdAi0tby/Y Ish2BLVa5j+BByfjDMkCIAMF1ZgDEGnhCIe2Gm0EwtQe08bPZUWdIbVqBddRPv3MSq 0suy/YuG1rICDfNXrCSdhYW3A6Yy8p+OR9MoBBQE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371203010; i=@resistor.net; bh=CEmnP6WUP66/mVw1Ks5ScIufSgasKWbNqE6PymIOzkc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YljAy8IdHTx45f4JpcVNNVEdanBJkMihlOsl4oJ7JLAVwKfQEVg1i7bVeorNvknFP LwFHnVWh8iPEKPzqr20Pjq0bcWlOlhM17iHAUZ2aV3uKW8ivZ3hQpP5TRvnoW50YMB z/OSPO8F00BWLcGljpRTd0OFGasVCNyr4LWhJVow= Message-Id: <6.2.5.6.2.20130614021154.0c4b34c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Jun 2013 02:42:05 -0700 To: Fernando Gont From: SM In-Reply-To: <51BA661F.8080703@si6networks.com> References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> <51BA295B.30504@gmail.com> <51BA44B7.4040707@si6networks.com> <6.2.5.6.2.20130613154308.0c475f08@resistor.net> <51BA661F.8080703@si6networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org, Scott Mansfield Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 09:43:37 -0000 Hi Fernando, At 17:38 13-06-2013, Fernando Gont wrote: >But I bet the IETF has a say there, right? If it is done informally, yes. >IMO, the process wasn't straightforward. Agreed. >Besides, reading Barbara's recent post, it looks like we need to get >consensus on the actual response (or something similar to that). Yes. Someone will have to put in the effort to build agreement. I don't know the impact of ITU-T X.1037. As Ted Lemon mentioned it might be codified in national regulations. Regards, -sm From v6ops@globis.net Fri Jun 14 06:25:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 brian.e.carpenter@gmail.com Fri Jun 14 13:21:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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 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> Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: v6ops@ietfa.amsl.com Delivered-To: v6ops@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> 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 Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 lorenzo@google.com Fri Jun 14 15:15:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2803C21E805E for ; Fri, 14 Jun 2013 15:15:45 -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 l--X1ysVYZdQ for ; Fri, 14 Jun 2013 15:15:45 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5029121E8083 for ; Fri, 14 Jun 2013 15:15:42 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so920159wgh.3 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=ii1xePVm9jhZuIi1n3h9M71AiWytqTCC+NiTHcTtA3dZ8MNXcZidrOaw9wjtumo7sy 6NbjoPDs/7f20Kvt+8d6SzAz1t2oFsCvLSBT07qp53xl4dkyDInDY8oJ9wQKk6zdXZSC JjCKoi6wA7PmyCffsN2MK0SFSyUjdcL3HJLQBx9RIqOZ4M8tGcCHorHw1a89v5d+1ftH ZkMFee2RCV+yV6HOT8vROefBgD0ampP2G8J7a7zUO45CrsqE1unEEOE0YYpF1VpxVqBU nbOesDwIzfgYeyV20Ji8FdfMn//r9nI6PKOzxNd34OSqrQUPdlqg7x2EeWoIOuiesnVE Ka9g== 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: To: Tony Hain Content-Type: multipart/alternative; boundary=047d7b5d9acd5bb6a604df2496a2 X-Gm-Message-State: ALoCoQkfVhUVUZlN5tkmJNc3DdXszynE3qp2/8sEWfz8z52IkDCYPTRBRy2IUNZhPEIFFDErXoxFcgb1x7ZjYHbQhc/OWck54SByiK58cAPC3JQmshXbZxp6YLbAryEiI2OK9kcCyhGB4eLBKbS1sHyDxiXihgboyhAG+/P1Gn1Sj2L9a0HlCIaVmEPUnT91hFT4+ze/f1L4 Cc: "v6ops@ietf.org WG" , IETF IPv6 Mailing List Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 aservin@lacnic.net Sat Jun 15 08:54:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A828021F9DE9 for ; Sat, 15 Jun 2013 08:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 NCYtqfoUbNYK for ; Sat, 15 Jun 2013 08:54:13 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id E49FB21F9D2F for ; Sat, 15 Jun 2013 08:54:12 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [190.186.17.178]) by mail.lacnic.net.uy (Postfix) with ESMTP id B35AF308462; Sat, 15 Jun 2013 12:53:51 -0300 (UYT) Message-ID: <51BC8E2A.4070304@lacnic.net> Date: Sat, 15 Jun 2013 11:54:18 -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: =?ISO-8859-1?Q?Hans_V=E8lez?= References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------060105020503090501030703" X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 Operational Guidelines for DC draft-lopez-v6ops-dc-ipv6-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 15:54:25 -0000 This is a multi-part message in MIME format. --------------060105020503090501030703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hans, Thank you very much for your comments. Please let us know any more comments or text that you may find useful to add to the draft. Cheers, as On 6/12/13 1:49 AM, Hans Vèlez wrote: > Hi authors, > I found it very good compilation that lead so far on the draft, the > issues are quite aligned with most experiences we have in the field of > Data center and virtualization. > > I would refer to points: > > *2.3.2 EXTENDED DUAL STACK OS / HYPERVISORS* > > This is important since the growth of virtualized resources in data > centers, since this increases the number of hypervisors in the same > way also creating a complex management state that extends to the same > security level, creating a point where IT managers will have a space > to develop security plans that go hand in hand with the implementation > of IPv6 hypervisor level, these schemes virtualization security quite > large areas that are called */Virtual Security/* where there are > already several manufacturers have developed products that are > designed to address these issues. > > *3.2 MANAGEMENT SYSTEMS AND APPLICATIONS.* > > Just put in the opinion of the authors this contribution since it is a > perception more about what we have been working in the area of data > centers and virtualization. In schemes where multiple data centers > interconnections live under their geographical separation is given to > our perception a good practice to have OBB network schemes (out of > band), which may enable an autonomous and safe for the management of > data centers as entities belong to a cloud, which is also considered > the deployment of IPv6 for thes part. > > > Thank you very much and good work. > > -- > Hans Vèlez S. > Medellin - Antioquia. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------060105020503090501030703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hans,

        Thank you very much for your comments.

        Please let us know any more comments or text that you may find useful to add to the draft.

    Cheers,
    as
    On 6/12/13 1:49 AM, Hans Vèlez wrote:
    Hi authors,
    I found it very good compilation that lead so far on the draft, the issues are quite aligned with most experiences we have in the field of Data center and virtualization.

    I would refer to points:

    2.3.2 EXTENDED DUAL STACK  OS / HYPERVISORS

    This is important since the growth of virtualized resources in data centers, since this increases the number of hypervisors in the same way also creating a complex management state that extends to the same security level, creating a point where IT managers will have a space to develop security plans that go hand in hand with the implementation of IPv6 hypervisor level, these schemes virtualization security quite large areas that are called Virtual Security where there are already several manufacturers have developed products that are designed to address these issues.

    3.2 MANAGEMENT SYSTEMS AND APPLICATIONS.

    Just put in the opinion of the authors this contribution since it is a perception more about what we have been working in the area of data centers and virtualization. In schemes where multiple data centers interconnections live under their geographical separation is given to our perception a good practice to have OBB network schemes (out of band), which may enable an autonomous and safe for the management of data centers as entities belong to a cloud, which is also considered the deployment of IPv6 for thes part.


    Thank you very much and good work.

    --
    Hans Vèlez S.
    Medellin - Antioquia. 


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

    --------------060105020503090501030703-- From arturo.servin@gmail.com Sat Jun 15 08:58:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8158821F9DED for ; Sat, 15 Jun 2013 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 z8+gok4lf16t for ; Sat, 15 Jun 2013 08:58:45 -0700 (PDT) Received: from mail-ye0-f173.google.com (mail-ye0-f173.google.com [209.85.213.173]) by ietfa.amsl.com (Postfix) with ESMTP id 98EC621F9DEA for ; Sat, 15 Jun 2013 08:58:45 -0700 (PDT) Received: by mail-ye0-f173.google.com with SMTP id m7so475297yen.32 for ; Sat, 15 Jun 2013 08:58:43 -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=7VaWs2N8PBc+9YPrFIz8ucpaSX9lkzmzxo6b3uX6f5o=; b=uK1dH7VSuyADangTYeTrJCcaFSZIKMljhwPSuJa4s2BMxtDwaHsv4DcM9KRou5vBkx DKRO4l6+NTB1+WpJWpEdW96Es+48SvsJijakZrFd8GQT+mAwRx4jKNncdSNCC8pEGzp3 0nPTNRw13m3zp0O9ntBLAjbMl3AlQYwrN02wfO13WRiiLzQhW+wPudq86e1JAQ92hCCH aMXKCwjxnRniSKwxB3G+p9SxacAQpTfx+bY8H0rOLHXajh1EpQe4dOFpw/267ZIqc7eK jw1DtBJnW/JhPyUfLegrxA3ROKzI+gAj0DzH2XdIEHv4FCd2pz8XH2Dqy7gjyDQ7smRF 20Pg== X-Received: by 10.236.17.165 with SMTP id j25mr4219004yhj.89.1371311923381; Sat, 15 Jun 2013 08:58:43 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([190.186.17.178]) by mx.google.com with ESMTPSA id r41sm11166982yhc.12.2013.06.15.08.58.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Jun 2013 08:58:42 -0700 (PDT) Message-ID: <51BC8F3D.1000008@gmail.com> Date: Sat, 15 Jun 2013 11:58: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: Scott Mansfield References: <51B2BB07.2040208@gmail.com> <612109CB-8E7F-4F30-B10A-D0254F3E3EED@ecs.soton.ac.uk> <51B4B0D9.5000104@gmail.com> <51B4B8BE.3020006@si6networks.com> <51B4F16B.1010100@gmail.com> <6F75BAA590FBB24C8CC9CC9503D2C491389736@xmb-aln-x14.cisco.com> <51B50594.7040303@si6networks.com> <51B9A59F.1060109@inex.ie> <51B9B3AF.8080009@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] FW: ITU-T Recommendation ITU-T X.1037, Technical security guideline on deploying IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 15:58:51 -0000 Scott, I think Fernando volunteered (haven't finished the whole thread if somebody else has volunteered too) . I could add some help as well if needed. Regards, as On 6/13/13 9:03 AM, Scott Mansfield wrote: > I think a nice liaison to the next SG17 meeting is in order that lists the work that Sec Area is doing. Something that would provide an FYI for future work. That is exactly what an informational liaison is for. Anyone up for helping craft such an overview? > > Regards, > -scott. From swmike@swm.pp.se Sun Jun 16 22:28:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B5021F99D0; Sun, 16 Jun 2013 22:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=1.044, 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 lVNCx2fq6BTI; Sun, 16 Jun 2013 22:28:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 501AD21F89EB; Sun, 16 Jun 2013 22:28:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9E0F99C; Mon, 17 Jun 2013 07:28:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95E779A; Mon, 17 Jun 2013 07:28:53 +0200 (CEST) Date: Mon, 17 Jun 2013 07:28:53 +0200 (CEST) From: Mikael Abrahamsson To: "Softwires-wg list (softwires@ietf.org)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 05:28:55 -0000 On Thu, 6 Jun 2013, Dan Wing wrote: > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. I read some RFQ answers for residential gateways lately and at least the devices there seemed to support around 2048-4096 mapping. Other numbers I've heard kicked around is for larger populations of fixed line customers (CGN for ADSL and similar tech), one needs to support around 30 connections per customer on average. This goes down a bit when it's a single mobile device (without tethering), then it's more like 4-6 TCP connections needed on average. If I was going to support a student dorm I'm pretty sure the above values would be a lot higher though, especially compared to a retirement home Wifi :) -- Mikael Abrahamsson email: swmike@swm.pp.se From slaggio@criba.edu.ar Tue Jun 18 07:37:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADDC21F9F4C for ; Tue, 18 Jun 2013 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkISxxvSZgdW for ; Tue, 18 Jun 2013 07:37:54 -0700 (PDT) Received: from mecha.criba.edu.ar (mecha.criba.edu.ar [IPv6:2801:0:90:192::8]) by ietfa.amsl.com (Postfix) with ESMTP id 749AC21F9F49 for ; Tue, 18 Jun 2013 07:37:52 -0700 (PDT) Received: from mecha.criba.edu.ar (unknown [127.0.0.1]) by mecha.criba.edu.ar (Postfix) with ESMTP id 64E685D3CA4; Tue, 18 Jun 2013 11:36:26 -0300 (ART) X-Virus-Scanned: amavisd-new at criba.edu.ar Received: from maleva.criba.edu.ar (maleva.criba.edu.ar [IPv6:2801:0:90:192::30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mecha.criba.edu.ar (Postfix) with ESMTP id D25CF5D3C24; Tue, 18 Jun 2013 11:36:23 -0300 (ART) Message-ID: <51C070BB.9090209@criba.edu.ar> Date: Tue, 18 Jun 2013 11:37:47 -0300 From: Santiago Aggio User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] IPv6 Operational Guidelines for DC (draft-lopez-v6ops-dc-ipv6-04) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:37:54 -0000 Dear Authors, My impression is that this very good, very clear, is a guide that covers most of the realities faced by an operator and an engineer of a DC infrastructure to deploy IPv6, with several considerations that help in the moment of decision and the work involved in the technical side of the routing, management and monitoring. The architecture described is very simple and clear, and very well the above stages to reach IPv6-only model. The references also seem to cover these aspects. Great Job!!!!, Congratulations Santiago Aggio Bahia Blanca Argentina. From bs@stepladder-it.com Mon Jun 17 03:47:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA9821F9958; Mon, 17 Jun 2013 03:47: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 B+Gi-JBcin9D; Mon, 17 Jun 2013 03:47:04 -0700 (PDT) Received: from mail.speedpartner.de (mail.speedpartner.de [IPv6:2a01:198::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6247921F9B93; Mon, 17 Jun 2013 03:46:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.speedpartner.de (Postfix) with ESMTP id F2CDD62226; Mon, 17 Jun 2013 12:46:24 +0200 (CEST) Received: from mail.speedpartner.de ([127.0.0.1]) by localhost (mail.speedpartner.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SwXZx5ar8Li; Mon, 17 Jun 2013 12:46:24 +0200 (CEST) Received: from stepladder-it.com (port-83-236-238-169.static.qsc.de [83.236.238.169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mxbot@stepladder-it.com) by mail.speedpartner.de (Postfix) with ESMTPSA id D589961BBD; Mon, 17 Jun 2013 12:46:24 +0200 (CEST) Received: from ip6-localhost ([::1] helo=natrix) by stepladder-it.com with esmtp (Exim 4.80) (envelope-from ) id 1UoWx3-0004bz-2J; Mon, 17 Jun 2013 10:46:21 +0000 From: Benedikt Stockebrand To: "Softwires-wg list \(softwires\@ietf.org\)" , "v6ops\@ietf.org" , "behave\@ietf.org" References: Date: Mon, 17 Jun 2013 10:46:20 +0000 In-Reply-To: (Dan Wing's message of "Thu, 6 Jun 2013 08:43:23 -0700") Message-ID: <877ghtt3pf.fsf@stepladder-it.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Tue, 18 Jun 2013 08:09:26 -0700 Subject: Re: [v6ops] [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:10:31 -0000 Hi Dan and lists, Dan Wing writes: > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) wrote: >> >> In short, port range of 500 seems ok, though 1000 would be more than enough for my home. > > I see several spikes in your data over 500 ports. [...] If you had > only 500 ports on those days, creating a new TCP mapping would have > been impossible, impacting ability to send or receive email, order > books from Amazon.com, and so on. ...or make an emergency phone call using SIP---which currently spooks triple play providers at least here in Germany, not only because it is bad press but disrupting emergency calls is in some cases considered a criminal offense here. Otherwise, in November I saw a presentation by Alain Fiocco (also Cisco) pointing out that a single Bittorrent client already needs about 700 simultaneous connections. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ From amunoz0481@gmail.com Tue Jun 18 18:55:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD04811E80A5 for ; Tue, 18 Jun 2013 18:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsJKfbqF2uRQ for ; Tue, 18 Jun 2013 18:55:45 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id CA42921F93BA for ; Tue, 18 Jun 2013 18:55:44 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ia10so3463305vcb.28 for ; Tue, 18 Jun 2013 18:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=1xUK3qcHdvqHNtZTFU4portSJ7PTdpKHpeJf50shb0E=; b=t4YtaD9ha3OGr8Cp1Mqb3+PBA/9a6+S4UxdePBTWTHl/6qTztnItyhBWEUvvPd4G5H 9rsSeRaCkpF6GkQLqJ6hinnq/aVJoH415yo/MxxXJ7VX1+FEkxITY2H1wgLsivETfJc9 SBYs7Z90KdYo8HJuW2Z5T3FKCenNaMzYV7rkS4oU6zMmX0O95UM97WB1fKVDGbPm6dRv 1p9cSQCbdk3/PwZtiHEQBhVQrQdMZYCddeE2Lt6kS5MttQzakaySLARXXuhzCXOwVOUT uEl7dnrNr6OybAt42yI0OXDloh0FESJk44q5fSAmbFNUEdxTtgfRTbTaJcOXviM+JnHS C3eA== X-Received: by 10.58.68.38 with SMTP id s6mr252415vet.46.1371606944170; Tue, 18 Jun 2013 18:55:44 -0700 (PDT) Received: from AMUNOZPC ([181.129.131.86]) by mx.google.com with ESMTPSA id bk7sm7321965ved.0.2013.06.18.18.55.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 18 Jun 2013 18:55:43 -0700 (PDT) From: "Alexis Munoz \(Gmail\)" To: References: <51C070BB.9090209@criba.edu.ar> In-Reply-To: <51C070BB.9090209@criba.edu.ar> Date: Tue, 18 Jun 2013 20:55:39 -0500 Message-ID: <017f01ce6c90$1ae2e190$50a8a4b0$@gmail.com> 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: AQCIoMgyEq3OaLkWA6YFxvUyr3pWP5vH3Q4g Content-Language: en-us Subject: Re: [v6ops] IPv6 Operational Guidelines for DC (draft-lopez-v6ops-dc-ipv6-04) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 01:55:49 -0000 Dear Authors First of all, I would like to congratulate to all the team who is participating in addressing this guideline ahead. Excellent work. So, I have read the document and I took some notes focus more in = Enterprise Datacenters that I would like to share here. I split my notes following = the chapters on the document: 2.1. General Architecture=20 The generalized interconnection schema in a DC in my opinion must goes beyond. Normally, in a datacenter infrastructure there are modules interconnecting the DC. I agree, the Internet Access is one of them, but = we cannot forget that there might be also modules interconnecting the DC = such as WAN and Remote Access Modules, all depend on the scenario and sector. = The IPv6 Deployment in the Datacenter might extend the interconnectivity to Branch Offices, Partners, Third-Parties, so forth. The IPv6 address = schema should consistent end-to-end, even more for delivery services and applications on public or private networks. 2.2. Experimental Stages=20 One of the implicit advantages of IPv6 application are Flow Labels and Mobile IP, only if they are applied at the ingress elements. However, it = is not clear for me, because all the internal networks are IPv4 in this = stage, then, why Mobile IP comes into play, also, Are we talking about Mobile = IP on IPv4 or IPv6?.=20 Additionally, for VM Migration intra or inter-DC, we might prefer to use mechanism offered by vendors for moving either the virtual machines or = the data, and to keep the ip address intra or inter-DC, there are mechanism = as VLANs, Extended LANs, so on. =20 I will really discuss and review the advantages and disadvantages of = this stage. If somebody is interested in looking this stage for = experimentation or early evaluation, the idea is to find out a good purpose for enroll = it.=20 2.3. Dual Stack Stages=20 On which internal elements are required to have dual-stack??, I guess = that an internal part or element could be defined as Switch, Router, Load Balancer, Firewall, NIPS, Server, Network Service, Application, so = forth. I think that could be interesting to mention in general in a dual-stack = stage which elements are more common to have a dual-stack to achieve a soft transition and avoid impact in the performance of the services and applications. =20 Additionally, the Dual-Stack is focus on LB Mechanism, what happen in scenarios where is not required a Load Balancer?....how is affected the = data transmission in the farm servers??...Should left in IPV4 the Farm = Servers and apply Dual-Stacking in the Services Layers with devices as Firewall, Load Balancer, DNS, Router, Wireless Controllers, So Forth?...what is = the best practice here? 2.4 IPv6 Only Stage.=20 I absolutely agree that planning the ip address schema is one of the = most important and stronger part for a transition IPv6 into the DC = Infrastructure successfully, also apply for any of the transition stages.=20 3. Other Operational Considerations 3.1 Addressing The document recommend at least to have a /48 for each Datacenter, what should be the recommendation to allocate the subnets inside the = datacenter?, I know all depends on the services and architecture, but I think could = be good idea to mention some general good practices to allocate properly = the IPv6 into the DC Infrastructure.=20 3.3. Monitoring and Logging Collect data specific can be using SNMPv3 over IPv6 as well, or is not supported SNMPv3 over IPv6 yet? 3.4. Costs What were the parameters or model to estimate the extra costs??...that = might be very useful to support the business case. I suggest to add to the document. =20 I hope these comments can help to the authors and the community to adopt = the document as WG item. =20 Thanks a lot. Alexis Mu=F1oz -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Santiago Aggio Sent: Tuesday, June 18, 2013 9:38 AM To: v6ops@ietf.org Subject: [v6ops] IPv6 Operational Guidelines for DC (draft-lopez-v6ops-dc-ipv6-04) Dear Authors, My impression is that this very good, very clear, is a guide that = covers most of the realities faced by an operator and an engineer of a DC infrastructure to deploy IPv6, with several considerations that help in = the moment of decision and the work involved in the technical side of the routing, management and monitoring. The architecture described is very simple and clear, and very well = the above stages to reach IPv6-only model. The references also seem to cover these aspects. =20 Great Job!!!!, Congratulations Santiago Aggio Bahia Blanca Argentina. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From aservin@lacnic.net Tue Jun 18 20:23:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB7D21E8082 for ; Tue, 18 Jun 2013 20:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.526 X-Spam-Level: X-Spam-Status: No, score=0.526 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172, 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 0myaYDWARTbm for ; Tue, 18 Jun 2013 20:23:21 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 812EF21E8056 for ; Tue, 18 Jun 2013 20:23:15 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (110-170-171-184.static.asianet.co.th [110.170.171.184]) by mail.lacnic.net.uy (Postfix) with ESMTP id 6CBBB308466 for ; Wed, 19 Jun 2013 00:22:50 -0300 (UYT) Message-ID: <51C12416.6040808@lacnic.net> Date: Wed, 19 Jun 2013 10:23:02 +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: v6ops@ietf.org References: <51C070BB.9090209@criba.edu.ar> In-Reply-To: <51C070BB.9090209@criba.edu.ar> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [v6ops] IPv6 Operational Guidelines for DC (draft-lopez-v6ops-dc-ipv6-04) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 03:23:25 -0000 Santiago, Thank you for the time to review. Cheers, as and the other authors. On 6/18/13 9:37 PM, Santiago Aggio wrote: > Dear Authors, > > My impression is that this very good, very clear, is a guide that covers most of the realities faced by an operator and an engineer of a DC infrastructure to deploy IPv6, with several considerations that help in the moment of decision and the work involved in the technical side of the routing, > management and monitoring. > > The architecture described is very simple and clear, and very well the above stages to reach IPv6-only model. The references also seem to cover these aspects. > > Great Job!!!!, Congratulations > > Santiago Aggio > Bahia Blanca > Argentina. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From aservin@lacnic.net Tue Jun 18 20:27:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C855821E8056 for ; Tue, 18 Jun 2013 20:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.676 X-Spam-Level: X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172, 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 H1NZ89F33Cfg for ; Tue, 18 Jun 2013 20:27:00 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 20E0D11E80D5 for ; Tue, 18 Jun 2013 20:26:59 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (110-170-171-184.static.asianet.co.th [110.170.171.184]) by mail.lacnic.net.uy (Postfix) with ESMTP id 2471C30843C for ; Wed, 19 Jun 2013 00:26:32 -0300 (UYT) Message-ID: <51C124F4.1010902@lacnic.net> Date: Wed, 19 Jun 2013 10:26:44 +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: v6ops@ietf.org References: <51C070BB.9090209@criba.edu.ar> <017f01ce6c90$1ae2e190$50a8a4b0$@gmail.com> In-Reply-To: <017f01ce6c90$1ae2e190$50a8a4b0$@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [v6ops] IPv6 Operational Guidelines for DC (draft-lopez-v6ops-dc-ipv6-04) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 03:27:04 -0000 Alexis, Thank you for the review. Let us check your comments and we will reply shortly. Regards as/ On 6/19/13 8:55 AM, Alexis Munoz (Gmail) wrote: > Dear Authors > > First of all, I would like to congratulate to all the team who is > participating in addressing this guideline ahead. Excellent work. > > So, I have read the document and I took some notes focus more in Enterprise > Datacenters that I would like to share here. I split my notes following the > chapters on the document: > > 2.1. General Architecture > > The generalized interconnection schema in a DC in my opinion must goes > beyond. Normally, in a datacenter infrastructure there are modules > interconnecting the DC. I agree, the Internet Access is one of them, but we > cannot forget that there might be also modules interconnecting the DC such > as WAN and Remote Access Modules, all depend on the scenario and sector. The > IPv6 Deployment in the Datacenter might extend the interconnectivity to > Branch Offices, Partners, Third-Parties, so forth. The IPv6 address schema > should consistent end-to-end, even more for delivery services and > applications on public or private networks. > > > 2.2. Experimental Stages > > One of the implicit advantages of IPv6 application are Flow Labels and > Mobile IP, only if they are applied at the ingress elements. However, it is > not clear for me, because all the internal networks are IPv4 in this stage, > then, why Mobile IP comes into play, also, Are we talking about Mobile IP > on IPv4 or IPv6?. > > Additionally, for VM Migration intra or inter-DC, we might prefer to use > mechanism offered by vendors for moving either the virtual machines or the > data, and to keep the ip address intra or inter-DC, there are mechanism as > VLANs, Extended LANs, so on. > > I will really discuss and review the advantages and disadvantages of this > stage. If somebody is interested in looking this stage for experimentation > or early evaluation, the idea is to find out a good purpose for enroll it. > > > 2.3. Dual Stack Stages > > On which internal elements are required to have dual-stack??, I guess that > an internal part or element could be defined as Switch, Router, Load > Balancer, Firewall, NIPS, Server, Network Service, Application, so forth. I > think that could be interesting to mention in general in a dual-stack stage > which elements are more common to have a dual-stack to achieve a soft > transition and avoid impact in the performance of the services and > applications. > > Additionally, the Dual-Stack is focus on LB Mechanism, what happen in > scenarios where is not required a Load Balancer?....how is affected the data > transmission in the farm servers??...Should left in IPV4 the Farm Servers > and apply Dual-Stacking in the Services Layers with devices as Firewall, > Load Balancer, DNS, Router, Wireless Controllers, So Forth?...what is the > best practice here? > > 2.4 IPv6 Only Stage. > > I absolutely agree that planning the ip address schema is one of the most > important and stronger part for a transition IPv6 into the DC Infrastructure > successfully, also apply for any of the transition stages. > > 3. Other Operational Considerations > 3.1 Addressing > > The document recommend at least to have a /48 for each Datacenter, what > should be the recommendation to allocate the subnets inside the datacenter?, > I know all depends on the services and architecture, but I think could be > good idea to mention some general good practices to allocate properly the > IPv6 into the DC Infrastructure. > > 3.3. Monitoring and Logging > > Collect data specific can be using SNMPv3 over IPv6 as well, or is not > supported SNMPv3 over IPv6 yet? > > 3.4. Costs > > What were the parameters or model to estimate the extra costs??...that might > be very useful to support the business case. I suggest to add to the > document. > > I hope these comments can help to the authors and the community to adopt the > document as WG item. > > Thanks a lot. > > Alexis Muñoz > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Santiago Aggio > Sent: Tuesday, June 18, 2013 9:38 AM > To: v6ops@ietf.org > Subject: [v6ops] IPv6 Operational Guidelines for DC > (draft-lopez-v6ops-dc-ipv6-04) > > Dear Authors, > > My impression is that this very good, very clear, is a guide that covers > most of the realities faced by an operator and an engineer of a DC > infrastructure to deploy IPv6, with several considerations that help in the > moment of decision and the work involved in the technical side of the > routing, management and monitoring. > > The architecture described is very simple and clear, and very well the > above stages to reach IPv6-only model. The references also seem to cover > these aspects. > > Great Job!!!!, Congratulations > > Santiago Aggio > Bahia Blanca > Argentina. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From bill.jouris@insidethestack.com Thu Jun 20 15:32:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430F21F9E5C 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.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oToIgjN6aA1w for ; Thu, 20 Jun 2013 15:32:38 -0700 (PDT) Received: from nm11-vm1.access.bullet.mail.mud.yahoo.com (nm11-vm1.access.bullet.mail.mud.yahoo.com [66.94.237.184]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4621F9E3C for ; Thu, 20 Jun 2013 15:32:38 -0700 (PDT) Received: from [66.94.237.126] by nm11.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000 Received: from [66.94.237.115] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000 Received: from [127.0.0.1] by omp1020.access.mail.mud.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 681435.15302.bm@omp1020.access.mail.mud.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 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 Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Jouris List-Id: v6ops discussion list 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 fred@cisco.com Tue Jun 25 18:37:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D2D11E8192 for ; Tue, 25 Jun 2013 18:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.044 X-Spam-Level: X-Spam-Status: No, score=-110.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 oqVO8ut6X+UB for ; Tue, 25 Jun 2013 18:37:30 -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 7BCB311E8191 for ; Tue, 25 Jun 2013 18:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=373; q=dns/txt; s=iport; t=1372210650; x=1373420250; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=DpE8spywQxN2LEw35+nuGO3xolT5xeAIJT5329PMFkc=; b=D2FKL4HRfnNoSuWMF4ViE7jlIQQOclpXzE0xRlAlWcKYjlHTpyTmRTI9 1vQQqlOXdCxrgS27DcVmwvxHekajuMac7SehTH+Br8aVa/1II1sqkPwqS aSexjqenUzR21OtqMHiwQ08OzZItqRe50pNNpzoFp0MG9ra0a5VUv0ByW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF1FylGtJXG+/2dsb2JhbABagwl6vziBCBZ0giUBBDpRASoUQicEG4gGmg2gP48ZgzphA6kIgxGCKA X-IronPort-AV: E=Sophos;i="4.87,940,1363132800"; d="scan'208";a="227498893" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jun 2013 01:37:13 +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 r5Q1bDYG026409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Jun 2013 01:37:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 20:37:13 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Important dates Thread-Index: AQHOcg2uea+/Gy9PEUidwFreVrspGA== Date: Wed, 26 Jun 2013 01:37:12 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9267CC@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Important dates X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 01:37:36 -0000 The -00 cutoff for IETF 87 is July 8, and for updated drafts, July 15. As a= lways, speaking time is reserved for those drafts that have had supportive = commentary on the list. That can be difficult to achieve if a draft is file= d at the last possible instant. So, suggestion: get your drafts posted soon= er, not later, and promote discussion of them on the list.= From fred@cisco.com Thu Jun 27 14:04:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE94B11E80D9 for ; Thu, 27 Jun 2013 14:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RevdSsOLAOr0 for ; Thu, 27 Jun 2013 14:04:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C57C11E80D5 for ; Thu, 27 Jun 2013 14:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1645; q=dns/txt; s=iport; t=1372367087; x=1373576687; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=nNbmGsU6PhiHICly31DG0id4a9IUQCKEh15hVtz39fs=; b=WPwbfz8amWajODsopzBXE8Qq8K1yr08sQA34AFSGBs2M3lDwdJn/+CIj rTPgMNhInryGI6QdLF3tlk2DGLkJILlxgNDS4TaiKLEahmyi/pHD/a95p /flzXzMThXB5lnv9HJB77zfDTwbyj+XSG+kgBZ6HAvJY6L9kIEsVX/l0K M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAF+ozFGtJXHA/2dsb2JhbABbgwl6vwyBAhZ0giMBAQEBAgF+CwIBGQMBAgskMhsCCAIEEwiIAAauKI0ejySDOmMDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="228359305" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jun 2013 21:04:47 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5RL4kZl019332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Jun 2013 21:04:46 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; Thu, 27 Jun 2013 16:04:46 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: v6ops - Requested sessions have been scheduled for IETF 87 Thread-Index: AQHOc3nzaLZOf/oBNUS3eESPIyN/aw== Date: Thu, 27 Jun 2013 21:04:45 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B92AF3F@xmb-rcd-x09.cisco.com> References: <20130627195901.28748.39444.idtracker@ietfa.amsl.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="Windows-1252" Content-ID: <1E0CA7416EAA044D92749AF7D7B3E273@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Fwd: v6ops - Requested sessions have been scheduled for IETF 87 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 21:04:53 -0000 FYI > From: "\"IETF Secretariat\"" > Subject: v6ops - Requested sessions have been scheduled for IETF 87 > Date: June 27, 2013 12:59:01 PM PDT > To: > Cc: , , , >=20 > Dear Fred Baker, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > v6ops Session 1 (2:00:00) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Potsdam 1 > --------------------------------------------- > v6ops Session 2 (2:00:00) > Wednesday, Morning Session I 0900-1130 > Room Name: Potsdam 1 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name:=20 > Area Name:=20 > Session Requester:=20 >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 2 Hours > Number of Attendees: 300 > Conflicts to Avoid:=20 > First Priority: 6man dhc homenet isis opsawg ospf softwire > Second Priority: behave iccrg intarea opsec tcpm tsvarea tsvwg >=20 >=20 >=20 > Special Requests: > Meetecho support is requested. Scheduling/non-conflict has primacy >=20 > We believe that the aqm BOF will also happen. We need to also not conflic= t with that, please, as Fred will likely be speaking. > --------------------------------------------------------- >=20 =95 Make things as simple as possible, but not simpler. Albert Einstein