From ietf@meetecho.com Thu Aug 1 02:07: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 7377421F9FCA for ; Thu, 1 Aug 2013 02:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcRTysE7wllo for ; Thu, 1 Aug 2013 02:07:24 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id BC11B21F9D70 for ; Thu, 1 Aug 2013 02:06:47 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6m1m00n0EaGCq01M6mKS; Thu, 01 Aug 2013 11:06:47 +0200 Date: Thu, 1 Aug 2013 11:06:44 +0200 (CEST) From: Meetecho Team To: v6ops@ietf.org Message-ID: <1136969288.29.1375348004768.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_28_520615538.1375348004764" Subject: [v6ops] V6OPS session recording available X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:07:29 -0000 ------=_Part_28_520615538.1375348004764 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the V6OPS WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#V6OPS For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_28_520615538.1375348004764-- From joelja@bogus.com Thu Aug 1 06:46:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C7F21E8133 for ; Thu, 1 Aug 2013 06:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 pFxXrIWqZWCR for ; Thu, 1 Aug 2013 06:46:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D71A021E81CB for ; Thu, 1 Aug 2013 06:45:15 -0700 (PDT) Received: from dhcp-6518.meeting.ietf.org (dhcp-6518.meeting.ietf.org [130.129.101.24]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r71DjCg2002936 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 13:45:14 GMT (envelope-from joelja@bogus.com) Message-ID: <51FA6667.4010200@bogus.com> Date: Thu, 01 Aug 2013 15:45:11 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: Nalini Elkins , IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 01 Aug 2013 13:45:14 +0000 (UTC) Subject: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:46:09 -0000 Since I ran into you in the hall and the dicussion turned to ntp... I'll try and be succinct, and as a non-expert in the time field this should be taken with a grain of salt. The generic utility of a high-resultion time-stamp is imho dodgey outside of situations where the clocks are deliberately syncronized and traceable to a common standard whether the protocol used for this is ntp or ieee 1588 (or since this is the ietf PTPV2) . While this is tractable for devices in a single span of control, the agruement that ntp might be suffcient to make this timstamp useful generically between two aribitratry devices where this functionality may need to be enabled is imho a hard one to assert. It is a set of operational practice and discipline moreso than the choice of technology that allows for a high-resolution timestamp to have sufficient precision to be useful between hosts. joel From nalini.elkins@insidethestack.com Thu Aug 1 07:12: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 E046D21F9EB3 for ; Thu, 1 Aug 2013 07:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 JyD6d2MlOIaY for ; Thu, 1 Aug 2013 07:12:15 -0700 (PDT) Received: from nm23-vm4.access.bullet.mail.gq1.yahoo.com (nm23-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.111]) by ietfa.amsl.com (Postfix) with ESMTP id 21A5E21E81EC for ; Thu, 1 Aug 2013 07:11:51 -0700 (PDT) Received: from [216.39.60.166] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Aug 2013 14:11:50 -0000 Received: from [216.39.60.233] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Aug 2013 14:11:50 -0000 Received: from [127.0.0.1] by omp1004.access.mail.gq1.yahoo.com with NNFMP; 01 Aug 2013 14:11:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 428944.22337.bm@omp1004.access.mail.gq1.yahoo.com Received: (qmail 95915 invoked by uid 60001); 1 Aug 2013 14:11:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375366309; bh=M7VsqSQIyZBTzWPPVtut9TaseHLwyZfcus0jEzca6QQ=; 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=YwMPhx5AvhLyh/51nc4vXEemOlE912Einus6ALh2pQl0/3uGO1H7tnHEqO5HVkQbYOdl4C8UxIEreSOWAqRUsDBoI1r3mbJJ/BtvaQ0m74nXrPyA09BUPpC5XI9s//C+MhzFu0gfPah5z+ltU/l3g4RSw5vu8JscZnosyvbRETo= X-YMail-OSG: QjborU0VM1n13UogXlCJafKh0N4jcYwsHOn_klRwZ9emxUh fnPFebNdKkay8ChTe6lRb Received: from [130.129.48.40] by web2803.biz.mail.ne1.yahoo.com via HTTP; Thu, 01 Aug 2013 07:11:49 PDT X-Rocket-MIMEInfo: 002.001, VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBKb2VsLgoKSSB3YW50IHRvIHRha2Ugc29tZSB0aW1lIHRvIHJlc2VhcmNoIHRoaXMgZnVydGhlciBhbmQgdGFsayB0byBzb21lIG1vcmUgcGVvcGxlLiDCoCDCoEkgd2lsbCByZXNwb25kIGJhY2sgb24gdGhlIGxpc3QgdG8gdGhpcyBwb2ludCBpbiBhYm91dCAyIHdlZWtzLiDCoCBJIHdhbnQgdG8gdGFsayB0aGlzIG92ZXIgd2l0aCBzb21lIG9mIHRoZSBmb2xrcyBhY3RpdmVseSB3b3JraW5nIG9uIE5UUCBhdCBJRVRGLsKgCgpOYWxpbmkgRWxraW5zCkluc2lkZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <51FA6667.4010200@bogus.com> Message-ID: <1375366309.93638.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Thu, 1 Aug 2013 07:11:49 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , IPv6 Ops WG In-Reply-To: <51FA6667.4010200@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-757779692-1375366309=:93638" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:12:22 -0000 ---1551098171-757779692-1375366309=:93638 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your comments, Joel.=0A=0AI want to take some time to research t= his further and talk to some more people. =A0 =A0I will respond back on the= list to this point in about 2 weeks. =A0 I want to talk this over with som= e of the folks actively working on NTP at IETF.=A0=0A=0ANalini Elkins=0AIns= ide Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A___= _____________________________=0A From: joel jaeggli =0ATo= : Nalini Elkins ; IPv6 Ops WG =0ASent: Thursday, August 1, 2013 6:45 AM=0ASubject: draft-elkins-v6o= ps-ipv6-pdm-recommended-usage-00=0A =0A=0ASince I ran into you in the hall = and the dicussion turned to ntp...=0A=0AI'll try and be succinct, and as a = non-expert in the time field this=0Ashould be taken with a grain of salt.= =0A=0AThe generic utility of a high-resultion time-stamp is imho dodgey=0Ao= utside of situations where the clocks are deliberately syncronized and=0Atr= aceable to a common standard whether the protocol used for this is ntp=0Aor= ieee 1588 (or since this is the ietf PTPV2) . While this is tractable=0Afo= r devices in a single span of control, the agruement that ntp might be=0Asu= ffcient to make this timstamp useful generically between two=0Aaribitratry = devices where this functionality may need to be enabled is=0Aimho a hard on= e to assert.=0A=0AIt is a set of operational practice and discipline moreso= than the=0Achoice of technology that allows for a high-resolution timestam= p to have=0Asufficient precision to be useful between hosts.=0A=0Ajoel ---1551098171-757779692-1375366309=:93638 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your comments, J= oel.

I want to take some time to research = this further and talk to some more people.    I will respond back= on the list to this point in about 2 weeks.   I want to talk this ove= r with some of the folks actively working on NTP at IETF. 

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

=
From: joel jaeggli <joe= lja@bogus.com>
To: = Nalini Elkins <nalini.elkins@insidethestack.com>; IPv6 Ops WG <v6o= ps@ietf.org>
Sent:= Thursday, August 1, 2013 6:45 AM
Subject: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00
<= /font>

=0ASince I ran into you in= the hall and the dicussion turned to ntp...

I'll try and be succinc= t, and as a non-expert in the time field this
should be taken with a gra= in of salt.

The generic utility of a high-resultion time-stamp is im= ho dodgey
outside of situations where the clocks are deliberately syncro= nized and
traceable to a common standard whether the protocol used for t= his is ntp
or ieee 1588 (or since this is the ietf PTPV2) . While this i= s tractable
for devices in a single span of control, the agruement that = ntp might be
suffcient to make this timstamp useful generically between = two
aribitratry devices where this functionality may need to be enabled = is
imho a hard one to assert.

It is a set of operational practice= and discipline moreso than the
choice of technology that allows for a h= igh-resolution timestamp to have
sufficient precision to be useful betwe= en hosts.

joel






= ---1551098171-757779692-1375366309=:93638-- From Ted.Lemon@nominum.com Thu Aug 1 07:37:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D5521E81F9 for ; Thu, 1 Aug 2013 07:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 VFHHnRe8NL4g for ; Thu, 1 Aug 2013 07:37:29 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 601DA21E8150 for ; Thu, 1 Aug 2013 07:37:24 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUfpyo4IPCpeITyKT8eYMDcdWaN9yUb6K@postini.com; Thu, 01 Aug 2013 07:37:24 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 74D911B8289 for ; Thu, 1 Aug 2013 07:37:23 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5371A190065; Thu, 1 Aug 2013 07:37:23 -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, 1 Aug 2013 07:37:23 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: Reachability [was: draft-ietf-v6ops-64share] Thread-Index: AQHOjXILgP4s3Cr1Y0KYZoQxVxepkJl+4cUAgAFfvQCAAKI5gA== Date: Thu, 1 Aug 2013 14:37:22 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077523C4A4@mbx-01.win.nominum.com> References: <12351.1375184644@sandelman.ca> <9422.1375196203@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B630775238774@mbx-01.win.nominum.com> <51F83A94.1010001@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775239C49@mbx-01.win.nominum.com> <51F9EA90.3050400@gmail.com> In-Reply-To: <51F9EA90.3050400@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , "v6ops@ietf.org WG" , "Byrne, Cameron" Subject: Re: [v6ops] Reachability [was: draft-ietf-v6ops-64share] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Aug 2013 14:37:37 -0000 On Aug 1, 2013, at 6:56 AM, Brian E Carpenter = wrote: > On 31/07/2013 19:57, Ted Lemon wrote: >> An implicit provisioning domain is one that wasn't specified, but assume= d by the host. A formal provisioning domain is specified by configuration= information received from the network. The architecture doc requires that = in order for two provisioning domains to be the same, they have to both be = formal and be securely validated. >>=20 >> It seems to me that reachability is a property of an advertised prefix, = and not of a provisioning domain. So if you have the same IP address on t= wo interfaces, you have the same prefix, and hence the same reachability, w= ith respect to that prefix. >=20 > Yes, but the problem is that we don't know how to express this, for a sco= pe > that isn't entirely local or entirely global. >=20 >> Obviously if the reachability isn't the same this will cause problems, b= ut I think that's a configuration error. >=20 > Or a failure to communicate the actual configuration to the recipient > of the prefix advertisement. I see your point. > I guess I'm saying that if we solve this problem only for the case > of provisioning domains (as defined by MIF), we haven't solved the > general case (where there may be arbitrary filters or missing > routes upstream from the various interfaces). It may not even be > soluble, in which case we'll need happy-eyeballs-like solutions > for ever. Well, given that we can't necessarily trust what the PVD is saying to us, t= hat may well be unfixable, but I think I agree with you that there is value= in conveying this information. If a PVD claims global reachability but doe= sn't have it, the application still has to try it if it have no selection m= echanism that rejects it. But if a PVD says "look, you can only reach the= se prefixes or domains using this PVD," then that certainly eliminates work= an application might otherwise have to do. If it is a trusted PVD, and t= he application wants to connect to a host knowably reachable in that PVD, i= t might be able to completely avoid happy eyeballs. From rajiva@cisco.com Thu Aug 1 13: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 123DF11E815E for ; Thu, 1 Aug 2013 13:43:43 -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 R7mdfjKKfB32 for ; Thu, 1 Aug 2013 13:43:38 -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 26B5011E810E for ; Thu, 1 Aug 2013 13:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5075; q=dns/txt; s=iport; t=1375389817; x=1376599417; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=s2QNlnJjP/0hi0MR9yH3oiSLQguI5Nb052JKYv8LriU=; b=a4tvNp4NS6JHpQ1QmCWDz4QwskYlwBRlPcl6oTZuMB0mFD1bVUMzLGoe 8DzFjXvcgPQuKF2+Zc4cPCu41JVT0DQbwOpeFe9xubZuFS75X5nCmim/k l75CSdbYFNOZPBHnndMm1tOvWubrmWGQyyEFPfacOOowzIsG4uLodpO5S E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAOTH+lGtJV2Z/2dsb2JhbABbgwY1ULpog2SBHRZ0giQBAQEEAQEBNzICAwUDDAYBCBEDAQIBChQxBgsdCAIEDgUIh3YDDwyxIw2IXo0WgTQSejEHBoMTcwOTR4IvgxOKfYUngxSBaQEeIg X-IronPort-AV: E=Sophos;i="4.89,796,1367971200"; d="scan'208";a="242480109" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2013 20:43:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r71KhJDN002502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 20:43:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.244]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 15:43:19 -0500 From: "Rajiv Asati (rajiva)" To: "cb.list6" Thread-Topic: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: AQHOi6uG49XSQKP7Y0WXvaOwRHidPZl8FUcAgABTgYCABIAeAA== Date: Thu, 1 Aug 2013 20:43:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.82.242.87] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG , "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 20:43:43 -0000 Cameron, Thanks for the details. Is there an implicit assumption that the roaming partners' backend system understands v6 PDP, but not v4v6 PDP? Cheers, Rajiv -----Original Message----- From: Cameron Byrne Date: Monday, July 29, 2013 3:59 PM To: Rajiv Asati Cc: "Fred Baker (fred)" , "v6ops@ietf.org" , "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >Rajiv > >On Mon, Jul 29, 2013 at 12:00 PM, Rajiv Asati (rajiva) >wrote: >> Hi Cameron, >> >> Could you please share more details about 3a and 3b below? >> >> > >Can you be more specific about the question? > >Charging systems have a hard time to reconcile usage from 2 PDP >because they are 2 separate CDRs, 1 for each PDP. Also, 2 PDP is 2x >as expensive in terms of signalling and licensing. > >v4v6 as single PDP is not viable because not everything supports >release 8 in the GSM/3GPP ecosystem. I tried to enable v4v6 for my >subscribers in my central database (HLR/HSS), and adding this >capability to all my subscribers made some existing ipv4 roaming >subscribers fail. Why? Because when my users attach into a roaming >partner network, their network downloads the capabilities of the >subscriber from my database (HLR/HSS)... and if one of the >capabilities includes v4v6, then the roaming partners's equipment >drops the users because they don't understand this term. > >This is a roaming partner network device acting in a bad and >non-standard way. It's a shame i have to turn off v4v6 globally >because of this issue. There is one subscriber database, and because >some roaming partner gear fails, it is not safe to turn anywhere. One >remediation is to limit attributes based on a whitelist / blacklist, >but this is not feature available today. > >Luckily, the good people of v6ops have approved RFC6877 and Android >implemented it in 4.3 , so single v6 PDP works ok. > > >> WOuldn't the UE fallback to v4 PDP, if v4v6 PDP wasn't available? >> > >Yes, it's supposed to work that way. But, keep in mind what i said >above. In the real world, it does not (for now, once everyone >upgrades maybe this wont be a problem). > >Cameron > >> Cheers, >> Rajiv >> >> -----Original Message----- >> From: Cameron Byrne >> Date: Sunday, July 28, 2013 11:48 AM >> To: "Fred Baker (fred)" >> Cc: "v6ops@ietf.org" , >> "draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org" >> >> Subject: Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis >> >>>As general feedback >>> >>>1. As others have noted, it is important to clarify that home routed >>>is the default case and local-breakout is only relavent for IMS, but >>>IMS based roaming and local breakout is yet to see its first >>>deployment, and may still be years in the future for roaming to work >>>this way. So, local breakout is not a real case and seems to be >>>causing more confusion. >>> >>>2. There is a hazard in assuming the well known prefix is always >>>available. Any device should not assume the well known prefix is >>>available. This is essentially a misconfiguration that should not >>>occur. >>> >>>3. What i have learned >>> >>>a. dual-stack 2 PDP will never work, charging issues in the billing >>>system, and too much capacity wasted for no real gain >>> >>>b. dual-stack 1 PDP (v4v6) will not work any time soon. Enabling >>>this feature in the HSS/HLR breaks roaming and there is no way to >>>ensure this issue is fixed in the hundreds of networks that are >>>potentially impacted. There are some backs to do on the home network >>>that can make this easier but not exposing partner networks to the new >>>release 8 features. >>> >>>c. What does work and adds value (saves IPv4 address for the common >>>case of not-roaming) : IPv6-only single PDP 464XLAT on the home >>>network, IPv4-only single PDP when roaming. This is how i am moving >>>forward. The when at home, the UE has default configs for ipv6-only >>>and when roaming the ue only attempts to connect using IPv4. This >>>gets the vast majority of users in my home network off v4 and keeps >>>ipv4 for the complicated yet relatively small percentage of roaming >>>users. >>> >>> >>> >>>On Tue, Jul 9, 2013 at 5:45 AM, wrote: >>>> >>>> A new draft has been posted, at >>>>http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. >>>>Please take a look at it and comment. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>_______________________________________________ >>>v6ops mailing list >>>v6ops@ietf.org >>>https://www.ietf.org/mailman/listinfo/v6ops >> From victor@jvknet.com Fri Aug 2 02:06: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 969DD21F85BB for ; Fri, 2 Aug 2013 02:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 99tKPqmy-6X3 for ; Fri, 2 Aug 2013 02:06:06 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3345011E82B9 for ; Fri, 2 Aug 2013 02:01:50 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so458152pbb.27 for ; Fri, 02 Aug 2013 02:00:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type:x-gm-message-state; bh=Dfxlw6Zsj+cAeD2MJOC/C983ZzAouB0EfZT+InbMnQI=; b=hlQUQmO+eZpABeG+JKIhhDi0+i6HbBxnOvhCmsHD7ZXkGJvNiXnh+jc+agZrG0vfE1 3ooCqXIe8YNphg4RS8Umr8rswxU0Y4MOxpyYJUkpLHvoZPXTqnlHYak0xcMJwdMiSfPt BjtL2HT9B7DbTejny7z0tMrVV3lQ+ejZut+qfE+wSOMj3m0YBpd2SHfRTpjL8Q8PQbU8 aYO44xFrC5mcjbwJtgVmYy8m0CoOpiq7OdxTMGhGlooA2fjGrtosdPqRczU4aXTetBab 4IW1Okk8nXH4WWZ9+T+XS2bkKrjfyV/KV/Q87Ixt3tXvbjVQ2wOSzvW/GgV75/3YzV+x sswQ== X-Received: by 10.68.172.34 with SMTP id az2mr2426589pbc.201.1375434059767; Fri, 02 Aug 2013 02:00:59 -0700 (PDT) Received: from [130.129.16.166] (dhcp-10a6.meeting.ietf.org. [130.129.16.166]) by mx.google.com with ESMTPSA id e7sm7514305pbc.11.2013.08.02.02.00.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 02 Aug 2013 02:00:58 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 02 Aug 2013 11:00:54 +0200 From: Victor Kuarsingh To: Message-ID: Thread-Topic: IPv6 Roaming Analysis Document Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3458286058_15723434" X-Gm-Message-State: ALoCoQmmc3KpHyQ+Xs+haIluhdg4dZqRZVo1xejjp46/cjrLjZghUuZd81nMAyFnKvkxt8sc9t7j Subject: [v6ops] IPv6 Roaming Analysis Document X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Aug 2013 09:06:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3458286058_15723434 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Group, As per comment on mic, this information is good, but to be effective as a communication tool, we need to get information back to GSMA. The document seems blur the lines between technology and business. I would say that keeping the information clean and only addressing technical issues is best. We can then allow the GSMA to become aware (I.e. Fred's suggestion to liaise with GSMA) of issues and technical issues, allowing them to address business components. I agree with comments on mic that not everyone reads the 3GPP and/or GSMA documents so a IETF document may help reach more people. Regards, Victor K --B_3458286058_15723434 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Group,

<= div>As per comment on mic, this information is good, but to be effective as = a communication tool, we need to get information back to GSMA.  The doc= ument seems blur the lines between technology and business.

I would say that keeping the information clean and only addressing = technical issues is best.  We can then allow the GSMA to become aware (= I.e. Fred's suggestion to liaise  with GSMA) of issues and technic= al issues, allowing them to address business components.

I agree with comments on mic that not everyone reads the 3GPP and/or G= SMA documents so a IETF document may help reach more people.

<= /div>
Regards,

Victor K
--B_3458286058_15723434-- From ietf@meetecho.com Fri Aug 2 04:15: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 637BD11E82B0 for ; Fri, 2 Aug 2013 04:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.07 X-Spam-Level: X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi6ZXsywG-Nc for ; Fri, 2 Aug 2013 04:14:55 -0700 (PDT) Received: from smtpdg12.aruba.it (smtpdg96.aruba.it [62.149.158.96]) by ietfa.amsl.com (Postfix) with ESMTP id 0E53411E80F8 for ; Fri, 2 Aug 2013 04:14:54 -0700 (PDT) Received: from dell-tcastaldi ([130.129.22.63]) by smtpcmd05.ad.aruba.it with bizsmtp id 7nEo1m00k1MgAzE01nEp98; Fri, 02 Aug 2013 13:14:51 +0200 Date: Fri, 2 Aug 2013 13:14:48 +0200 (CEST) From: Meetecho Team To: v6ops@ietf.org Message-ID: <265370795.1.1375442088847.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_255967135.1375442088814" Subject: [v6ops] V6OPS session recording available X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 11:15:00 -0000 ------=_Part_0_255967135.1375442088814 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the V6OPS WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#V6OPS For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_255967135.1375442088814-- From fred@cisco.com Sun Aug 4 11:00: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 90DB821F9D6B for ; Sun, 4 Aug 2013 11:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWQGQP+W6g30 for ; Sun, 4 Aug 2013 11:00:09 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C15AC21F85E8 for ; Sun, 4 Aug 2013 11:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=639; q=dns/txt; s=iport; t=1375639209; x=1376848809; h=date:from:message-id:to:subject:cc; bh=Lu85nh6fJjKXuGoQAQMcQ4+u8MbjVrtOnfy++nuKelo=; b=G40/oHwMUlJAS48ja1C0sBVHaxhBzN63CLfQWu5fM7yxyuC8sXjSOOxJ m/A2kO8fkDLG6rxS1853ME4Eq/9RQg1rU4dq3/6knGvTyuo3SYzNOVtCQ k1CnBVxQE1O53mtFUiz2BD1ZXvRKCn/q6Tbij/KESrPAejRHuJtmiwDI1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMGAPyV/lGrRDoG/2dsb2JhbABagwY1rWsBkXmBGRZ0gyQ8NIhwDbUvkBkdgwN0A4kqj2CQJYM3 X-IronPort-AV: E=Sophos;i="4.89,813,1367971200"; d="scan'208";a="85815844" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Aug 2013 18:00:08 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r74I07Yw000755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Aug 2013 18:00:07 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r74I03RC023055; Sun, 4 Aug 2013 11:00:03 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r74I03pC023049; Sun, 4 Aug 2013 11:00:03 -0700 (PDT) Date: Sun, 4 Aug 2013 11:00:03 -0700 (PDT) From: Fred Baker Message-Id: <201308041800.r74I03pC023049@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 18:00:14 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From lorenzo@google.com Sun Aug 4 18:35: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 2EC9121E80BC for ; Sun, 4 Aug 2013 18:35:17 -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 6holMY4XFzpg for ; Sun, 4 Aug 2013 18:35:16 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F2EC221E80BE for ; Sun, 4 Aug 2013 18:35:04 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g12so4903135oah.6 for ; Sun, 04 Aug 2013 18:35:04 -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=+vk40YeeLyepA6b0R9YTUFpfT/l1lScEIhyarg6nNls=; b=Xdf3GJTcI9YuZXKNgy1dW7hM0TyUbIcuNfSVNF/cP/+jM8FeFsIULXhcetiph4G2rh PQq/+sXdFKC++g07I4VEHItlu13MTs2felbbJgz0jhK5xQWItfdCNExgeGHOwsq2Glie C11REJfjuX/yXgQqF7oNyodXXAGcR9C9XTg32UTZ9Ns4gN+r/7Ki4uoL+qT/wFBL9ez5 E+/1GF9MkSusMPiXlX3UGauruIP8CQ2eFXSklch4cidaxriR1URp2TRWKl9bthjYsgIY 3EwpQD6i2p1e66t7esknCgZi8KQnFsxyIu9DxBUO2ovmYwmiRXuu8dwU6ovwJTfh+ks+ tfYg== 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=+vk40YeeLyepA6b0R9YTUFpfT/l1lScEIhyarg6nNls=; b=Ce1O2bpQaNvL3vwZu/EDVZK+aAK+TDgW7QtOlU4Vx3ayY1SJ8Q4WjRpLTzpzbC0sYF CHBfo0EgHvd6rK1kRsON53McV2I+dmXHhvDjTIu5+P54biPyz9KQgp6QZZtCR4pVaDA7 Y/ujlsMQog2ddq0bO0WZzZXj8K5kc9kjmmxjqYr5VH8+U3ZmSVIKS/g1dAlUqRp0Kgiy yuZBzvUyTZuFKHaDnFeGkTDYISY8V8BvnwIbmtsUKBgg5zxKV0hv64ej0DNZsLYrggGu Km0AzFanF+b8RK+rYQwz5BovNpZZWGuKTNi4UsrWfnK8KoE/j2OPAsJx5/KacrYS8UCI ObHg== X-Received: by 10.50.18.5 with SMTP id s5mr874873igd.6.1375666503830; Sun, 04 Aug 2013 18:35:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Sun, 4 Aug 2013 18:34:43 -0700 (PDT) In-Reply-To: <201308041800.r74I03pC023049@irp-view13.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> From: Lorenzo Colitti Date: Mon, 5 Aug 2013 10:34:43 +0900 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=089e013cc1c44aa9d204e329514f X-Gm-Message-State: ALoCoQleEcEQ0D84inrHB8tQMfuY7cT3wqb6LHWX3OUtBlXFN+LjYPNpiFYNsl5A9RQ4HR1Ra8xIST2TDwiOv3Vw+r9xSOszxvxqS3DQGfmr/pGUCWxYzwjWIIogya1/P/FOm9kZSwPhg9HCVxSYGQEZQM6Qah9TgSu3/+YmftLRAVbWN6s2vZd1tsuI6JiEvZbQxf0Ylj6k Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 01:35:17 -0000 --089e013cc1c44aa9d204e329514f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 5, 2013 at 3:00 AM, Fred Baker wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6. > Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > As stated at the mike, I think all mention of ULA+NPT66 should be removed, because: 1. AFAIK this is not a scenario that is specified in any RFC, and it is not appropriate to introduce it here in passing, since this document is only tangential to ULAs. 2. This working group is also discussing this same question - with a fair amount of controversy - in the ULA usage draft. That discussion should be held in only one place and should not hold up this document. 3. There is zero or near-zero experience of this deployment model. The authors did not appear to be aware of any deployments that actually used this model. Also, RFC6724-compliant hosts will always prefer IPv4 over ULA, so they will in effect never use them at all; the fact that this is not mentioned in the draft suggests that nobody has actually done this. If ULAs are to be cited in the draft, then they should be mentioned in the context of the only scenarios currently specified by the IETF, either in networks that are completely isolated or in conjunction with global addresses. --089e013cc1c44aa9d204e329514f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 5, 2013 at 3:00 AM, Fred Baker <fred@cisco.com> wrote:
This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-ente= rprise-incremental-ipv6. =A0Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a
statement or finding additional issues that need to be addressed,
please post your comments to the list.

= As stated at the mike, I think all mention of ULA+NPT66 should be removed, = because:
  1. AFAIK this is not a scenario that is specif= ied in any RFC, and it is not appropriate to introduce it here in passing, = since this document is only tangential to ULAs.
  2. This working group is also discussing this same question - with a fair = amount of controversy - in the ULA usage draft. That discussion should be h= eld in only one place and should not hold up this document.
  3. There i= s zero or near-zero experience of this deployment model. The authors did no= t appear to be aware of any deployments that actually used this model. Also= , RFC6724-compliant hosts will always prefer IPv4 over ULA, so they will in= effect never use them at all; the fact that this is not mentioned in the d= raft suggests that nobody has actually done this.
If ULAs are to be cited in the draft, then they should be mention= ed in the context of the only scenarios currently specified by the IETF, ei= ther in networks that are completely isolated or in conjunction with global= addresses.
--089e013cc1c44aa9d204e329514f-- From ek@google.com Sun Aug 4 19:04: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 D0AFD21F9CAD for ; Sun, 4 Aug 2013 19:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjDw3PrJS6jS for ; Sun, 4 Aug 2013 19:04:14 -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 6AB2521F9931 for ; Sun, 4 Aug 2013 19:04:14 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id s1so1371834qcw.23 for ; Sun, 04 Aug 2013 19:04:13 -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=93aX5Fhi+LenptyAEK9rKkWqrT39bwcdY66KSTpEGyo=; b=HsP1vzzT+U4CGqh6id0WDaX3TMRohTXU10SLgeEH0n7k6cp2MprorQVblU9nR3T+BI JLruP1ORnlrpSGOMwJrlPivX+nx+Rx2gsX9bY50nGwwz8b17yC+dPJO8B+X1TtOE9a+/ bRw7USXD8xIKkLzpCSf9SuDX5OzbZ/M70K8j4OPj8P5Rabd/eG66dmONjCsSkTm/axPq gwNy/NmGerk4xw1Bt5Pj3wP00uI/SqG9a76xpPqpB0L7824zda/LiQNCjrb78w1MpqIK 2yv37Ulb+YRuTH/7kIrTD9caXw02FAk3KgtuZxqa1ftP1HT+ac2tAc5pEe3sFja6LQ4Y EQ/g== 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=93aX5Fhi+LenptyAEK9rKkWqrT39bwcdY66KSTpEGyo=; b=F7GJmrgohPfYYZeaKH6bZYkYkClfBeRuAIFqWMU9EEPoHCEpitB7mcwd5BygHw4rVW Zup7qAOAoniiRvxvv2UpObjlRSPPfpMRWqgHCM5+L5fFKMq1kNx33e+l64VWN2guiXNl zxoca6O5yIEoHeMkLYV/lcTu3GgQYiy4/it6+k3mfM//uJjz0Izcns9FOVqCrgiaNdp9 62vjFKUv4mn2j07u020NtOQJjqWyB+Nn58JZNMuTYuRfLgSY5n50uGMZe6EZgEIltdZq 8betiC2FfrLuHmNIDumErouozZDaY2BBYrCnB+vyZfc+GqSkOgaCXNkzhGBE40SGmUno rKTw== X-Received: by 10.49.42.103 with SMTP id n7mr4083415qel.75.1375668252910; Sun, 04 Aug 2013 19:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.11.73 with HTTP; Sun, 4 Aug 2013 19:03:52 -0700 (PDT) In-Reply-To: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> From: Erik Kline Date: Mon, 5 Aug 2013 04:03:52 +0200 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkTZjJTtnD56W4r8lkDS16RLfu7f6/T0Rj+YaszApBbhkBSSgw/9mdoMen5LWtZzl2fyxnPRnXwnki5csjUDB04BE0W+4Fo9dJixuup91lk96AUqurK1rg83NJKBAxqV5jU8vWG0j2UiJoHO0RlAOMiOMaaKEsOxQ2JRV18pDHnwD+q2dAaRCWSFmgi2D6oikKVuiaP Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 02:04:14 -0000 > As stated at the mike, I think all mention of ULA+NPT66 should be removed, > because: Agreed. From christian.jacquenet@orange.com Mon Aug 5 01:23: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 0DA1821F9D0D for ; Mon, 5 Aug 2013 01:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+bSjwLH945a for ; Mon, 5 Aug 2013 01:23:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C491921F9CEF for ; Mon, 5 Aug 2013 01:23:05 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 8ED703B46EF; Mon, 5 Aug 2013 10:23:04 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6B62A4C195; Mon, 5 Aug 2013 10:23:04 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 5 Aug 2013 10:23:04 +0200 From: To: Fred Baker , "v6ops@ietf.org" Date: Mon, 5 Aug 2013 10:23:02 +0200 Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: Ac6RPJAPvCz0VJrVRye5mfYc/5k3oQAc/iMw Message-ID: <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> In-Reply-To: <201308041800.r74I03pC023049@irp-view13.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 08:23:13 -0000 WG,=20 I've read (and commented) this draft some time ago. This document is useful= and I think it should move forward. Regarding the ULA-related discussion, I don't think the document should sim= ply ignore the potential use of such addresses, e.g., because our experienc= e of providing IPv6 VPN service to our corporate customers since 2009 has s= hown that some of these customers ask for (and sometimes demand) a ULA-base= d addressing plan, mostly because these customers still think that private = addressing provides some form of security.=20 This is partly an educational matter which we usually address by organizing= training sessions within the enterprise, but the reality is that we could = never avoid the discussion about ULA usage with these customers. And there = are indeed a few of them who have chosen to go for an ULA addressing plan, = at least for the duration of field trials or even pilot deployments. I would therefore expect the draft to mention ULA addresses. But I would al= so expect the draft to clearly discourage the use of such addresses, for th= e reasons mentioned by Lorenzo in his recent message.=20 For the sake of readability, I would (1) remove the ULA-related text from S= ections 2.4.2, 3.1 and 6.3, and (2) dedicate a specific "On ULA Addressing = and Its Foreseen Implications" subsection in Section 2.6, which would bette= r elaborate on the warnings highlighted in the aforementioned sections (e.g= ., Section 3.1's "use of PI space obviates the need for ULAs"). A few additional typos: Section 2.1, page 7: "...after all initial *deployment* has been completed." Section 2.2.2., page 9: s/recommend/recommended Section 6.3, page 26: s/enterprise/university (second paragraph), s/campus = enterprise/campus Section 8, page 27: s/Jaquenet/Jacquenet=20 Cheers, Christian. -----Message d'origine----- De=A0: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de= Fred Baker Envoy=E9=A0: dimanche 4 ao=FBt 2013 20:00 =C0=A0: v6ops@ietf.org Objet=A0: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC This is to initiate a two week working group last call of http://tools.ietf= .org/html/draft-ietf-v6ops-enterprise-incremental-ipv6. Please read it now= . If you find nits (spelling errors, minor suggested wording changes, etc),= comment to the authors; if you find greater issues, such as disagreeing wi= th a statement or finding additional issues that need to be addressed, plea= se post your comments to the list. We are looking specifically for comments on the importance of the document = as well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to make. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From victor@jvknet.com Mon Aug 5 07:20: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 7D05D21F9C05 for ; Mon, 5 Aug 2013 07:20:38 -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 gVJkZHHtO3b2 for ; Mon, 5 Aug 2013 07:20:32 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1D77121F9E01 for ; Mon, 5 Aug 2013 07:20:32 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id f6so1733772qej.26 for ; Mon, 05 Aug 2013 07:20:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=gzvXAcp06FQKACHb/vDc4FkpkSGgVv5rR+XU09eTZB4=; b=n1JamihHqvJClMKhjHtDOwJgMy0eyd7jGbFKaFVoRdyHh3lKul/4trLnO4mKkhiD+b k9iQu7Vq+8R9rY+qSyYLQbh5zaq+iFrrllVZMlgvQ6zVwOkIuFc4e2N5NTXTSu2WyeR6 SJFWLcvUT3UjWvyv+jexbSspM+3vf4lQfGaO+ZLxRGRtY+7l1QkD8yv72Xxlyt2Q8A4j qqkZDG0uU1c4ByV3AT5Jwjtp0iByRW3l7edgQiJlamY0m3NXlkDF0IHtCnV+ZSbSU19M Lp9jueSKcAPKRIqWxxPEIql18zlBRtxjhSyw7ZrWfIgDTjh3J18Opso7Fw09PD7YJs+D ZwmQ== X-Received: by 10.49.0.198 with SMTP id 6mr18566674qeg.48.1375712431463; Mon, 05 Aug 2013 07:20:31 -0700 (PDT) Received: from [192.168.1.44] ([24.114.93.130]) by mx.google.com with ESMTPSA id h4sm7312783qai.6.2013.08.05.07.20.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 07:20:30 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 05 Aug 2013 10:20:23 -0400 From: Victor Kuarsingh To: , Fred Baker , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC In-Reply-To: <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Gm-Message-State: ALoCoQkRVqyYHGDXBB6OcoyZQ+q8OQZNqqUvqO5jx3zsSI6gpGj5Ye8Y2LFqmx2SFrfMgl9ki8S6 Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:20:39 -0000 On 2013-08-05 4:23 AM, "christian.jacquenet@orange.com" wrote: > >Regarding the ULA-related discussion, I don't think the document should >simply ignore the potential use of such addresses, e.g., because our >experience of providing IPv6 VPN service to our corporate customers since >2009 has shown that some of these customers ask for (and sometimes >demand) a ULA-based addressing plan, mostly because these customers still >think that private addressing provides some form of security. Agreed in principle. I am not able to talk about my personal experiences per NDA with customers. I would say the the use of ULAs in a network is not a secret and people are considering it. Being mute on the subject may result in incorrect analysis of ULA validity in the enterprise. Not considering the good/bad, or the various aspects by which one needs to factor it against - I.e. Security, Internet Reachability, inter-op with other functions like Multicast etc). >=20 > >This is partly an educational matter which we usually address by >organizing training sessions within the enterprise, Fair enough, but I am sure there may be some mis-informed folks potentially advising some customers in the other direction (lets call them rogue consultants). My largest concern is that irrespective of any IETF guidance (if it's negative or positive), ULAs will likely still show up. > > >I would therefore expect the draft to mention ULA addresses. But I would >also expect the draft to clearly discourage the use of such addresses, >for the reasons mentioned by Lorenzo in his recent message. I want to agree with this, but given we have little long term operational experience with ULAs, discouraging it's use based on perceived downfalls may be as bad as encouraging it. If we are unable to provide guidance one way or the other, then pointing to other works (which will continue this debate I am sure), may be the most practical. I think some mention of ULAs, in-line with the text is a good idea since it's with the flow of the document (I.e address subject matters based on document context).=20 As an example, Section 2.4.2 discusses ULAs with respect to [perceived] connections to RFC1918 and security. It was the specific intent of the draft to provide such security guidance in-line. I think pulling out such text would then leave the reading to guess whether ULAs play into the security considerations during the assessment phase. So in summary (my input): (1) Mention ULAs, in-line within text per relevant topic area (2) Don=B9t encourage it's use, and provide due warning of potential issues (again in-line)* (3) Point to other works/drafts on usage cases and further information * I think repetitive warnings throughout document, per subject area will have a better deterrent affect vs. a single section with a "bad for your health" warning. Regards, Victor Kuarsingh > >Christian. > >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de >Fred Baker >Envoy=E9 : dimanche 4 ao=FBt 2013 20:00 >=C0 : v6ops@ietf.org >Objet : [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC > >This is to initiate a two week working group last call of >http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6. >Please read it now. If you find nits (spelling errors, minor suggested >wording changes, etc), comment to the authors; if you find greater >issues, such as disagreeing with a statement or finding additional issues >that need to be addressed, please post your comments to the list. > >We are looking specifically for comments on the importance of the >document as well as its content. If you have read the document and >believe it to be of operational utility, that is also an important >comment to make. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From brian@innovationslab.net Mon Aug 5 07:22: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 EDEDF21F9F1C for ; Mon, 5 Aug 2013 07:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 OBGxyC56Jilq for ; Mon, 5 Aug 2013 07:21:59 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2CE21F9F01 for ; Mon, 5 Aug 2013 07:21:40 -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 E5C1D880FB for ; Mon, 5 Aug 2013 07:21:39 -0700 (PDT) Received: from 10252294.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 AE84813680D7 for ; Mon, 5 Aug 2013 07:21:39 -0700 (PDT) Message-ID: <51FFB4F2.4060503@innovationslab.net> Date: Mon, 05 Aug 2013 10:21:38 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <51FA6667.4010200@bogus.com> <1375366309.93638.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1375366309.93638.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:22:09 -0000 ntpwg@lists.ntp.org will get you the NTP WG. Regards, Brian On 8/1/13 10:11 AM, Nalini Elkins wrote: > Thanks for your comments, Joel. > > I want to take some time to research this further and talk to some more people. I will respond back on the list to this point in about 2 weeks. I want to talk this over with some of the folks actively working on NTP at IETF. > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > > ________________________________ > From: joel jaeggli > To: Nalini Elkins ; IPv6 Ops WG > Sent: Thursday, August 1, 2013 6:45 AM > Subject: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 > > > Since I ran into you in the hall and the dicussion turned to ntp... > > I'll try and be succinct, and as a non-expert in the time field this > should be taken with a grain of salt. > > The generic utility of a high-resultion time-stamp is imho dodgey > outside of situations where the clocks are deliberately syncronized and > traceable to a common standard whether the protocol used for this is ntp > or ieee 1588 (or since this is the ietf PTPV2) . While this is tractable > for devices in a single span of control, the agruement that ntp might be > suffcient to make this timstamp useful generically between two > aribitratry devices where this functionality may need to be enabled is > imho a hard one to assert. > > It is a set of operational practice and discipline moreso than the > choice of technology that allows for a high-resolution timestamp to have > sufficient precision to be useful between hosts. > > joel > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nalini.elkins@insidethestack.com Mon Aug 5 07:58:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188C021F9F7F for ; Mon, 5 Aug 2013 07:58:48 -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 VhCo2HWtDdrb for ; Mon, 5 Aug 2013 07:58:43 -0700 (PDT) Received: from nm1-vm8.access.bullet.mail.bf1.yahoo.com (nm1-vm8.access.bullet.mail.bf1.yahoo.com [216.109.114.79]) by ietfa.amsl.com (Postfix) with ESMTP id A173F21F9F6F for ; Mon, 5 Aug 2013 07:58:42 -0700 (PDT) Received: from [66.196.81.155] by nm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 14:58:41 -0000 Received: from [66.196.81.134] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 14:58:41 -0000 Received: from [127.0.0.1] by omp1010.access.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 14:58:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 13806.48257.bm@omp1010.access.mail.bf1.yahoo.com Received: (qmail 99027 invoked by uid 60001); 5 Aug 2013 14:58:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375714720; bh=E7/eieltNllLYUIOecyVqN+hS2SQ5Cnj+YkvLf/4lWE=; 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=jVijtHCKmXHbx9ofKlONYfKfEMdkzzFHuQM0vQWYXAV37psLV8WcMcOy0iUyECmilSkdNSkz4CX2qM2U+VD8Xzt570LvsKSjFIDrrZuz73aVfddpecGfaaY93OsvgN3X7PihUecLBGirgCFgzt8x8FaHojexZ8wra5Ahspx6oDw= X-YMail-OSG: DmJa_VkVM1mahvZEaofSwCIlUWRIeWYa6gjVn_6d123TTTH rVWjAQO6nHEzT.TW92rFeX1FgBNTQANw891GKU_l068T3KRJ2o6oM6S_Dqvo LeKkbPuVvX7zSx3S4O59TQXWWqVGGNCDMb0pPCg7n..dq8PAtJMVHKfeJRwM jeYti2fX9hmFo_T6iSZg9FjU03BCbUlDfNsrxtSk5z4Hx3Ypc9t7JE5TuBMY VnyyXIFrKE6yIZVKXk1nXVI0JBoFkZb4pmEs7lJcr00q8wN1t9czajsBkU5Q FY6bCJIZhhK6EMq1lwRbFFR2BIx0ZP_lkub3SevAMC.eLKZUlbMV0QYE6oqi F9ZEnVWeHtdtnmuwC9mhXXNvFc20UO1pvRTF9h3uiPPOTmZNNLI73vYqhgOm 71fL3GIEOwfM9C8zbRyqV6jEq4WXQzFErzHOTRg4q6xIoq_eIv5VfNJw2Xnf h1Bcv685ideVjedtuA15mbC9Lazi5IsSfhuigrjrb.vfH4rXJbHVHHiKC_w3 PtK4W.2wnvqkmXBta8D.T9WV8B9udK_3p2YDsILwvnGq3X99KjypZfkkihH9 QbJ1SL19EsyGeFT.UothlUTXzEbkbOQ0m5t9YUX83wgbYI4ZbiN1CCzSkqEq EG2TZrX9cp1Zs8LoFCIu5OJDvnwueDyrlURWYa6LwqrIvrnGQCE8.x5HEbA- - Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Mon, 05 Aug 2013 07:58:40 PDT X-Rocket-MIMEInfo: 002.001, CgpUaGFua3MsIEJyaWFuLgoKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IEJyaWFuIEhhYmVybWFuIDxicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ.ClRvOiB2Nm9wc0BpZXRmLm9yZyAKU2VudDogTW9uZGF5LCBBdWd1c3QgNSwgMjAxMyA3OjIxIEFNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWVsa2lucy12Nm9wcy1pcHY2LXBkbS1yZWNvbW0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <51FA6667.4010200@bogus.com> <1375366309.93638.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51FFB4F2.4060503@innovationslab.net> Message-ID: <1375714720.98714.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Mon, 5 Aug 2013 07:58:40 -0700 (PDT) From: Nalini Elkins To: Brian Haberman , "v6ops@ietf.org" In-Reply-To: <51FFB4F2.4060503@innovationslab.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-310996721-1375714720=:98714" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:58:48 -0000 ---1551098171-310996721-1375714720=:98714 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AThanks, Brian.=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) = 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______________________________= __=0A From: Brian Haberman =0ATo: v6ops@ietf.org = =0ASent: Monday, August 5, 2013 7:21 AM=0ASubject: Re: [v6ops] draft-elkins= -v6ops-ipv6-pdm-recommended-usage-00=0A =0A=0Antpwg@lists.ntp.org will get = you the NTP WG.=0A=0ARegards,=0ABrian=0A=0AOn 8/1/13 10:11 AM, Nalini Elkin= s wrote:=0A> Thanks for your comments, Joel.=0A>=0A> I want to take some ti= me to research this further and talk to some more people.=A0 =A0 I will res= pond back on the list to this point in about 2 weeks.=A0 I want to talk th= is over with some of the folks actively working on NTP at IETF.=0A>=0A> Nal= ini Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> www.insidethest= ack.com=0A>=0A>=0A>=0A> ________________________________=0A>=A0 From: joel= jaeggli =0A> To: Nalini Elkins ; IPv6 Ops WG =0A> Sent: Thursday, August 1, 2013 = 6:45 AM=0A> Subject: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00=0A>= =0A>=0A> Since I ran into you in the hall and the dicussion turned to ntp..= .=0A>=0A> I'll try and be succinct, and as a non-expert in the time field t= his=0A> should be taken with a grain of salt.=0A>=0A> The generic utility o= f a high-resultion time-stamp is imho dodgey=0A> outside of situations wher= e the clocks are deliberately syncronized and=0A> traceable to a common sta= ndard whether the protocol used for this is ntp=0A> or ieee 1588 (or since = this is the ietf PTPV2) . While this is tractable=0A> for devices in a sing= le span of control, the agruement that ntp might be=0A> suffcient to make t= his timstamp useful generically between two=0A> aribitratry devices where t= his functionality may need to be enabled is=0A> imho a hard one to assert.= =0A>=0A> It is a set of operational practice and discipline moreso than the= =0A> choice of technology that allows for a high-resolution timestamp to ha= ve=0A> sufficient precision to be useful between hosts.=0A>=0A> joel=0A>=0A= >=0A>=0A> _______________________________________________=0A> v6ops mailing= list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A= >=0A=0A_______________________________________________=0Av6ops mailing list= =0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops ---1551098171-310996721-1375714720=:98714 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks, Bria= n.


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

From: Brian Haberman <brian@innova= tionslab.net>
To: v= 6ops@ietf.org
Sent: M= onday, August 5, 2013 7:21 AM
Sub= ject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-= 00

=0Antpwg@lists.= ntp.org will get you the NTP WG.

Regards,
Brian

On 8/1= /13 10:11 AM, Nalini Elkins wrote:
> Thanks for your comments, Joel.<= br>>
> I want to take some time to research this further and talk = to some more people.    I will respond back on the list to this p= oint in about 2 weeks.  I want to talk this over with some of the fol= ks actively working on NTP at IETF.
>
> Nalini Elkins
> I= nside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>>
>
> ________________________________
>  From:= joel jaeggli <joelja@bogus.com>
> To: Nalini Elkins <nalini.elkins@insidethest= ack.com>; IPv6 Ops WG <v6ops@ietf.org>
> Sent: Thursday, A= ugust 1, 2013 6:45 AM
> Subject: draft-elkins-v6ops-ipv6-pdm-recommen= ded-usage-00
>
>
> Since I ran into you in the hall and t= he dicussion turned to ntp...
>
> I'll try and be succinct, and= as a non-expert in the time field this
> should be taken with a grai= n of salt.
>
> The generic utility of a high-resultion time-sta= mp is imho dodgey
> outside of situations where the clocks are delibe= rately syncronized and
> traceable to a common standard whether the p= rotocol used for this is ntp
> or ieee 1588 (or since this is the iet= f PTPV2) . While this is tractable
> for devices in a single span of = control, the agruement that ntp might be
> suffcient to make this timstamp useful generically between two
> aribitratry devices where = this functionality may need to be enabled is
> imho a hard one to ass= ert.
>
> It is a set of operational practice and discipline mor= eso than the
> choice of technology that allows for a high-resolution= timestamp to have
> sufficient precision to be useful between hosts.=
>
> joel
>
>
>
> _____________________= __________________________
> v6ops mailing list
> v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops
>

______= _________________________________________
v6ops mailing list
v6ops@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/v6ops

<= br>
---1551098171-310996721-1375714720=:98714-- From fred@cisco.com Mon Aug 5 09:38: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 55A0F21F9FC6 for ; Mon, 5 Aug 2013 09:38:27 -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 YEgKF2UYOLPL for ; Mon, 5 Aug 2013 09:38:20 -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 2FFB521F9D33 for ; Mon, 5 Aug 2013 09:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5582; q=dns/txt; s=iport; t=1375720681; x=1376930281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FUZVHO8TwnxXMThwriVS6gJckEsHBT5zSRNxOzc9L5A=; b=OlOKv2Pp128jWRFEVawFML2bbP8UrluDA9RD+tmMF8AtHQ4DM+VUW3s8 7GY754qhg26u929HZ5m+FwlrVIjsDbiuSohFrWNXvvuCTOFdnl6DhwHau RWHRf0CU5uLZMmhHzWOpJ60uSygetZ3c43L5eVgZzsP+sMZd0bPWFinB1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAITU/1GtJXG//2dsb2JhbABbgwY1UL51gSEWdIIkAQEBAwEBAQFrCwULAgEIIh0HJwsUEQIEAQ0FCBSHbgYMtTOOUYEVAjEHgxl0A5kKkCWDF4FxOQ X-IronPort-AV: E=Sophos;i="4.89,819,1367971200"; d="scan'208";a="243607120" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 05 Aug 2013 16:37:55 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r75GbsQE014993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 16:37:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 11:37:54 -0500 From: "Fred Baker (fred)" To: "christian.jacquenet@orange.com" , "Lorenzo Colitti" Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkfohNjEYIMkIb0i5L4Ne0hNrqQ== Date: Mon, 5 Aug 2013 16:37:53 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: text/plain; charset="Windows-1252" Content-ID: <171FEFC2394AE44991622FE6E35F768C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:38:27 -0000 A thought - tell me if this makes sense. In IPv4 networks, it is pretty common to in some way advertise the address = of an internal-only server and then block access to it at the firewall. If = you want Cisco examples, try wwwin.cisco.com or irp-view13.cisco.com - dig = them, ping them, and traceroute towards them. From my perspective, in IPv4 = or in IPv6, the firewall rule makes little sense except as an additional de= fensive layer; one should not advertise the name to the great unwashed, and= whether or not one does, one should give the system an address that is not= advertised to the great unwashed. The next question, of course, is how to = achieve that - does one only advertise half of their address space? Announc= e multiple prefixes? The ULA, whatever its other ills or uses may be, is an= address that is not advertised upstream, and therefore a very logical addr= ess for an internal-only system in an IPv6 network. I scratch my head a bit on the vehemence that seems to come across in discu= ssions of the ULA. I understand that there is a strong distaste for NATs, a= nd I share it in the stateful case. It sounds a bit like the baby is being = discarded with the bathwater, though, in the case of a system that one does= n't want to have communicating with the great wide world. Am I out to lunch? If so, in what way? On Aug 5, 2013, at 1:23 AM, christian.jacquenet@orange.com wrote: > WG,=20 >=20 > I've read (and commented) this draft some time ago. This document is usef= ul and I think it should move forward. >=20 > Regarding the ULA-related discussion, I don't think the document should s= imply ignore the potential use of such addresses, e.g., because our experie= nce of providing IPv6 VPN service to our corporate customers since 2009 has= shown that some of these customers ask for (and sometimes demand) a ULA-ba= sed addressing plan, mostly because these customers still think that privat= e addressing provides some form of security.=20 >=20 > This is partly an educational matter which we usually address by organizi= ng training sessions within the enterprise, but the reality is that we coul= d never avoid the discussion about ULA usage with these customers. And ther= e are indeed a few of them who have chosen to go for an ULA addressing plan= , at least for the duration of field trials or even pilot deployments. >=20 > I would therefore expect the draft to mention ULA addresses. But I would = also expect the draft to clearly discourage the use of such addresses, for = the reasons mentioned by Lorenzo in his recent message.=20 >=20 > For the sake of readability, I would (1) remove the ULA-related text from= Sections 2.4.2, 3.1 and 6.3, and (2) dedicate a specific "On ULA Addressin= g and Its Foreseen Implications" subsection in Section 2.6, which would bet= ter elaborate on the warnings highlighted in the aforementioned sections (e= .g., Section 3.1's "use of PI space obviates the need for ULAs"). >=20 > A few additional typos: >=20 > Section 2.1, page 7: "...after all initial *deployment* has been complete= d." > Section 2.2.2., page 9: s/recommend/recommended > Section 6.3, page 26: s/enterprise/university (second paragraph), s/campu= s enterprise/campus > Section 8, page 27: s/Jaquenet/Jacquenet=20 >=20 > Cheers, >=20 > Christian. >=20 > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de= Fred Baker > Envoy=E9 : dimanche 4 ao=FBt 2013 20:00 > =C0 : v6ops@ietf.org > Objet : [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC >=20 > This is to initiate a two week working group last call of http://tools.ie= tf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6. Please read it n= ow. If you find nits (spelling errors, minor suggested wording changes, etc= ), comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, pl= ease post your comments to the list. >=20 > We are looking specifically for comments on the importance of the documen= t as well as its content. If you have read the document and believe it to b= e of operational utility, that is also an important comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 =95 Make things as simple as possible, but not simpler. Albert Einstein From Fred.L.Templin@boeing.com Mon Aug 5 11:56: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 18F0621F9DF0 for ; Mon, 5 Aug 2013 11:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 z1rcLPnB5YmR for ; Mon, 5 Aug 2013 11:56:24 -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 4FC9C21F8F32 for ; Mon, 5 Aug 2013 11:56:24 -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 r75Iv616003072 for ; Mon, 5 Aug 2013 11:57:06 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r75Iv6PP003069 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 5 Aug 2013 11:57:06 -0700 Received: from XCH-BLV-307.nw.nos.boeing.com (130.247.25.219) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 5 Aug 2013 11:56:23 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.29]) by XCH-BLV-307.nw.nos.boeing.com ([169.254.7.253]) with mapi id 14.02.0328.011; Mon, 5 Aug 2013 11:56:22 -0700 From: "Templin, Fred L" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkTyP0j6dQxs+okyfI+7WfZncI5mG7srA Date: Mon, 5 Aug 2013 18:56:22 +0000 Message-ID: <2134F8430051B64F815C691A62D983180DF98D@XCH-BLV-504.nw.nos.boeing.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> In-Reply-To: <201308041800.r74I03pC023049@irp-view13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:56:30 -0000 Hi Fred, See below for my comments: Thanks - Fred fred.l.templin@boeing.com 1) Suggest going through the document and update any references that were once I-Ds but have since been published as RFCs (editorial). 2) Abstract - change: "and potentially an IPv6-only operating mode." to: "and eventually an IPv6-only operating mode." ? 3) Throughout the document, the use of "tunnels" seems to generically refer to tunnels used for IPv6/IPv4 transition purposes and is used in a somewhat negative light. However, IPv6 tunnels will be used in enterprises for the long term for other crucial functions. To disambiguate, suggest going through the document and change the word "tunnels" to "transition tunnels" where this is the intended meaning. Also add text similar to the following near the beginning of the document: "Tunnels used for IPv6/IPv4 transition are expected as near/mid- term mechanisms, while IPv6 tunneling will be used for many long-term operational purposes such as security, routing control, mobility, multi-homing, traffic engineering, etc. We refer to the former class of tunnels as "transition tunnels". 4) Section 4.3, end of third paragraph, add the sentence: "For example, mobility management functions will be needed to accommodate handovers between diverse access technologies." 5) Section 4.3, add a final paragraph such as: "Enterprise networks more and more include virtual networks where a single physical node may host many virtualized addressable devices. It is imperative that the addressing plans assigned to these virtual networks and devices be consistent and non-overlapping with the addresses assigned to real networks and nodes. For example, a virtual network established within an isolated lab environment may at a later time become attached to the production enterprise network."=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fred Baker > Sent: Sunday, August 04, 2013 11:00 AM > To: v6ops@ietf.org > Subject: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC >=20 > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental- > ipv6. Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. >=20 > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Mon Aug 5 12:33: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 ECD4821F9DAA for ; Mon, 5 Aug 2013 12:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, 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 FsvIuHdRhzIq for ; Mon, 5 Aug 2013 12:33:38 -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 2EBA521F9D9C for ; Mon, 5 Aug 2013 12:33:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6013787007F; Mon, 5 Aug 2013 21:33:22 +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 chBUv1b8R-tR; Mon, 5 Aug 2013 21:33:22 +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 0AD74870077; Mon, 5 Aug 2013 21:33:22 +0200 (CEST) Message-ID: <51FFFDFB.1040309@globis.net> Date: Mon, 05 Aug 2013 21:33:15 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:33:40 -0000 Fred Baker (fred) wrote: > A thought - tell me if this makes sense. > > In IPv4 networks, it is pretty common to in some way advertise the address of an internal-only server and then block access to it at the firewall. This might be classified as a "leak" if they were 192.168/16 addresses. But for GUA I see no harm advertising them, either in the namespace or the routing space. The information is invariant inside and outside: they're just not reachable from everywhere. > If you want Cisco examples, try wwwin.cisco.com or irp-view13.cisco.com - dig them, ping them, and traceroute towards them. The examples you gave are equivalent of GUA, and Internet DNS. > From my perspective, in IPv4 or in IPv6, the firewall rule makes little sense except as an additional defensive layer; one should not advertise the name to the great unwashed, and whether or not one does, one should give the system an address that is not advertised to the great unwashed. Agreed. Agreed. It's not just security. It's to avoid confusion, cached connections etc. > The next question, of course, is how to achieve that - does one only advertise half of their address space? Name space is the key here IMHO. Not just address space. You're into DNS Bind "view" territory. Especially when you have devices that wander regularly across the border and that cache lots of information. > Announce multiple prefixes? The ULA, whatever its other ills or uses may be, is an address that is not advertised upstream, and therefore a very logical address for an internal-only system in an IPv6 network. True. But how does your machine know it is "internal only" or "external" with VPN's, proxies, ALGs etc. etc. And how long is that definition valid? When management gets outsourced to supplier X? > I scratch my head a bit on the vehemence that seems to come across in discussions of the ULA. I understand that there is a strong distaste for NATs, and I share it in the stateful case. It sounds a bit like the baby is being discarded with the bathwater, though, in the case of a system that one doesn't want to have communicating with the great wide world. > > Am I out to lunch? If so, in what way? It's the confusion equivalent to the .local namespace that bothers me more. I've seen people configure a server x.foobar.com in DNS that is not only a different IP address on the inside and outside, it's a completely different machine. Or it might not be a different machine, but it's one machine with a different physical interface with completely different firewall rules. If you then have a cached bzr: checkout over ssh on your mobile device, you're going to get confused machines and users. A URL should be universal. Especially in a world that is becoming increasingly mobile. Once you start using ULA + NPT, all URLs and DNS entries become equivalent to .local namespace + RFC1918, depending on your current connection point relative to the NPT and the server. i.e. you've got no idea if the NPT is in path or not. NPT doesn't translate the DNS AAAA records. And DNS replies are cached. Then you end up with all sorts of horrible kludges in the OS and apps to detect whether your device is "on net" or "off net". And then you start to wonder what is the definition of "on net" and "off net" when there's so many different ways of traversing the boundary. You could be on-net via proxy bypass for one HTTP site. And off-net for another HTTP site via a proxy (steered via a .pac file). And then you could be on-net for SSH (no proxy) via an IP direct to a trusted 3rd party partner hosted system connected via a private gateway. But off-net to a cloud service via an Internet firewall (steered via private backdoor routes). I did a project where I ended up putting in hundreds of external DNS entries into an internal self-rooted DNS, together with hundreds of firewall rules, and a proxy.pac file as long as your arm for proxy bypass (which is then promptly mis-interpreted or ignored by every different version of browser ever written) And those entries had to be kept in synch every time the external info changes. And tested for every browser release. There lies operational madness. > On Aug 5, 2013, at 1:23 AM, christian.jacquenet@orange.com wrote: > >> WG, >> >> I've read (and commented) this draft some time ago. This document is useful and I think it should move forward. >> >> Regarding the ULA-related discussion, I don't think the document should simply ignore the potential use of such addresses, e.g., because our experience of providing IPv6 VPN service to our corporate customers since 2009 has shown that some of these customers ask for (and sometimes demand) a ULA-based addressing plan, mostly because these customers still think that private addressing provides some form of security. >> >> This is partly an educational matter which we usually address by organizing training sessions within the enterprise, but the reality is that we could never avoid the discussion about ULA usage with these customers. And there are indeed a few of them who have chosen to go for an ULA addressing plan, at least for the duration of field trials or even pilot deployments. >> >> I would therefore expect the draft to mention ULA addresses. But I would also expect the draft to clearly discourage the use of such addresses, for the reasons mentioned by Lorenzo in his recent message. >> >> For the sake of readability, I would (1) remove the ULA-related text from Sections 2.4.2, 3.1 and 6.3, and (2) dedicate a specific "On ULA Addressing and Its Foreseen Implications" subsection in Section 2.6, which would better elaborate on the warnings highlighted in the aforementioned sections (e.g., Section 3.1's "use of PI space obviates the need for ULAs"). >> >> A few additional typos: >> >> Section 2.1, page 7: "...after all initial *deployment* has been completed." >> Section 2.2.2., page 9: s/recommend/recommended >> Section 6.3, page 26: s/enterprise/university (second paragraph), s/campus enterprise/campus >> Section 8, page 27: s/Jaquenet/Jacquenet >> >> Cheers, >> >> Christian. >> >> -----Message d'origine----- >> De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de Fred Baker >> Envoyé : dimanche 4 août 2013 20:00 >> À : v6ops@ietf.org >> Objet : [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC >> >> This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. >> >> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> > > • Make things as simple as possible, but not simpler. > Albert Einstein > > -- Regards, RayH From markzzzsmith@yahoo.com.au Mon Aug 5 14:39: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 598F421F9DF0 for ; Mon, 5 Aug 2013 14:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_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 h0u-oSSJjQDB for ; Mon, 5 Aug 2013 14:39:20 -0700 (PDT) Received: from nm39-vm1.bullet.mail.bf1.yahoo.com (nm39-vm1.bullet.mail.bf1.yahoo.com [72.30.239.145]) by ietfa.amsl.com (Postfix) with ESMTP id D18CA21F9E43 for ; Mon, 5 Aug 2013 14:39:10 -0700 (PDT) Received: from [98.139.212.148] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:39:09 -0000 Received: from [98.139.212.201] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:39:09 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:39:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 145080.11090.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 46475 invoked by uid 60001); 5 Aug 2013 21:39:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1375738749; bh=gYAFSU3pKOmPWsQPWbQNVx/u7So+IzM8OspqNEzxR6A=; 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=bFBKeAnvvELREYF5XZrfj2pzdPoEtgjsJgVYY5lilG5GjtdfeS6XybGiiseUAGc1gfm83djugAoRf2GiyOrgbnHknW7EcwzqcHNKjPBl/MBsDnPt6BHPvBOiCSO7/AzW4CnYiuZv7/RFHFx7sk2dhUeJN7y1IQ2KVwx7A3m6tOM= 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=4Ju9ozwRTva/LbSApyZvArEXHNTJJ4bmxaYF2Pe9WCrVZ5ujQiQ3nmCMSJO4kfsQ0MuUeeyJj51XdZZuv6y2DNDMr1Kaa0c8P+I1FDiBkvZKkQiGJvJV7H/PS5Ose2r6vdOkHKDFNe+mmPGJ07AHQNitVBaDt5bZozAIH7N0Xww=; X-YMail-OSG: mIrO29EVM1k1YTebP_VKSPVgbrCE2q5fdP9WYR4ZIuRbmYI k9Bb5ZncoccubSN1LmRa9cUfvZvlzlsOSQFbM.bnznSVRBMCtbFrO.MVMp2A b4NgXwGoBfM9znw7.RCvzTH6IKIHfg6GKtqCwrzy_WhMFBBsk_rGxIuEZCG3 Q2bRNIWAHtNuqCBW522raNv4sT4YvRZDiGdbFuDr_xiwZuOFT9W_woRXFb77 xklu7Hrn8enPmHBMYv6b2Y9wKt0rrsHZ58_mZ8a4_bx_yX5BCj4zq6PXaQwb dnzJfpvUWbmWCM9384ZPi3L3sw0u7vW5usL.AalfmJeOXvNO.sYSxsNXPTRT Q639mkANq.uK1IRjcFUGe789tWhYu.K2Lcuzov.B0atT6qmcQWz2posafgwb i8CUo8vb7lcTqg3wZh_dh4OEk6.bAtTP1pFe9lVAInhLtqe1AMSzHLxB1R6T ZOG2e_u0mRM96KD7odKE.IaBQieErIFvufydZCUqdcaprWaiodeebDIelxGN SdVc.s0yC54m74JdEmpewTkeMHC95hF.702Vh.Tsv2jCRpVc4sp_5rCZgMGY aKGA9BFhAYtqQ7YDNPcSMSG9BgEe_ZfgPkg_vWs5GEHeXNg-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Mon, 05 Aug 2013 14:39:08 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.Cj4gVG86ICJjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb20iIDxjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb20.OyBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPiBDYzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogVHVlc2RheSwgNiBBdWd1c3QgMjAxMyAyOjM3IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> Message-ID: <1375738748.38980.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 5 Aug 2013 14:39:08 -0700 (PDT) From: Mark ZZZ Smith To: "Fred Baker \(fred\)" , "christian.jacquenet@orange.com" , Lorenzo Colitti In-Reply-To: <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:39:25 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Fred Baker (fred) =0A> To: "christian.jacquenet@orange.com" ; Lorenzo Colitti =0A> Cc: "v6ops@ietf.org" =0A> Sent: Tuesday, 6 August 2013 2:37 AM=0A> Subject: Re: [v= 6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC=0A> =0A> A thought = - tell me if this makes sense.=0A> =0A> In IPv4 networks, it is pretty comm= on to in some way advertise the address of an =0A> internal-only server and= then block access to it at the firewall. If you want =0A> Cisco examples, = try wwwin.cisco.com or irp-view13.cisco.com - dig them, ping =0A> them, and= traceroute towards them. From my perspective, in IPv4 or in IPv6, the =0A>= firewall rule makes little sense except as an additional defensive layer; = one =0A> should not advertise the name to the great unwashed, and whether o= r not one =0A> does, one should give the system an address that is not adve= rtised to the great =0A> unwashed. The next question, of course, is how to = achieve that - does one only =0A> advertise half of their address space? An= nounce multiple prefixes? The ULA, =0A> whatever its other ills or uses may= be, is an address that is not advertised =0A> upstream, and therefore a ve= ry logical address for an internal-only system in an =0A> IPv6 network.=0A>= =C2=A0=0A=0AMakes sense to me. I think ULAs would be better than globals wi= th ACLs blocking access for these sorts of sites because ULAs aren't global= ly reachable, and even if they're accidentally leaked, their external reach= ability should be very limited. If the default unreachability of ULAs isn't= good enough, ACLs blocking the fc00::/7 on the edge of the network would b= e further protection.=0A=0AThe nature of globals is that they're intended t= o provide global reachability by default. ULAs are not intended to provide = global reachability, and even if leaked, probably won't provide global reac= hability reliably, which will also discourage their use for "global purpose= s". So if you don't want global reachability, it would seem to me that ULA = is the better address space to use.=0A=0A> I scratch my head a bit on the v= ehemence that seems to come across in=C2=A0=0A=0A> discussions of the ULA. = I understand that there is a strong distaste for NATs, =0A> and I share it = in the stateful case. It sounds a bit like the baby is being =0A> discarded= with the bathwater, though, in the case of a system that one =0A> doesn't = want to have communicating with the great wide world.=0A>=C2=A0=0A=0AI don'= t really understand it either. The value I see in ULAs is that it is your o= wn local address space, meaning that you're in complete charge of it, unlik= e the global address space you have been given by somebody else. It seems t= o me that one way to increase robustness is to reduce external dependencies= . Using a local address space, that is used in preference to a global addre= ss space when there is a choice, in general should be more robust because y= ou have absolute control over it.=0A=0A> Am I out to lunch? If so, in what = way?=0A> =0A> On Aug 5, 2013, at 1:23 AM, christian.jacquenet@orange.com wr= ote:=0A> =0A>> WG, =0A>> =0A>> I've read (and commented) this draft some = time ago. This document is =0A> useful and I think it should move forward.= =0A>> =0A>> Regarding the ULA-related discussion, I don't think the docume= nt should =0A> simply ignore the potential use of such addresses, e.g., bec= ause our experience =0A> of providing IPv6 VPN service to our corporate cus= tomers since 2009 has shown =0A> that some of these customers ask for (and = sometimes demand) a ULA-based =0A> addressing plan, mostly because these cu= stomers still think that private =0A> addressing provides some form of secu= rity. =0A>> =0A>> This is partly an educational matter which we usually ad= dress by organizing =0A> training sessions within the enterprise, but the r= eality is that we could never =0A> avoid the discussion about ULA usage wit= h these customers. And there are indeed =0A> a few of them who have chosen = to go for an ULA addressing plan, at least for the =0A> duration of field t= rials or even pilot deployments.=0A>> =0A>> I would therefore expect the d= raft to mention ULA addresses. But I would =0A> also expect the draft to cl= early discourage the use of such addresses, for the =0A> reasons mentioned = by Lorenzo in his recent message. =0A>> =0A>> For the sake of readability,= I would (1) remove the ULA-related text from =0A> Sections 2.4.2, 3.1 and = 6.3, and (2) dedicate a specific "On ULA Addressing =0A> and Its Foreseen I= mplications" subsection in Section 2.6, which would =0A> better elaborate o= n the warnings highlighted in the aforementioned sections =0A> (e.g., Secti= on 3.1's "use of PI space obviates the need for =0A> ULAs").=0A>> =0A>> A = few additional typos:=0A>> =0A>> Section 2.1, page 7: "...after all initia= l *deployment* has been =0A> completed."=0A>> Section 2.2.2., page 9: s/re= commend/recommended=0A>> Section 6.3, page 26: s/enterprise/university (se= cond paragraph), s/campus =0A> enterprise/campus=0A>> Section 8, page 27: = s/Jaquenet/Jacquenet =0A>> =0A>> Cheers,=0A>> =0A>> Christian.=0A>> =0A>>= -----Message d'origine-----=0A>> De : v6ops-bounces@ietf.org [mailto:v6o= ps-bounces@ietf.org] De la part de =0A> Fred Baker=0A>> Envoy=C3=A9 : dima= nche 4 ao=C3=BBt 2013 20:00=0A>> =C3=80 : v6ops@ietf.org=0A>> Objet : [v6= ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC=0A>> =0A>> This is = to initiate a two week working group last call of =0A> http://tools.ietf.or= g/html/draft-ietf-v6ops-enterprise-incremental-ipv6. Please =0A> read it n= ow. If you find nits (spelling errors, minor suggested wording changes, =0A= > etc), comment to the authors; if you find greater issues, such as disagre= eing =0A> with a statement or finding additional issues that need to be add= ressed, please =0A> post your comments to the list.=0A>> =0A>> We are look= ing specifically for comments on the importance of the document =0A> as wel= l as its content. If you have read the document and believe it to be of =0A= > operational utility, that is also an important comment to make.=0A>> ___= ____________________________________________=0A>> v6ops mailing list=0A>> = v6ops@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/v6ops=0A>> =0A>= > =0A> ____________________________________________________________________= _____________________________________________________=0A>> =0A>> Ce messag= e et ses pieces jointes peuvent contenir des informations =0A> confidentiel= les ou privilegiees et ne doivent donc=0A>> pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu =0A> ce message par erreur, v= euillez le signaler=0A>> a l'expediteur et le detruire ainsi que les piece= s jointes. Les =0A> messages electroniques etant susceptibles d'alteration,= =0A>> Orange decline toute responsabilite si ce message a ete altere, defo= rme ou =0A> falsifie. Merci.=0A>> =0A>> This message and its attachments m= ay contain confidential or privileged =0A> information that may be protecte= d by law;=0A>> they should not be distributed, used or copied without auth= orisation.=0A>> If you have received this email in error, please notify th= e sender and =0A> delete this message and its attachments.=0A>> As emails = may be altered, Orange is not liable for messages that have been =0A> modif= ied, changed or falsified.=0A>> Thank you.=0A>> =0A> =0A> =C2=A0=C2=A0=C2= =A0 =E2=80=A2 Make things as simple as possible, but not simpler.=0A> Alber= t Einstein=0A> =0A> _______________________________________________=0A> v6o= ps mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinf= o/v6ops=0A> From markzzzsmith@yahoo.com.au Mon Aug 5 14:49: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 A32F421F9CCC for ; Mon, 5 Aug 2013 14:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_40=-0.185, 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 w34T7EX2nctw for ; Mon, 5 Aug 2013 14:49:16 -0700 (PDT) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) by ietfa.amsl.com (Postfix) with ESMTP id DD4C921F9CC3 for ; Mon, 5 Aug 2013 14:49:15 -0700 (PDT) Received: from [98.139.212.151] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:49:15 -0000 Received: from [98.139.212.243] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:49:15 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:49:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 349596.37046.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 44347 invoked by uid 60001); 5 Aug 2013 21:49:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1375739355; bh=EfjI6/pcyCmoJdJHPDzEGkZtAFasREj0o/lYOIUvucg=; 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=ZVT0PARWthmo0m60kxUIS5jI9gc5F70dGXjA+ZHI9at7W70fOXHGDLnvJ2UHz6kjMjdkqNWBlXzAkL62qIXbg1xyzfHMxuW4EhwhvWWcYuX0wwXJlo9YdFA2e5VLdv5kHvIEVvSjpjZ/OLbvgFaeJQVdXkauENRaH27M87xnOGI= 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=d8JE89g37003rbCVAAe3qvAfNZQnMtAkUhyHpnmmobQO3ple/PD9E3xI3GWVrNntH8COt9VYpcGmIpL0wqPHwrgo20pffSGnaY2eSqxgCoZfJ1HdtMlVrmN2rB6XSarM8vTgIri9Ggn4Z/M9Q8dq4+i8rVkGWbT9NlMcy9gJfbU=; X-YMail-OSG: 9zGTou8VM1mypmqkA6J42gjzJO8MiC5.rGxYWj4s7Xc5AcT LtoQdpXiifLZL0rApUdTA4F9jWbm3VX93z3_mrMKkEmofbA4uq9llg.n6.B5 zUcNF_xyrASwK3saC55Q_V3xXzdvbqLHUfs0zXjDet_vn_6o4rY21DwLmEEq Xia_i4gZZNyZqiTYyDnM6Bii2xfUF7eyIW.FqzCwOpBgf3cQSpKUA.r_.kkN cX4zb5Ocoi0MO729jH42rA6QCGBUlVm1cXXJeTrgweqjWFZuKF1AQ_NCrvJ4 CxmS.xqLGRH13R4xJY1ZxxNAsPpnS7mnqGLmcbNZJOqIvn.amO96QiMYyxcE I3exkQdpdVi1GFp9j236mNKHrRbeAfNSPQoXDRwSkmmuHqNYvEj7fgKVajFb yD1Kp0tlzotAB9y_k5BQD1h.L3H36Izub.pJMVCnWZ6j01em2vaCjFu3Nlj1 7oDv6CgMew0jTfxjgRYnTqmbHQ3Pl21eMPniQCPiJ34PoTkJmbVpWRmpg7Bl aukhiz0ccxhwwN20Gc8vIFIZ6K8J6Q60GQCBfgdhjW0LBvTjWSDZmFnWRKaE TUPYbt9wqGuj.gWaW Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Mon, 05 Aug 2013 14:49:15 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBUbzogRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPjsgImNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbSIgPGNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbT47IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBUdWVzZGF5LCA2IEEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <1375738748.38980.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1375739355.31146.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Mon, 5 Aug 2013 14:49:15 -0700 (PDT) From: Mark ZZZ Smith To: "Fred Baker \(fred\)" , "christian.jacquenet@orange.com" , Lorenzo Colitti In-Reply-To: <1375738748.38980.YahooMailNeo@web142501.mail.bf1.yahoo.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] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:49:21 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mark ZZZ Smith =0A> To: Fred Baker (fred) ; "christian.j= acquenet@orange.com" ; Lorenzo Colitti =0A> Cc: "v6ops@ietf.org" =0A> Sent: Tuesda= y, 6 August 2013 7:39 AM=0A> Subject: Re: [v6ops] draft-ietf-v6ops-enterpri= se-incremental-ipv6 WGLC=0A> =0A> =0A> =0A> =0A> =0A> ----- Original Messag= e -----=0A>> From: Fred Baker (fred) =0A>> To: "christian= .jacquenet@orange.com" =0A> ; Lorenzo Colit= ti =0A> =0A>> Cc: "v6ops@ietf.org" =0A= >> Sent: Tuesday, 6 August 2013 2:37 AM=0A>> Subject: Re: [v6ops] draft-i= etf-v6ops-enterprise-incremental-ipv6 WGLC=0A>> =0A>> A thought - tell me = if this makes sense.=0A>> =0A=0A>> =A0=0A> =0A> I don't really unders= tand it either. The value I see in ULAs is that it is =0A> your own local a= ddress space, meaning that you're in complete charge of it, =0A> unlike the= global address space you have been given by somebody else. It seems =0A> t= o me that one way to increase robustness is to reduce external dependencies= . =0A> Using a local address space, that is used in preference to a global = address =0A> space when there is a choice, in general should be more robust= because you have =0A> absolute control over it.=0A>=A0=0A=0AJust to clarif= y though, I'm not for NAT in any form. I think NPT is a lot better, however= I still think that because it hides the external identity of hosts from th= emselves that it creates constraints that are better to avoid. Through expe= rience, I've come to the view point that global uniqueness of identity (thr= ough globally unique addresses) is a property that is nearly as important a= s global reachability for troubleshooting and security.=0A=0ARegards,=0AMar= k. From lorenzo@google.com Mon Aug 5 15: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 6DF3721F9C20 for ; Mon, 5 Aug 2013 15:15:26 -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 TX0VXO51lDJS for ; Mon, 5 Aug 2013 15:15:26 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0331321F9AA8 for ; Mon, 5 Aug 2013 15:15:25 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd6so6692054obb.5 for ; Mon, 05 Aug 2013 15:15:25 -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=ioygnE9ehdYhDdqj9t7HVPc/+kcYlFrm5z2RlB1lwmA=; b=Glg32gDs/XbmJUkTr3DWj7RGHazWqTyKPWijjz8yN1Zo5UymqLmYdXolE7nIY1CZYY EHndlRluoczpfVVqh/vGJtf6C9vTyEtAIyAOXtT5nv/KT43P+0f3vOKBSz38qGnCnsv7 4+vPO+9lrrBLzQMvrOXXhZm6r0ywjesXqFpPYIJG4dTZLtyma7s5FkWXsS6Xxo4JzGA0 6U9uUNiwk/0NanFdu2PwSxsprANtFnlC5BHUHhT4M5GLAQoTC0xz1lknl4tx6wXOtfxt ZQv+E3YIHQC2EXkklphw3ByjWGPBVkPKsOrSXw5+ZzqOQKz6PiZM1IlcKvcm/GoBPC1r Wb+g== 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=ioygnE9ehdYhDdqj9t7HVPc/+kcYlFrm5z2RlB1lwmA=; b=is/Rpm3MoaIZ3YGy4hcvaSbdfwSUBlQnOS9MLUp5K4dNnA23uoa+A9KIHge4qVUhZn htx4DzyyjX+Sy92XtBWntJ4dzWtZFFpym1M8NFuYFzRUc24mpyDSJa2ppUYY+lrpq3ZU IZkdYMx1QVHQEqy0LQdFfSgrDq4SeaYy3OxoBXB+mMCdJp/ASPC5lMdfGpcr6vq8JESY fObnZvssozzBj6hFHX02oTFAXaTRSFsMUf2EXCII3f9iUbx14Yb0PyEr4TNNGJ9pzaBL 08bbGLOVtF9Pt7nk7fRMRVONavLclR8NHWHBar/ObsCMTQaode7eydO+Rt0WEcZ5+02S emQg== X-Received: by 10.43.60.139 with SMTP id ws11mr1783041icb.12.1375740925275; Mon, 05 Aug 2013 15:15:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 5 Aug 2013 15:15:05 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> From: Lorenzo Colitti Date: Tue, 6 Aug 2013 07:15:05 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=bcaec51a8946279f8e04e33aa5d8 X-Gm-Message-State: ALoCoQnuSrCxcSOhS7+ZvV4vxtXHUHsTWtM8Al9LuHyV6+YTDsNNQ7uj+EFnpnBuwGnRMB6xE7fhnlK42lkAsKRB7HcoU12sMLU0muf+0rrJErQQLr1ueykYLFmIJjc8eSVkJrUoHeN0c9DMhzOKHQbgnbdwsxcgnftzKcvlgW9KLOTXUqr0Z0S5NofC3X9wZae943SH0kT+ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:15:26 -0000 --bcaec51a8946279f8e04e33aa5d8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 1:37 AM, Fred Baker (fred) wrote: > I scratch my head a bit on the vehemence that seems to come across in > discussions of the ULA. I understand that there is a strong distaste for > NATs, and I share it in the stateful case. NAT creates problems for applications not only in the stateful case, but in the stateless case as well, because with NAT the client must be prepared for a situation where it does not know its own address. This complicates peer-to-peer networking applications such as video chat. --bcaec51a8946279f8e04e33aa5d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 6, 2013 at 1:37 AM, Fred Baker (fred) <fred@cisc= o.com> wrote:
I scratch my head a bit on the vehemence tha= t seems to come across in discussions of the ULA. I understand that there i= s a strong distaste for NATs, and I share it in the stateful case.

NAT creates problems for applications not only in the s= tateful case, but in the stateless case as well, because with NAT the clien= t must be prepared for a situation where it does not know its own address. = This complicates peer-to-peer networking applications such as video chat.
--bcaec51a8946279f8e04e33aa5d8-- From fred@cisco.com Mon Aug 5 16:27: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 1CBEB21F9E27 for ; Mon, 5 Aug 2013 16:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.849 X-Spam-Level: X-Spam-Status: No, score=-110.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 sdSqcOEze3pB for ; Mon, 5 Aug 2013 16:27:08 -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 92B8421F9D0A for ; Mon, 5 Aug 2013 16:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=818; q=dns/txt; s=iport; t=1375745228; x=1376954828; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a3yD81kfoCKiuuiB3CF8zZO/kDb8n+K2JWWRIn5btr4=; b=k7adOl3LocY6vXNq7vOzjcT39kM9BWO4dVKLTNf7XkMgiZfv8Vojqny7 WIy9gpamd+yCE3iNYg3hq+U7AWGNO0+69mJzg46wHw8c1Jpdb8+IJls/S SbIDobrcnTPaOuHtMFQnlrByExi+Wr9PzS4iPSQ2j67U78NFhUmlFtkhB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAKszAFKtJV2c/2dsb2JhbABbgwaBBYJJvC+BJBZ0giQBAQEDAXkFCwIBCBgKJDIlAgQOBQiIAga1UY9kAjEHgxl0A4hyoD2DF4Iq X-IronPort-AV: E=Sophos;i="4.89,822,1367971200"; d="scan'208";a="243896854" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2013 23:27:08 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r75NR8tN021312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 23:27:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 18:27:07 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkjNNdzjT7voctUaLF3m4W8p2PA== Date: Mon, 5 Aug 2013 23:27:07 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 23:27:14 -0000 On Aug 5, 2013, at 3:15 PM, Lorenzo Colitti wrote: > On Tue, Aug 6, 2013 at 1:37 AM, Fred Baker (fred) wrote: > I scratch my head a bit on the vehemence that seems to come across in dis= cussions of the ULA. I understand that there is a strong distaste for NATs,= and I share it in the stateful case. >=20 > NAT creates problems for applications not only in the stateful case, but = in the stateless case as well, because with NAT the client must be prepared= for a situation where it does not know its own address. This complicates p= eer-to-peer networking applications such as video chat. I'm not going to argue one way or the other. The substance of my comment re= lated to an address that was not intended to be globally reachable. our tho= ught there?= From brian.e.carpenter@gmail.com Mon Aug 5 17:20: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 01DE721F9BCA for ; Mon, 5 Aug 2013 17:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91jJFiSHdjpr for ; Mon, 5 Aug 2013 17:20:37 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6238621F9BC9 for ; Mon, 5 Aug 2013 17:20:37 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc17so3976857pbc.18 for ; Mon, 05 Aug 2013 17:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G39t+hD6f7PcoD4rSFk4mdhmIqGzX1+FppD/MTj3AeY=; b=Rzr2rfbeMWKH9vP9n+M8WZPkFrMAiDV8liWfUQiC2wURAvpVLE4AtN9i4+Nm8PFurC vO/tflECMVOP/CIkZwT6xbN1y9ToENyYQTnMW7heBMleFfOAbYIe5I/RkWOd6mmM8Xcw OLhXIzNLeWZ3qZGBfMBNNwuCy3dSZROAQd6tz0igVNeP80GwVTjEkAZ2GMiNEpgWT9rY GDNqfU1ITlLPB4UYRTS/0eYMhOD9FT+myZ7OnGva0+VqS2pO9+5ZclqfIOQylOSzIFkL 4MDWSV9sInt3CoPumXlh0iqKtMyiB2/vUGepYbKjsgHl54R5FP2tqEwmW6Di1il4a2xS e3PQ== X-Received: by 10.68.211.138 with SMTP id nc10mr25074536pbc.162.1375748436775; Mon, 05 Aug 2013 17:20:36 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id eq5sm1570710pbc.15.2013.08.05.17.20.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 17:20:35 -0700 (PDT) Message-ID: <5200414F.4010905@gmail.com> Date: Tue, 06 Aug 2013 12:20:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <1375738748.38980.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1375739355.31146.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1375739355.31146.YahooMailNeo@web142505.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:20:38 -0000 On 06/08/2013 09:49, Mark ZZZ Smith wrote: ... >> I don't really understand it either. The value I see in ULAs is that it is >> your own local address space, meaning that you're in complete charge of it, >> unlike the global address space you have been given by somebody else. It seems >> to me that one way to increase robustness is to reduce external dependencies. >> Using a local address space, that is used in preference to a global address >> space when there is a choice, in general should be more robust because you have >> absolute control over it. >> > > Just to clarify though, I'm not for NAT in any form. I think NPT is a lot better, however I still think that because it hides the external identity of hosts from themselves that it creates constraints that are better to avoid. Through experience, I've come to the view point that global uniqueness of identity (through globally unique addresses) is a property that is nearly as important as global reachability for troubleshooting and security. It seems to me that any IETF consensus document should make it clear that ULAs are for internal use only, that GUAs should be used in parallel for external access, and that NPTv6 is (if mentioned) only an experimental specification. Also note that draft-liu-v6ops-ula-usage-analysis and draft-liu-v6ops-running-multiple-prefixes are around and cover this topic. Brian From lorenzo@google.com Mon Aug 5 19:03: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 5DE3421F9E35 for ; Mon, 5 Aug 2013 19:03:11 -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 QvTm9tuSvmy8 for ; Mon, 5 Aug 2013 19:03:11 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D1F3121F9E48 for ; Mon, 5 Aug 2013 19:03:10 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so7824639oag.4 for ; Mon, 05 Aug 2013 19:03:10 -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=+nSqYgw6ilZrFdeBrmLSFVf+wNhMlzb2CdVre2lfKwk=; b=BlzUD09yoAmFikvPKu4vG2WTRAVS9Dd7+TcAdN31vgvqK2qqn7falxKj33MhLYqeDp l3hqYoV9GM9entINq2lknChFFEEkEQCF96H+q8NZB3GwvFkCNAadAKRmvEdPZWrDdaMu 1og/Beb0y02WBznlj8EJQepXF26zu5DAxFlLo8N24+q5OFKelIaAChqwui1CCsavFlKM mEZA/LsM3X8e9koLw9pUy+f8Kpf7AYaPdTMFj9FxzJvBl/HGR/x6irBvaeMbDGkQo99+ +dz/nBg8/SGndJ/25VlRJa9YbP0Mc0YWyEn7W09/sz8WiD1S6KeSW5+vFYbBLRScHwqm +HwA== 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=+nSqYgw6ilZrFdeBrmLSFVf+wNhMlzb2CdVre2lfKwk=; b=gmUZvyVZWvZlk3uFBEfj9eQITqPBcEa5weuJOwMrUP+MTVVcIvUJMLnnSu1ikffnXK zQY1j+cwAqQHdpGFGTjBhEMxxiQ31McRN64w8wH3JQSw25cfcXRDXl80xsvysY+oTVT+ l/iH9dKGjnFS5zY4FPdKQtUbCcJzcvyZr8Pbx11bywUM7eA7dXk4UuPxHRDQEwqes2ML c4r/DmVeBGJNgIboyQL6RkB/73mcUTw7dGWa3tVkX3wQvHf7SeuuEcy1FmxKzOvMsgOB tevAMRinTaPWgB+X4fXbCacOG6bYKRAQE3R5gCvY240fZGdfbnV1SJ6H00c6EpOA1MXz qwZQ== X-Received: by 10.50.18.5 with SMTP id s5mr58288igd.6.1375754590191; Mon, 05 Aug 2013 19:03:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 5 Aug 2013 19:02:50 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> From: Lorenzo Colitti Date: Tue, 6 Aug 2013 11:02:50 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e013cc1c4a5b36c04e33dd3f1 X-Gm-Message-State: ALoCoQl6fKLMfN7Oj8pe8sR6xMkKwUmSjcFVroh5ztRESXHfBDc1KnFytz5zLtqOxe4oDrekAEW+fHO7oaOmb7WIa5NMWGh/Ad4OLrgIdpfUTBU2rjGngrB8ezrHo/qwu+3dLYUTd5ELKIp3k+GWvAIqWdE3g0V4CYUppaqLmfNphGc+KUyswQY1MNdM5T4l73jpnFPZU3cv Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:03:11 -0000 --089e013cc1c4a5b36c04e33dd3f1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) wrote: > > NAT creates problems for applications not only in the stateful case, but > in the stateless case as well, because with NAT the client must be prepared > for a situation where it does not know its own address. This complicates > peer-to-peer networking applications such as video chat. > > I'm not going to argue one way or the other. The substance of my comment > related to an address that was not intended to be globally reachable. our > thought there? But if it's not indended to be globally reachable... then why is it behind a NPTv6 box? I'd argue is that it *does* need to be globally reachable, but "only for certain traffic". For example, "TCP/443 replies from the Windows Update server". The point is that when people say, "X will never do Y" sometimes it turns out that "never" just means "in the next six months", and what ends up happening is that they need to deal with additional complexity once Y becomes a requirement. --089e013cc1c4a5b36c04e33dd3f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) <fred@cisc= o.com> wrote:
>= NAT creates problems for applications not only in the stateful case, but i= n the stateless case as well, because with NAT the client must be prepared = for a situation where it does not know its own address. This complicates pe= er-to-peer networking applications such as video chat.

I'm not going to argue one way or the other. The substance = of my comment related to an address that was not intended to be globally re= achable. our thought there?

But if it's not indended to be globally reachable... then why is it beh= ind a NPTv6 box? I'd argue is that it *does* need to be globally reacha= ble, but "only for certain traffic". For example, "TCP/443 r= eplies from the Windows Update server".

The point i= s that when people say, "X will never do Y" sometimes it turns ou= t that "never" just means "in the next six months", and= what ends up happening is that they need to deal with additional complexit= y once Y becomes a requirement.
--089e013cc1c4a5b36c04e33dd3f1-- From lorenzo@google.com Mon Aug 5 19:05: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 1D14921F9B12 for ; Mon, 5 Aug 2013 19:05:10 -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 EwCoV1KJPKEO for ; Mon, 5 Aug 2013 19:05:09 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9D47B21F8BB7 for ; Mon, 5 Aug 2013 19:05:09 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g12so7844113oah.20 for ; Mon, 05 Aug 2013 19:05:09 -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=9dCSCQWiv9cg/h1bg94fAiUQ5LdQFG/2Xsz5WT5bJLE=; b=RBtqTjrQc2mGLBwHCo5cZfHDfhFkYL67cXziHf9tjKaYSddefjz9V5ab4sSr1YcIxo 6K7uxnzpe3lK4PU3MU2D4av89Ybwxn9b8Zos4gxps8surGhX2hz+gOVskSEbXa77HneT FMQDodu2D+qnU7xZgkjpdSxxbNbbvNreftBEhd5lrCE/bll4qUosHhRzgL/HAtX0PY+C NQE50bY7HWmEm+zhsbxh3DHmju/6ix9PJzAkKZKpNoS0ERCv3rzQzEu/8+09v/ha10Rc 4NNTvDXR0KBMsSgCbT3gG8zCxLDbVugbsR61e+dPZXGX89lLJo/6Zv3qs77+EVGQn/l0 352w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9dCSCQWiv9cg/h1bg94fAiUQ5LdQFG/2Xsz5WT5bJLE=; b=IhDIxvDV2j3Vt/K+OIO4s4E6GPl3f7izTYbe9vKyGqLTvNTVqP6ut5HogClYRqH445 j0XwVZ+3GlQ+FDz7I7WUra7MOweN0Fbl+InEJm2IDXPZzsk3uf0KEytW3ZcBvt/6caGU T6J0G506s+jO3/UC+KmE/MO8ixsQuIouuMSsA7wLdsuW4bF0UNXRO4WB7k1cFIEYpfhK m9y0lmmlgwpzswDnRzdrdCTM9F182h1N+v4+dIfwuiCEqFD9L4QMnOKmtYs8Mq1aA94h rwMwVYcs6QJtqVOSNzMhXhDaI/1Olhftn9iHaCEibPpMnq529j/dK+V18euQFPOIfYCd WxGA== X-Gm-Message-State: ALoCoQmWmMnB2dSor5Ajmd5yxDBACjCj3MqmaAyUrhYNzbjYJs2bQMCSQTWceQzfQUcgrqdS4/BH3R2q82UGHhlBRZRn9tZ1vxipYhPnC+xqAD8gN6P9riLCmHKgFgrzzvuJaMoztG+6ohlNrfEZXC8uQh/ohVNsQSQRSHnnIALbAHtPcPGDYdCEt5hm6KnoLjAmUYQbrkpH X-Received: by 10.50.9.102 with SMTP id y6mr54456iga.17.1375754708942; Mon, 05 Aug 2013 19:05:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 5 Aug 2013 19:04:48 -0700 (PDT) In-Reply-To: <5200414F.4010905@gmail.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <1375738748.38980.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1375739355.31146.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5200414F.4010905@gmail.com> From: Lorenzo Colitti Date: Tue, 6 Aug 2013 11:04:48 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c31b66b9b13004e33dda5d Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:05:10 -0000 --001a11c31b66b9b13004e33dda5d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 9:20 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > It seems to me that any IETF consensus document should make it clear > that ULAs are for internal use only, that GUAs should be used in parallel > for external access, and that NPTv6 is (if mentioned) only an experimental > specification. > Yes, yes, and yes. > Also note that draft-liu-v6ops-ula-usage-analysis and > draft-liu-v6ops-running-multiple-prefixes are around and cover > this topic. > Which is why that debate does not belong in this draft and the authors would be wise to remove this text so this draft can advance while we discuss those documents. --001a11c31b66b9b13004e33dda5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 6, 2013 at 9:20 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
It seems to me th= at any IETF consensus document should make it clear
that ULAs are for internal use only, that GUAs should be used in parallel for external access, and that NPTv6 is (if mentioned) only an experimental<= br> specification.

Yes, yes, and yes.
=
=A0
Also note that draft-liu-v6ops= -ula-usage-analysis and
draft-liu-v6ops-running-multiple-prefixes are around and cover
this topic.

Which is why that debate do= es not belong in this draft and the authors would be wise to remove this te= xt so this draft can advance while we discuss those documents.
--001a11c31b66b9b13004e33dda5d-- From fred@cisco.com Mon Aug 5 19: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 30A5921F8EA8 for ; Mon, 5 Aug 2013 19:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.821 X-Spam-Level: X-Spam-Status: No, score=-110.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 mROmq4DsL5nJ for ; Mon, 5 Aug 2013 19:24:57 -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 49AA921F8EB3 for ; Mon, 5 Aug 2013 19:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=383; q=dns/txt; s=iport; t=1375755887; x=1376965487; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y1FSEWzPuatffKmwWrwMp0NmIng3PaTTT7OQV49KXSE=; b=GOWGpVJK3/YYhayMDDWSYykCAyU3DkvDOeuQBlbjgqvrKuUngKdodNlr zM5nIbRRgYZ97qeNceHujvHcC2I57GziNMJqow2smLMhfbafuRK4c12Qr WX1EOD2MgDtsXgKfthQoLdcHYnVKtIp/HvI2x3GCtDxjNYrB1CmXMu53n I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAN9dAFKtJV2c/2dsb2JhbABbgwaBBYJJvDGBKBZ0giQBAQEEeRACAQgYCiQyFwENAgQOBQiICLVij2QCMQeDGXQDiHKgPYMXgio X-IronPort-AV: E=Sophos;i="4.89,823,1367971200"; d="scan'208";a="243840528" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 06 Aug 2013 02:24:45 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r762OiEH019706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 02:24:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 21:24:43 -0500 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkkwc/O+ewochqUWEiCocbX9qAQ== Date: Tue, 6 Aug 2013 02:24:42 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B96ECA8@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:25:03 -0000 On Aug 5, 2013, at 7:02 PM, Lorenzo Colitti wrote: > But if it's not indended to be globally reachable... then why is it behin= d a NPTv6 box? I'd argue is that it *does* need to be globally reachable, b= ut "only for certain traffic". For example, "TCP/443 replies from the Windo= ws Update server". Where in *my* comment did I mention a NPTv6 box? From victor@jvknet.com Mon Aug 5 19:34: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 BD73B21F9D15 for ; Mon, 5 Aug 2013 19:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeCw1XlsuE1U for ; Mon, 5 Aug 2013 19:33:59 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id EEB5421F9A7D for ; Mon, 5 Aug 2013 19:33:58 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id s1so2073604qcw.23 for ; Mon, 05 Aug 2013 19:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=3AZmmnaEDhsNEXVVoTLwx2w+3Epiv0Lc+ZTTmjH3ij8=; b=oemACWioddM64EmZJSfhV0cBPyq4GjxiXGvPE1cO99Ff0pEynF5vk0sJsDsnR3DwUn MQYwTYfqd/89hSnzvjABAilWGZlhmdZH+ppAx/o3AK94sXsdCApxnPFyWhjij+tPIGhT pHPEJx8yJDtJDisz0WBowhyTwITaA29Urj/YkU5+B71Jg2e3VWR+WO7kFc5uaHxMHSuI b91oxhAzeGo6588nGuHyT7PZ6Q826Ui85wQ1EEuUiezCnH7SS4seXQIyTWoZxaAE9Jdx V3iopLpBwKY69eCBBWTd8zICx+rKLfJpZtIRSkuGSx7e2cdM8KFUl2pRycW5jCV93Yhk NDCg== X-Gm-Message-State: ALoCoQnrWzDcP06s/UmMfAIs+w4L7Qpb6ozypoXgvLYyV4O2pw+vi+d7K8uO18XLkp29YlxjGDkC X-Received: by 10.224.6.7 with SMTP id 7mr570057qax.84.1375756437300; Mon, 05 Aug 2013 19:33:57 -0700 (PDT) Received: from [192.168.1.44] ([24.114.93.130]) by mx.google.com with ESMTPSA id u8sm3326203qey.5.2013.08.05.19.33.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 19:33:56 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 05 Aug 2013 22:33:48 -0400 From: Victor Kuarsingh To: Lorenzo Colitti , Brian E Carpenter Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3458586835_24053513" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:34:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3458586835_24053513 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Lorenzo, For clarity, if the text remaining mentioned ULAs, but text removed connecting it to NPT or NAT, would that meet your objections? We then point to drafts (draft-liu-v6ops-running-multiple-prefixes) and (draft-liu-v6ops-running-multiple-prefixes) for use cases and further considerations. Of course, due warning on ULAs seems to be also warranted (based on comments). Regards, Victor K From: Lorenzo Colitti Date: Tue, 6 Aug 2013 11:04:48 +0900 To: Brian E Carpenter Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC On Tue, Aug 6, 2013 at 9:20 AM, Brian E Carpenter wrote: > It seems to me that any IETF consensus document should make it clear > that ULAs are for internal use only, that GUAs should be used in parallel > for external access, and that NPTv6 is (if mentioned) only an experimental > specification. Yes, yes, and yes. > Also note that draft-liu-v6ops-ula-usage-analysis and > draft-liu-v6ops-running-multiple-prefixes are around and cover > this topic. Which is why that debate does not belong in this draft and the authors would be wise to remove this text so this draft can advance while we discuss those documents. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3458586835_24053513 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Lorenzo,

For clarity, if the text remaining mentioned ULAs, but text removed co= nnecting it to NPT or NAT, would that meet your objections?  We then po= int to drafts (draft-liu-v6ops-running-multiple-prefixes) and (draft-liu-v6o= ps-running-multiple-prefixes) for use cases and further considerations. &nbs= p;Of course, due warning on ULAs seems to be also warranted (based on commen= ts).



Regards,

Victor K

F= rom: Lorenzo Colitti <lorenzo= @google.com>
Date: Tue, 6 A= ug 2013 11:04:48 +0900
To: Brian E= Carpenter <brian.e.carpente= r@gmail.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: = Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC

On Tue, Aug 6, 2013 at 9:20 AM, Brian E Carpenter = <brian.e.carpenter@gmail.com> wrote:
It seems to me tha= t any IETF consensus document should make it clear
that ULAs are for internal use only, that GUAs should be used in parallel for external access, and that NPTv6 is (if mentioned) only an experimental<= br> specification.

Yes, yes, and yes.
=
 
Also note that draft-liu-v6ops-ul= a-usage-analysis and
draft-liu-v6ops-running-multiple-prefixes are around and cover
this topic.

Which is why that debate do= es not belong in this draft and the authors would be wise to remove this tex= t so this draft can advance while we discuss those documents.
_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3458586835_24053513-- From lorenzo@google.com Mon Aug 5 19:36: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 6AB6B21F9E26 for ; Mon, 5 Aug 2013 19:36:48 -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 Q0GkeTprXd+v for ; Mon, 5 Aug 2013 19:36:48 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DA07721F9D52 for ; Mon, 5 Aug 2013 19:36:47 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so7874644oag.4 for ; Mon, 05 Aug 2013 19:36: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=TTwj0YFfJYCz+34DcE8fPSViK1/adwAB4Tl0IskeWfM=; b=TUDN6oFHMDV1EGNhj3PjNMagbMLvyxxn3KCZjriD3svV1t7CFw0j41pr5/LWhAXTTa PVQ1qcLxwiwWdkgQuXPmfAXgpRrjKKn0Bnlxi0NW6AgIFgBlk2z4FVY66wqmZk3cOba2 CzyUZmF7EzgtJ0/Gfn7w6LZkmhScD/0QkInwaeSEmn/iKBzsrvuTNYrMDUA/HT6HFyjr NvSprhV/nwATQV46C4kKqp9OOlNhjBsd5OlTPgDDsdCvCgHnCunxByYqGsZX0BmHw9D4 VMTgg24aclh4uKVHzCO+P8fjSqMF5ZNgQ0up8n8MhBQUFoB6zdcZzIh1Q2kwR5VcXp3a /+Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TTwj0YFfJYCz+34DcE8fPSViK1/adwAB4Tl0IskeWfM=; b=bAsSlv45x6/UrESkJdZ1vlnYz4jsj13fzH/hhLueVBYxq8SpKJ/8/IoE/R4o5ipmL9 tgXk4fh8DFFdmP+GuJO0VQVycCCRAbTWMWYitNUjbymOTETY42igLF//znVHSFEuRTag gp83OCqtP+EcheG2PFIEPniyBGrIwZTmvZTrnq1EU2asn8P8CfD2MokqgC5Wo4Vi1qpR y1yyDEXa912sQg6eqnMVkqvz+VLMVht9EVTFKsoQV4Y1OAjg2U3lQgvUNgZv7ghabN34 p96Kgson6YcmG7AouAJW1YeoMUR/+30F6koopioLgGHh28U/gbDdnsu2fYswhs6Gmvqo 8kSg== X-Gm-Message-State: ALoCoQlEluJL9pPKqGCDVUWS2Yv6KCVqBXdun27Qu37IC50shUsKxQ2tQWDGZfVY0E9G1u3Cvx2NTmOpwin+E1UM4Ylpt7GuyFrSW48Jg1hHBXpDCLmwZU+20l9R414hwvmK4Mwyv9XRIY3PRRTjm1BG8KjdE+VTWCVot2Tid0EAlotBFC9sVqb68wmjdYo50tSJi4TKDSSU X-Received: by 10.50.127.145 with SMTP id ng17mr67391igb.6.1375756607191; Mon, 05 Aug 2013 19:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 5 Aug 2013 19:36:27 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B96ECA8@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96ECA8@xmb-rcd-x09.cisco.com> From: Lorenzo Colitti Date: Tue, 6 Aug 2013 11:36:27 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e013a079ee0453c04e33e4b35 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:36:48 -0000 --089e013a079ee0453c04e33e4b35 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 11:24 AM, Fred Baker (fred) wrote: > wrote: > > But if it's not indended to be globally reachable... then why is it > behind a NPTv6 box? I'd argue is that it *does* need to be globally > reachable, but "only for certain traffic". For example, "TCP/443 replies > from the Windows Update server". > > Where in *my* comment did I mention a NPTv6 box? > Er... you you said "distaste for NATs", and talked about "the stateful case". I assumed you meant stateful NAT66, which the IETF has not standardized. I then noted that stateless NAT (by which I meant NPTv6) also creates problems because the application does not know its own address. Does that clarify? Did I misunderstand you? --089e013a079ee0453c04e33e4b35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 6, 2013 at 11:24 AM, Fred Baker (fred) <fred@cis= co.com> wrote:
=A0wrote:
> But if it's not indended to be globally reachable... then why is i= t behind a NPTv6 box? I'd argue is that it *does* need to be globally r= eachable, but "only for certain traffic". For example, "TCP/= 443 replies from the Windows Update server".

Where in *my* comment did I mention a NPTv6 box?

Er... you you said "distaste for NATs", and talke= d about "the stateful case". I assumed you meant stateful NAT66, = which the IETF has not standardized. I then noted that stateless NAT (by wh= ich I meant NPTv6) also creates problems because the application does not k= now its own address. Does that clarify? Did I misunderstand you?
--089e013a079ee0453c04e33e4b35-- From lorenzo@google.com Mon Aug 5 19:44:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DE421F9377 for ; Mon, 5 Aug 2013 19:44:54 -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 wj9T1J2qp9Cc for ; Mon, 5 Aug 2013 19:44:53 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1E021F933B for ; Mon, 5 Aug 2013 19:44:52 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so7086633obc.40 for ; Mon, 05 Aug 2013 19:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LlsN9XRebAbg7qeyap9dAz+bJ5ekvyAeOuucDNyoVxM=; b=jK5157tgwGAWgQ0cPy7XVPQTyAItl6sdXWQaVwjP/QDVGAAvJc5KmR3N9swbS76rGq wg68Sp0ihEKFuHAhLq1FbpAy/WEqyWKuJcw5QkgwHpZ38ObhF/x4bhz2kDEbATWB0bjv jbadCbt8yaLBdzaY8+OBdbkLIweUjDBSYTZKWYMRDwIjDwoAdHcKCL1wBygB2u24z58u QT2cFSO6v5l7GFWtQNWnVEElwLHSwUUPcLg4mql/PJd+MG+8gKruckLa9NuwSDPqKQnK FgkSfCc9nMKHzSv5uebAg/pnWZoENbEWS3wHozYY8S8090kH42McYbTNeMjOisLsYLt9 65rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LlsN9XRebAbg7qeyap9dAz+bJ5ekvyAeOuucDNyoVxM=; b=iojUIJ9/rnrwyoIK+dEepaiYuAtCmv0tFef19OvYcL+QLg7u0xu3riLG6dnbTCaZaZ uqJsgGPAAuIM+5EpHnw/Od1gWQ1oM/auPNmmZkRxlsrBQTyfPHEdM82XW9SguWILtWI3 rFKtFMkOuUYchEKVL6dWowgqyHQqjUXQ4cl0NiaNvxNjgojI7rhbFbvjrLBd0qmoewIF pwm5aLEvtQ2KmhlQvpKW+Z2sYP3aPZ8vdlwTo2V+LVHk4vyAoxacG7AYUCby0GQwOywb 1+oU32gZcFXDiKhUu4tmfUM8xgijkeN0mTyXv69avnXgMyddfxuMkOm/3ZefHrXwCpb5 GNAA== X-Gm-Message-State: ALoCoQnUlj0463+firNvXCvli8+afhvKNm28aqVViXFHWwjJsk83SWcjaXuIagFTMLEKfNzxkuTiFXfzxKV3EZPXVUDHIw0rCLFy/ti15ysnLh3GOB0ofzVsfnBZ2maK3wF0wWDfLGgEo+xJAa4N0XbTWSGrFAAKENZz1R1wgR/J3mKZXGhNnNUsrSnoVW++W25HwIB4DVZr X-Received: by 10.50.9.102 with SMTP id y6mr65212iga.17.1375757092342; Mon, 05 Aug 2013 19:44:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 5 Aug 2013 19:44:31 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 6 Aug 2013 11:44:31 +0900 Message-ID: To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=001a11c31b66c979c204e33e6870 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:44:54 -0000 --001a11c31b66c979c204e33e6870 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 11:33 AM, Victor Kuarsingh wrote: > For clarity, if the text remaining mentioned ULAs, but text removed > connecting it to NPT or NAT, would that meet your objections? > If this draft describes the use of ULAs only in conjunction with global addresses, and states that they cannot be used by themselves, noting that this is different from IPv4, where a host can have only private addresses and function properly, then that's likely to be non-controversial, because it just repeating what's written in RFC 4193. Mentioning a use case where a host only has ULAs, or suggesting the use of ULA+NPTv6, is likely going to be controversial. We then point to drafts (draft-liu-v6ops-running-multiple-prefixes) > and (draft-liu-v6ops-running-multiple-prefixes) > I take it you mean "draft-liu-v6ops-running-multiple-prefixes" and "draft-ietf-v6ops-ula-usage-recommendations"? --001a11c31b66c979c204e33e6870 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 6, 2013 at 11:33 AM, Victor Kuarsingh <victor= @jvknet.com> wrote:
For clarity, if the text remaining mentioned ULAs, but text removed co= nnecting it to NPT or NAT, would that meet your objections?

If this draft describes the use of ULAs only i= n conjunction with global addresses, and states that they cannot be used by= themselves, noting that this is different from IPv4, where a host can have= only private addresses and function properly, then that's likely to be= non-controversial, because it just repeating what's written in RFC 419= 3. Mentioning a use case where a host only has ULAs, or suggesting the use = of ULA+NPTv6, is likely going to be controversial.

=A0We then point to drafts (draft-liu-v6ops-running-multiple-prefixes)= =A0
and (draft-liu-v6ops-running-multiple-prefixes)

I take it you mean "draft-liu-v6ops-runni= ng-multiple-prefixes" and "draft-ietf-v6ops-ula-usage-recommendat= ions"?
--001a11c31b66c979c204e33e6870-- From victor@jvknet.com Mon Aug 5 19:53: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 D2BFD21F9D52 for ; Mon, 5 Aug 2013 19:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwZy9Md5hkrW for ; Mon, 5 Aug 2013 19:53:36 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id DF54521F9CBD for ; Mon, 5 Aug 2013 19:53:35 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so1379693qab.2 for ; Mon, 05 Aug 2013 19:53:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=JYfyj9nH1OxqIJw/dSkk8zcU9sjGTjRa5tXFx383b4I=; b=UHRV4ZwG8HMc3ySM5qIMxSwWcbltdsAGZ/PIUx2/1pLo9P+Uz0lLI+ZB9Npycyoigp t/vj57Y4uY9a7Rt3AlkGS8WJSLBp+U6dgfeCJ2gzKvP/nKHA61vyDnpnlr/GUrODOgzi whRFR0XXy4jOjGsRUvmI4qb+H2wdBunJ3rQ3MoRzDEG7oR9Ize3aTohXmJZZngOSSBnT obi1+P5IoX9/SEWnzCPWJ1a9q7AoTrdZRuz4K40oBy9lG2fHsPViXeG+RSjHmE9iGSky XaYxG38koVbfWPqplNKwAVRJczi5K6OgkZv9Bym+7Qp6Ls/OAY9GIs5BgZ1mhxRRMuVj Xuzw== X-Gm-Message-State: ALoCoQmzg+0hesyr7k9pXLAF7ar83v7V9UjPS8M+eCbl3FsVn/AZblwhEyC36uKbYR/KTwfVp+qi X-Received: by 10.224.6.7 with SMTP id 7mr637042qax.84.1375757615357; Mon, 05 Aug 2013 19:53:35 -0700 (PDT) Received: from [192.168.1.44] ([24.114.93.130]) by mx.google.com with ESMTPSA id q15sm1462277qak.5.2013.08.05.19.53.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 19:53:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 05 Aug 2013 22:53:27 -0400 From: Victor Kuarsingh To: Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3458588013_24153524" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 02:53:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3458588013_24153524 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Lorenzo (in-line) From: Lorenzo Colitti On Tue, Aug 6, 2013 at 11:33 AM, Victor Kuarsingh wrote: >>> >>For clarity, if the text remaining mentioned ULAs, but text removed >>> connecting it to NPT or NAT, would that meet your objections? >If this draft describes the use of ULAs only in conjunction with global addresses, and states that they cannot be used by themselves, noting >that this is different from IPv4, where a host can have only private addresses and function properly, then that's likely to be non->controversial, because it just repeating what's written in RFC 4193. Mentioning a use case where a host only has ULAs, or suggesting the >use of ULA+NPTv6, is likely going to be controversial. What about the use case of a host that has no global connectivity requirements? I know of cases in the SP world where this is true, although this draft is for Enterprise, but they may have similar cases (I.e. Closed network environments, testing beds, etc). >>> >>We then point to drafts (draft-liu-v6ops-running-multiple-prefixes) >>> >>and (draft-liu-v6ops-running-multiple-prefixes) >I take it you mean "draft-liu-v6ops-running-multiple-prefixes" and "draft-ietf-v6ops-ula-usage-recommendations"? Yes, my bad. My cut/paste skills are poor this evening. Regards, Victor K --B_3458588013_24153524 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Lorenzo

=
(in-line)

From: = Lorenzo Colitti <lorenzo@google.com<= /a>>


On Tue, Aug 6, 2013 at 11= :33 AM, Victor Kuarsingh <victor@jvknet.com> wrote:
>>For clarity= , if the text remaining mentioned ULAs, but text removed connecting it to NP= T or NAT, would that meet your objections?

=
>If this draft describes the use of ULAs only in conjunction w= ith global addresses, and states that they cannot be used by themselves, not= ing >that this is different from IPv4, where a host can have only private= addresses and function properly, then that's likely to be non->controver= sial, because it just repeating what's written in RFC 4193. Mentioning a use= case where a host only has ULAs, or suggesting the >use of ULA+NPTv6, is= likely going to be controversial.

What about the use case of a host that has no global connectivity r= equirements? I know of cases in the SP world where this is true, although th= is draft is for Enterprise, but they may have similar cases (I.e. Closed net= work environments, testing beds, etc).
=

 >>We then point to drafts (draft-liu-v6o= ps-running-multiple-prefixes) 
>>and (draf= t-liu-v6ops-running-multiple-prefixes)

>I take it you mean "draft-liu-v6ops-running-multiple-prefixes" an= d "draft-ietf-v6ops-ula-usage-recommendations"?

Yes, my bad.  My cut/paste skills are poor this e= vening.

Regards,

Victor K<= /div> --B_3458588013_24153524-- From lorenzo@google.com Mon Aug 5 20:41:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D621F9BBF for ; Mon, 5 Aug 2013 20:41:22 -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 KYWpOeEL8jRb for ; Mon, 5 Aug 2013 20:41:21 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1B921F9C16 for ; Mon, 5 Aug 2013 20:41:21 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so8180250oag.15 for ; Mon, 05 Aug 2013 20:41:20 -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=Sbe3TTJDV27i8skYwjvnWZQt3VYe/q5MeqbCxhBa4XA=; b=kQoBbtOPa+LjZlYfQlsQKDVbGhYliAap30lj+r5ma0qbaHjRDolk8NeQpiZylUQAkr IhKUYMRudjAj72atxqRfKblL3VUTPEZIRUGWfnAE6ALWtchjQ4VGU+CcC7+EJ/zoB00l TaRmuN67liy4S8S102D5zCGjJxV5tYG6u9r0vvMeASV9PnFbpwsEuTecK9hAOO0582ai LOwTMu2liYCarEYzwYln6+uxE7dRAt6a45pNYHiyCrW5/GjoKDENWP4wiakjvV1hgLFf XnRB7YWGMXr7MvGuojF5pszmvCo6LtJewficQrvRW3qpdqXo5ApSQo4LFepi2BW8/zt0 5sSg== 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=Sbe3TTJDV27i8skYwjvnWZQt3VYe/q5MeqbCxhBa4XA=; b=X05kI8Kc0nL5OZh7mEe2wvWIYgv32n+A3S56Iuypws7y+eRysdZGQS5UuPDlAKrTg8 z9FK1CgbXi5eJGu2NMhdxMRh84A66Z0uGvCW0Z/a6M9ypJNoGsz0GiBd9YlTTZRz7CRG 54CzPCx+lnfiS8qN+FbQtwzWR1tsZwzJhBpcJKQobM6bUt0bFVwyLWEnOfM7Z4nnZAuF rvVQjoyKLmgNCeRMj2R2gZCqkJv/v1YS/qvhSgUNKRYSV06Iw5/1GVMMFZEklVZgVoWq Xyb4KmeK1g77uJQlR3pWSFgnO3WUW9P/cW4Tfv9+Y/ImmBuh0rAxNzbFgTJzWzZAi8CN BUBA== X-Received: by 10.43.137.131 with SMTP id io3mr1905712icc.79.1375760480765; Mon, 05 Aug 2013 20:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Mon, 5 Aug 2013 20:41:00 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 6 Aug 2013 12:41:00 +0900 Message-ID: To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=001a11c2c322c0ccf504e33f32ad X-Gm-Message-State: ALoCoQkOpUja7SptSInWFdzZrG0yw7zlL28gBHiZ12YAS9pnPZ8t0jlv0zA8Ciq8R7P50OMb6ejK91GCyiRNPh+5scAb76/yLyn4hT34500P+M41ruei/jaXq6KaVEuR4raRH2GxmhvkgM3di6urJHeLv/bU0m1GcZBF8WqxXkxNFJBG5faQAqLWwX3YpwqrZMr2dzY6gIZu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 03:41:22 -0000 --001a11c2c322c0ccf504e33f32ad Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 11:53 AM, Victor Kuarsingh wrote: > What about the use case of a host that has no global connectivity > requirements? I know of cases in the SP world where this is true, although > this draft is for Enterprise, but they may have similar cases (I.e. Closed > network environments, testing beds, etc). > This case is neither as simple nor as clear-cut as it sounds. If a host truly has no global connectivity requirements then it doesn't matter what IP addresses it uses as long as they are globally unique. (They still need to be globally unique because even though the host doesn't talk to the outside world, it will talk to something that [talks to something that...] talks to the outside world). In that case, then that host can use any address that's globally unique, including global unicast or ULA. Global addresses have the advantage that they are unambiguously globally unique, whereas ULA addresses are only probabilistically unique. This means that if you have enough ULA to cause a collision then you will have problems, and if someone misconfigures their machines with the ULA prefix that you picked, then you're sort of SOL. On the other hand, ULA has an advantage over PI addresses because the latter may need to be renumbered if you change ISPs. There's also the point that when people say "will never talk to the outside world", that's more often than not an oversimplification. :-) Since these points are pretty subtle, they should be carefully worded. I think the right place for that is in the ULA usage document. Why not simply punt to that document? --001a11c2c322c0ccf504e33f32ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 6, 2013 at 11:53 AM, Victor Kuarsingh <victor= @jvknet.com> wrote:
What about the use case of a host that has no global connectivity requ= irements? I know of cases in the SP world where this is true, although this= draft is for Enterprise, but they may have similar cases (I.e. Closed netw= ork environments, testing beds, etc).

This case is neither as simple= nor as clear-cut as it sounds.

If a host truly ha= s no global connectivity requirements then it doesn't matter what IP ad= dresses it uses as long as they are globally unique. (They still need to be= globally unique because even though the host doesn't talk to the outsi= de world, it will talk to something that [talks to something that...] talks= to the outside world).

In that case, then that host can use any address that&#= 39;s globally unique, including global unicast or ULA. Global addresses hav= e the advantage that they are unambiguously globally unique, whereas ULA ad= dresses are only probabilistically unique. This means that if you have enou= gh ULA to cause a collision then you will have problems, and if someone mis= configures their machines with the ULA prefix that you picked, then you'= ;re sort of SOL. On the other hand, ULA has an advantage over PI addresses = because the latter may need to be renumbered if you change ISPs.

There's also the point that when people say "w= ill never talk to the outside world", that's more often than not a= n oversimplification. :-)

Since these points are p= retty subtle, they should be carefully worded. I think the right place for = that is in the ULA usage document. Why not simply punt to that document?
--001a11c2c322c0ccf504e33f32ad-- From brian.e.carpenter@gmail.com Mon Aug 5 21:49: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 3306521F9C83 for ; Mon, 5 Aug 2013 21:49:19 -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 1aA9IJ9tIE44 for ; Mon, 5 Aug 2013 21:49:18 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id BE63921F9C66 for ; Mon, 5 Aug 2013 21:49:18 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so4116785pde.9 for ; Mon, 05 Aug 2013 21:49: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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=id6iwwOghY+Hin/O0NzHdO9LJ62536NfPVS3QX68ZjM=; b=jWE5RmUMVbD1mjw9ngsuPKS4U9gYjkyon8UvddplG+IOmsDPMK5edyPitjCXb5+HZZ 3ODCICIZkSUAKNKyTMX4kReKL5dxcYmNzU4x+zZFwqijE2qCU3lbU+bHf4UkTzd5lmMp RiYvVLiVsM03Re+XsCE3X/GDNB5dmFKfgF2VS1WmOtOPgJc7lyudea6di0PSl3i97i03 CTPxjnBFLo73AA1PunGlEHjr68yGIwgp/GvPw+swMqgMzdjQ5kxdGsjKJ0HfjgNVE9uJ eKAx1BPIcOqHU5xB7VCfz6coMk3hSqbExjH9sUlv+T943ErRqQRNRW5TnBVF9gjNvLZe B02Q== X-Received: by 10.68.43.71 with SMTP id u7mr25591284pbl.187.1375764558511; Mon, 05 Aug 2013 21:49:18 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id py4sm2697435pbc.14.2013.08.05.21.49.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 21:49:17 -0700 (PDT) Message-ID: <5200804D.2050006@gmail.com> Date: Tue, 06 Aug 2013 16:49:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <201308041800.r74I03pC023049@irp-view13.cisco.com> In-Reply-To: <201308041800.r74I03pC023049@irp-view13.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 04:49:19 -0000 On a different topic, section 5 covers IPv6-only issues. I'm a bit concerned that this might need a health warning: deploying NAT64/DNS64 might cause pain and suffering. Perhaps after this text: > Together, RFCs > 6146 and RFC 6147 provide a viable method for an IPv6-only client to > initiate communications to an IPv4-only server. we should add something like: At enterprise level, operating NAT64 and DNS64 services for heavy usage may have significant practical implications. Also, the last paragraph of section 5: > It is worth noting that for IPv6-only access networks that use > technologies such as NAT64, the more content providers (and > enterprises) that make their content available over IPv6, the less > the requirement to apply NAT64 to traffic leaving the access network. A reference to RFC 6883 would fit nicely there. Regards Brian From john_brzozowski@cable.comcast.com Mon Aug 5 22: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 B7B9221E804D for ; Mon, 5 Aug 2013 22:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.667 X-Spam-Level: X-Spam-Status: No, score=-100.667 tagged_above=-999 required=5 tests=[AWL=-2.229, BAYES_20=-0.74, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, 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 Bs1H0JHVshTU for ; Mon, 5 Aug 2013 22:23:27 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2B28D11E80D5 for ; Mon, 5 Aug 2013 22:23:26 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.60826516; Tue, 06 Aug 2013 01:23:11 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.157]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Tue, 6 Aug 2013 01:23:20 -0400 From: "Brzozowski, John" To: v6ops Thread-Topic: IETF 87 v6ops meeting minutes Thread-Index: AQHOkmUPGP7P6Q0Tl0uNBfaim2qvIw== Date: Tue, 6 Aug 2013 05:23:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <19D2D8D58A46484D943931402FAAF31E@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] IETF 87 v6ops meeting minutes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Aug 2013 05:23:32 -0000 Apologies for sending this to the entire WG, can the person who took minutes in Berlin for both v6ops sessions please send them to Fred and myself? Thank you, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 609-377-6594 o) 484-962-0060 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From martin@millnert.se Mon Aug 5 23:05: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 CAD1611E80E0 for ; Mon, 5 Aug 2013 23:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, 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 iS18iCLN3zNH for ; Mon, 5 Aug 2013 23:05:17 -0700 (PDT) Received: from ncis.csbnet.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id D654311E80D5 for ; Mon, 5 Aug 2013 23:05:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 3E4C54D6; Tue, 6 Aug 2013 08:05:54 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF5cpvB7hPI4; Tue, 6 Aug 2013 08:05:53 +0200 (CEST) Received: from [192.168.120.225] (h-186-193.a189.priv.bahnhof.se [85.24.186.193]) by ncis.csbnet.se (Postfix) with ESMTPSA id 1BF0EB9; Tue, 6 Aug 2013 08:05:52 +0200 (CEST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1BA82DF6-277E-4FA0-99CE-8F848E25FF75@millnert.se> X-Mailer: iPad Mail (10B329) From: Martin Millnert Date: Tue, 6 Aug 2013 08:05:03 +0200 To: Lorenzo Colitti Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 06:05:22 -0000 On 6 aug 2013, at 05:41, Lorenzo Colitti wrote: > In that case, then that host can use any address that's globally unique, i= ncluding global unicast or ULA. Global addresses have the advantage that the= y are unambiguously globally unique, whereas ULA addresses are only probabil= istically unique. This means that if you have enough ULA to cause a collisio= n then you will have problems, and if someone misconfigures their machines w= ith the ULA prefix that you picked, then you're sort of SOL. On the other ha= nd, ULA has an advantage over PI addresses because the latter may need to be= renumbered if you change ISPs. >=20 > There's also the point that when people say "will never talk to the outsid= e world", that's more often than not an oversimplification. :-) >=20 > Since these points are pretty subtle, they should be carefully worded. I t= hink the right place for that is in the ULA usage document. Why not simply p= unt to that document? Enterprises WILL configure addresses without using RIR-coordinated GUA, so j= ust a summary of ULA and instead references to other RFCs, such as 4193 and m= entioned drafts, is in order in this document IMO.=20 /M= From evyncke@cisco.com Wed Aug 7 06:07: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 60A3121E811A for ; Wed, 7 Aug 2013 06:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 N-cXzoEwhuOo for ; Wed, 7 Aug 2013 06:07:48 -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 133E221E80FE for ; Wed, 7 Aug 2013 06:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12139; q=dns/txt; s=iport; t=1375880868; x=1377090468; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=95FC5rU8R4X7q57e0M3LqPL3GaukSS+05LVF7FiJVtU=; b=Ty4niXdSjimuQ7BjgIeHwBsAjvDqTb0tQhpSbdFfDMee7sR3+Lb3PEIc Yj4Z4LdPEExaM6Agp++qOZR3BJgmP0evt1TqMB8IFS5x5lyuZSbvdF3A+ ChjHPnX50vsyQ880viEwUlnym7smc0jVBnJ0eEd6K1I1pXVvF44+VxOtM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFANFFAlKtJV2b/2dsb2JhbABbgkJEgQW+R4EcFnSCJAEBAQMBLUwFCwIBCBEEAQEBCh0HMhQDAQUIAgQBDQUIiAIGuGKPaTEGAYMadAOIc6A9gxeCKg X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208,217";a="244343514" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 07 Aug 2013 13:07:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r77D7luw023723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 13:07:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 08:07:46 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkTyDevJwNWLtzkuaof7OxddtY5mGm1kAgACKQoCAAF43gIAAFCCAgAArgQCAAfZ/gA== Date: Wed, 7 Aug 2013 13:07:46 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E113128FA2xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:07:57 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E113128FA2xmbalnx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In short, the debate is not so much about ULA per se (we all know that ther= e are obvious cases - even if rare - where ULA is the obvious choice) but a= bout NPTv6 ;-O What a surprise... I dislike NAT (especially the n:1 stateful one) even more when it is assume= d to add security (cough cough). But, during my day job I talk to enterprise customers (from small SMB with = 3 people - friends and acquaintance - to 1000 people) and to be honest ULA = (and I am ashamed to add NPT6 to the mix) is really what they want and I ca= n understand why: - Having the internal network up when DHCP-PD is failing because WAN = link is down (at least they keep ULA and loose only their GUA), this should= be mentioned in our I-D - Having a simple and cheap way to do multi-homing, search about mult= i-homing, load-balancing, ... for SMB and those boxes uses RFC 1918 inside = + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will get a PI= space and will run BGP. In short, I am probably the only co-author, that do not want to hide the to= pic under the carpet of another I-D. We could mention the above points (and= others) without taking decisions but referring to the ULA use case I-D. Bu= t, we should mention that there are use case where ULA _APPEARS_ as appeali= ng. -=E9ric (and YES I dislike NAPT for breaking apps, and making security wors= e) From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= orenzo Colitti Sent: mardi 6 ao=FBt 2013 04:03 To: Fred Baker (fred) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) > wrote: > NAT creates problems for applications not only in the stateful case, but = in the stateless case as well, because with NAT the client must be prepared= for a situation where it does not know its own address. This complicates p= eer-to-peer networking applications such as video chat. I'm not going to argue one way or the other. The substance of my comment re= lated to an address that was not intended to be globally reachable. our tho= ught there? But if it's not indended to be globally reachable... then why is it behind = a NPTv6 box? I'd argue is that it *does* need to be globally reachable, but= "only for certain traffic". For example, "TCP/443 replies from the Windows= Update server". The point is that when people say, "X will never do Y" sometimes it turns o= ut that "never" just means "in the next six months", and what ends up happe= ning is that they need to deal with additional complexity once Y becomes a = requirement. --_000_97EB7536A2B2C549846804BBF3FD47E113128FA2xmbalnx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In short, th= e debate is not so much about ULA per se (we all know that there are obviou= s cases – even if rare – where ULA is the obvious choice) but about NPTv6 ;-O What a surprise...

 <= /o:p>

I dislike NA= T (especially the n:1 stateful one) even more when it is assumed to add sec= urity (cough cough).

 <= /o:p>

But, during = my day job I talk to enterprise customers (from small SMB with 3 people = 211; friends and acquaintance – to 1000 people) and to be honest ULA (and I am ashamed to add NPT6 to the mix) is really what they want and= I can understand why:

-       Havi= ng the internal network up when DHCP-PD is failing because WAN link is down= (at least they keep ULA and loose only their GUA), this should be mentioned in our I-D

-       Havi= ng a simple and cheap way to do multi-homing, search about multi-homing, lo= ad-balancing, ... for SMB and those boxes uses RFC 1918 inside + NAT towards two ISP or two links (xDSL & 4G)... Not all S= MB will get a PI space and will run BGP.

 <= /o:p>

In short, I = am probably the only co-author, that do not want to hide the topic under th= e carpet of another I-D. We could mention the above points (and others) without taking decisions but referring to the ULA use case I-= D. But, we should mention that there are use case where ULA _APPEARS= _ as appealing.

 <= /o:p>

-=E9ric (and= YES I dislike NAPT for breaking apps, and making security worse)

 <= /o:p>

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org= ] On Behalf Of Lorenzo Colitti
Sent: mardi 6 ao=FBt 2013 04:03
To: Fred Baker (fred)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WG= LC

 

On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) &l= t;fred@cisco.com>= ; wrote:

> NAT creates prob= lems for applications not only in the stateful case, but in the stateless c= ase as well, because with NAT the client must be prepared for a situation w= here it does not know its own address. This complicates peer-to-peer networking applications such as video chat.<= o:p>

I'm not going to argue one way or the other. The sub= stance of my comment related to an address that was not intended to be glob= ally reachable. our thought there?

 

But if it's not indended to be globally reachable...= then why is it behind a NPTv6 box? I'd argue is that it *does* need to be = globally reachable, but "only for certain traffic". For example, = "TCP/443 replies from the Windows Update server".

 

The point is that when people say, "X will neve= r do Y" sometimes it turns out that "never" just means "= ;in the next six months", and what ends up happening is that they need= to deal with additional complexity once Y becomes a requirement.

--_000_97EB7536A2B2C549846804BBF3FD47E113128FA2xmbalnx02ciscoc_-- From lorenzo@google.com Wed Aug 7 07:19: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 F33A521F9223 for ; Wed, 7 Aug 2013 07:19:52 -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_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1kYXsUEdctT for ; Wed, 7 Aug 2013 07:19:52 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 623C921F91CA for ; Wed, 7 Aug 2013 07:19:52 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so3537946oag.12 for ; Wed, 07 Aug 2013 07:19: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=zdLmv0J7N0tBvPqwM5aBHkMez51XkTdO/yUH6x3DH6c=; b=W1PyGNpRcL9kOdajDBxQWlgx3HPVV6r/ac1BXwrRuxn9Ym/5TmCMXi4aTShYP2y9ss zls7JCMuuvE6qpyt1qrebuTNltJncTLTDHPqDsfy9iOixMTHYpyKadbKbITYS26oIgFw zgJfWmchrA85fVJVIfSIEktKlV1AC+bVwh2IJjhDGbbbc1VO9p86rbNXpvgxPVEYSUSe eYH4l8KEBd5Krpjp+EIzQ6GgWt0WciA/ExwVwPvA0M3vvk8ZX2lx+eFKWIKC/2oRtaHd 2HM/arSnSeQGb2bXhzGC5bZvOLtZ2WUuCW5qUNVx5W+ZTRkG1fcMU+Ass+/eTRY6ATWY 0zAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zdLmv0J7N0tBvPqwM5aBHkMez51XkTdO/yUH6x3DH6c=; b=OfcWSynQEjTFH7Q50kAh3UAhEksUa3NstrETlnFQOS9QZFUIMXHZFfm/XevyMPMPov v35p11UF/XHos0Yae9GlvKaaSlX8AhxUusNS2zrRQjJ7+C0CxxEGj5GviBIerzKmZfdh h/ctY9tY5B5P/YP6Lxsi73iO4GMD+jEjWUjAX9M3quMJ1HRmxYw9UbsGbE0Nrac01CI7 hAYp/x3dbVpZRs88lCm3mK1gi3BUbi5TvqMTvegMtgF1DbWhDYQgPgnYXdiYOuzHFG1p rCecTclRaxZoXXWOSWlQ7Zh7LC/Cf3ZaZjsHPM+sQtzHSg+Wqgb9eOb7ujDAO7ACRoNr SUCw== X-Gm-Message-State: ALoCoQm1s13MAnZyJqfJbu0j099vY5D/oyt6s2z5AOl+9P+7sqJg4wAH3z0ERF5pHdXVI4FM/M7lalOmi18led58/+7yFIa3T2OvmziBXh6WjG+oIA0R5wcJBkvUcyeWN/gMrl0kW8is/mh3Zc6/97NMpkSh3Z/wZUwhRIG3yjpMVSH4uV0hu8ApqJ7NnwaFUZEbCpUF5Qy1 X-Received: by 10.50.9.102 with SMTP id y6mr82553iga.17.1375885190793; Wed, 07 Aug 2013 07:19:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.144 with HTTP; Wed, 7 Aug 2013 07:19:30 -0700 (PDT) In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> From: Lorenzo Colitti Date: Wed, 7 Aug 2013 23:19:30 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=001a11c31b660cb1c004e35c3cc4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:19:53 -0000 --001a11c31b660cb1c004e35c3cc4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 7, 2013 at 10:07 PM, Eric Vyncke (evyncke) w= rote: > - **Having the internal network up when DHCP-PD is failing because > WAN link is down (at least they keep ULA and loose only their GUA), this > should be mentioned in our I-D > I think we all agree that ULA + GUA is an accepted use case that should go into this document as well. Are you saying that ULA-only should to into this document as well? I don't think there is consensus on that. - **Having a simple and cheap way to do multi-homing, search about > multi-homing, load-balancing, ... for SMB and those boxes uses RFC 1918 > inside + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will > get a PI space and will run BGP. > That's why we're working on source+destination based routing, which is a much better solution than anything involving translation. and since this is an IETF document, I think it should document src+dst routing (which is gaining consensus and has a lot of work going on around it in various working groups) over ULA-only, whose only reason for existence is "it's similar to what we do in IPv4, which we all hate". > -=E9ric (and YES I dislike NAPT for breaking apps, and making security wo= rse) > NPTv6 breaks apps too. For example, it will break anything using libjingle (e.g., Google video chat). --001a11c31b660cb1c004e35c3cc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 7, 2013 at 10:07 PM, Eric Vyncke (evyncke) <e= vyncke@cisco.com> wrote:

-=A0=A0=A0=A0=A0=A0 Having the internal network up wh= en DHCP-PD is failing because WAN link is down (at least they keep ULA and = loose only their GUA), this should be mentioned in our I-D

I think we all agree that ULA + GUA is an accepted use case tha= t should go into this document as well. Are you saying that ULA-only should= to into this document as well? I don't think there is consensus on tha= t.

-=A0=A0=A0= =A0=A0=A0 Having a simple and cheap way to = do multi-homing, search about multi-homing, load-balancing, ... for SMB and= those boxes uses RFC 1918 inside + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB w= ill get a PI space and will run BGP.


That's why we're working on source+destination bas= ed routing, which is a much better solution than anything involving transla= tion. and since this is an IETF document, I think it should document src+ds= t routing (which is gaining consensus and has a lot of work going on around= it in various working groups) over ULA-only, whose only reason for existen= ce is "it's similar to what we do in IPv4, which we all hate"= .
=A0

-=E9ric (and= YES I dislike NAPT for breaking apps, and making security worse)


NPTv6 breaks apps too. For example, it wil= l break anything using libjingle (e.g., Google video chat).
--001a11c31b660cb1c004e35c3cc4-- From evyncke@cisco.com Wed Aug 7 07:24: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 E297D21F91CA for ; Wed, 7 Aug 2013 07:24:34 -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.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVEFEFwsL24g for ; Wed, 7 Aug 2013 07:24:29 -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 0EDA521F9302 for ; Wed, 7 Aug 2013 07:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9855; q=dns/txt; s=iport; t=1375885469; x=1377095069; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oGlIdbWxAeL4kCTzIlnChAcf1N+RycdLi1TD8cMkirE=; b=jr+t39mhEU6BMifhhPro5+cm6Riya3bNWOKmx0Zpq+/acagKBNtZ5vpX gK7yn0kMkkENIx33edCBvJrbTvgQDzzrdaM+vX2dzFNp7PlZOhauNjqau +h7Wo5i0S+5bfKxd1vovEMtGNGFYW0w+BsnQXsbACQBJ4ToAFUmioreJ2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAGFXAlKtJXG9/2dsb2JhbABbgkJEgQW+R4EcFnSCJAEBAQQtPw0QAgEIEQQBAQsdBzIUCQgCBA4FCBOHdbhPj2kxBgGDGnQDiHOgPYMXgio X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208,217";a="244653918" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 07 Aug 2013 14:24:28 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r77EOSLG005127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 14:24:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 09:24:27 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOk3k0iEs+n1KrYk++vIe4m7g1OpmJzGHw Date: Wed, 7 Aug 2013 14:24:27 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1131292C8@xmb-aln-x02.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E1131292C8xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:24:35 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E1131292C8xmbalnx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lorenzo You have a very valid point about documenting the source-destination routin= g on the same 'foot' as NPT6. And of course, we are in agreement on NPT6 breaking applications (probably = less though than NAPT) -=E9ric From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: mercredi 7 ao=FBt 2013 16:20 To: Eric Vyncke (evyncke) Cc: Fred Baker (fred); v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC On Wed, Aug 7, 2013 at 10:07 PM, Eric Vyncke (evyncke) > wrote: - Having the internal network up when DHCP-PD is failing because WAN = link is down (at least they keep ULA and loose only their GUA), this should= be mentioned in our I-D I think we all agree that ULA + GUA is an accepted use case that should go = into this document as well. Are you saying that ULA-only should to into thi= s document as well? I don't think there is consensus on that. - Having a simple and cheap way to do multi-homing, search about mult= i-homing, load-balancing, ... for SMB and those boxes uses RFC 1918 inside = + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will get a PI= space and will run BGP. That's why we're working on source+destination based routing, which is a mu= ch better solution than anything involving translation. and since this is a= n IETF document, I think it should document src+dst routing (which is gaini= ng consensus and has a lot of work going on around it in various working gr= oups) over ULA-only, whose only reason for existence is "it's similar to wh= at we do in IPv4, which we all hate". -=E9ric (and YES I dislike NAPT for breaking apps, and making security wors= e) NPTv6 breaks apps too. For example, it will break anything using libjingle = (e.g., Google video chat). --_000_97EB7536A2B2C549846804BBF3FD47E1131292C8xmbalnx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lorenzo

 

You have a v= ery valid point about documenting the source-destination routing on the sam= e ‘foot’ as NPT6.

 <= /o:p>

And of cours= e, we are in agreement on NPT6 breaking applications (probably less though = than NAPT)

 <= /o:p>

-=E9ric=

 <= /o:p>

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: mercredi 7 ao=FBt 2013 16:20
To: Eric Vyncke (evyncke)
Cc: Fred Baker (fred); v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WG= LC

 

On Wed, Aug 7, 2013 at 10:07 PM, Eric Vyncke (evynck= e) <evyncke@cisco= .com> wrote:

-     &n= bsp; Having the internal network = up when DHCP-PD is failing because WAN link is down (at least they keep ULA= and loose only their GUA), this should be mentioned in our I-D

 

I think we all agree that ULA + GUA is an accept= ed use case that should go into this document as well. Are you saying that = ULA-only should to into this document as well? I don't think there is conse= nsus on that.

 

-     &n= bsp; Having a simple and cheap wa= y to do multi-homing, search about multi-homing, load-balancing, ... for SM= B and those boxes uses RFC 1918 inside + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will get a PI space and wi= ll run BGP.

 

That's why we're working on source+destination b= ased routing, which is a much better solution than anything involving trans= lation. and since this is an IETF document, I think it should document src&= #43;dst routing (which is gaining consensus and has a lot of work going on around it in various working groups) over U= LA-only, whose only reason for existence is "it's similar to what we d= o in IPv4, which we all hate".

 

-=E9ric (and YES I dislike= NAPT for breaking apps, and making security worse)

 

NPTv6 breaks apps too. For example, it will break an= ything using libjingle (e.g., Google video chat).

--_000_97EB7536A2B2C549846804BBF3FD47E1131292C8xmbalnx02ciscoc_-- From mackermann@bcbsm.com Wed Aug 7 10:30: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 B9C3E21F9D1B for ; Wed, 7 Aug 2013 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.702 X-Spam-Level: X-Spam-Status: No, score=-5.702 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J3i8HE95P+e for ; Wed, 7 Aug 2013 10:30:29 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id C4FA921F9F00 for ; Wed, 7 Aug 2013 10:30:24 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 8DCAA9ADA11 for ; Wed, 7 Aug 2013 12:30:18 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 742D39AD9FC; Wed, 7 Aug 2013 12:30:17 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 19D982F0045; Wed, 7 Aug 2013 13:23:03 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id 0D3012F0043; Wed, 7 Aug 2013 13:23:03 -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%13]) with mapi id 14.01.0438.000; Wed, 7 Aug 2013 13:30:16 -0400 From: "Ackermann, Michael" To: "v6ops@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-elkins-6man-ipv6-pdm-dest-option-00 Thread-Index: Ac6Tduii6HBaDHrPTdid+mpYk64vCA== Date: Wed, 7 Aug 2013 17:30:16 +0000 Deferred-Delivery: Wed, 7 Aug 2013 17:30:00 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A7E2A84@PWN401EA160.ent.corp.bcbsm.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_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_" MIME-Version: 1.0 Subject: [v6ops] draft-elkins-6man-ipv6-pdm-dest-option-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:30:38 -0000 --_000_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At IETF 87 in Berlin, our team presented the Performance and Diagnostic = Metrics (PDM) Option for the DOH Extension Header. This presentation, and = the associated Draft, addressed the need for enhanced diagnostics and = performance information in IPv6, as well as a recommended solution that = would accomplish this. Similar information on this topic was presented to both v6ops and 6man. There were several follow up issues and questions that we will now address = on the Email list. We will be discussing our proposal with a number of other IETF groups = (NTP, IPPM, LMAP) as well as RIPE NCC TTM. We will cross-post the results = of our discussions on the appropriate lists. To summarize our proposal and the outstanding issues/questions:: 1. This Destination Option type is Optional and can be turned on/off = independently at either end. 2. The field called Packet Sequence Number is similar to IPID in = IPv4 and is primarily intended to ease and expedite diagnostics, = particularly at end points. 3. The two Timestamp fields are primarily for network performance = triage and metrics. These fields can also be utilized for: performance = reporting; by security devices; and for any other functions requiring a = highly granular time reference. 4. The 3 new fields can also be utilized together to further enhance = network diagnostics and support, at any point or device in the network path. 5. The 4th field is open to be used by applications and platforms = having =22Special=22 performance or diagnostic needs (e.g. Gaming, = commerce, etc.). 6. As pointed out by Joel after the presentation, having = synchronized time sources in the devices being analyzed is critical for = effective results when using the network performance (timestamps) features = and functions. ANY performance monitoring/measurement solution will = require this -- see, for example, RFC 2679 and RFC2681. We will discuss = this issue with other groups to see how they have dealt with this problem. 7. Both the Packet Sequence number and the Timestamp fields are per = =22FLOW=22. After the presentation it was pointed out that this term was = evidently not meaningful or specific enough. Some would use the words per = =22Session=22, per =22Connection=22 or per =22Socket=22. Regardless of = the term applied, the 5 unique identifiers are IP address and port at each = end point, plus the protocol (e.g. UDP, TCP, etc.). Hopefully that = delineates what was referred to in the presentation as =22Flow=22. 8. In the question and answer period of the presentation, it was = suggested that this solution should work fine in private networks, but = perhaps not on the Internet. It is our assertion that this solution = should work on all networks, as long as the DOH Extension Header is = passed end to end. Since Extension Headers are an intrinsic component of = the IPv6 Architecture, we should be able to assume this to be true. If = Extension Headers are not being passed along any given path (Internet or = otherwise), then that is an issue/problem that is much bigger than this = proposal and needs to be adequately addressed if IPv6 is to be successful. This is the area that we are exploring with other IETF groups. We hope to = collaborate with them and incorporate their expertise and experience to = build a solution which will be useful for the Internet as well as private = networks. We feel that a simple and scalable way to provide accurate and timely = diagnostics and performance measurement is what is needed to further the = usability and promote the growth of the Internet as well as implementation = of IPv6. If other issues or questions exist, relative to this proposal, we look = forward to addressing them. 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_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_ 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-->

At IETF 87 in Berlin, our team presented the Performance and = Diagnostic Metrics (PDM) Option for the DOH Extension = Header.  This presentation, and the associated = Draft, addressed the need for enhanced diagnostics and performance information in IPv6, as well as a recommended solution that would = accomplish this.      

 

Similar information on this topic was presented to both v6ops and = 6man.

 

There were several follow up issues and questions that we will now = address on the Email list.    

 

We will be discussing our proposal with a number of = other IETF groups (NTP, IPPM, LMAP) as well as RIPE NCC TTM.  We will = cross-post the results of our discussions on the appropriate lists.

 

To summarize our proposal and the outstanding = issues/questions::

 

1.     &nb= sp; This Destination Option type is Optional and can be turned on/off independently at either end.

 

2.       The field called Packet = Sequence Number is similar to IPID in IPv4 and is primarily intended = to ease and expedite diagnostics, particularly at end points. 

 

3.       The two = Timestamp fields are primarily for network performance triage and = metrics.  These fields can also be utilized for: performance = reporting; by security devices; and for any other functions requiring a highly = granular time reference. 

 

4.       The 3 new fields can also = be utilized together to further enhance network diagnostics and support, = at any point or device in the network path.

 

5.       The 4th field is open to be used = by applications and platforms having &=238220;Special&=238221; performance or diagnostic needs (e.g. Gaming, commerce, etc.).

 

6.       As pointed out by Joel = after the presentation, having synchronized time sources in the devices = being analyzed is critical for effective results when using the network performance (timestamps) features and = functions.  ANY performance monitoring/measurement solution will = require this -- see, for example, RFC 2679 and RFC2681.   We = will discuss this issue with other groups to see how they have dealt with this problem.

 

7.       Both the Packet Sequence = number and the Timestamp fields are per = &=238220;FLOW&=238221;.   After the presentation it was pointed = out that this term was evidently not meaningful or specific enough.  Some would use the = words per &=238220;Session&=238221;, per &=238220;Connection&=238221; =  or per &=238220;Socket&=238221;.  Regardless of the term = applied, the 5 unique identifiers are IP address and port at each end = point, plus the protocol (e.g. UDP, TCP, etc.).  Hopefully that delineates what was referred to in the presentation as = &=238220;Flow&=238221;. 

 

8.       In the question and = answer period of the presentation, it was suggested that this solution = should work fine in private networks, but perhaps not on the Internet.  It is our assertion that this solution should = work on all networks,  as long as the DOH Extension Header is passed = end to end.  Since Extension Headers are an intrinsic component = of the IPv6 Architecture, we should be able to assume this to be true.  If Extension Headers are not being passed along any = given path (Internet or otherwise), then that is an issue/problem that is = much bigger than this proposal and needs to be adequately addressed if = IPv6 is to be successful. 

 

This is the area that we are exploring with other IETF groups.  = We hope to collaborate with them and incorporate their expertise and = experience to build a solution which will be useful for the Internet as well as private networks.

 

 

We feel that a simple and scalable way to provide accurate and timely = diagnostics and performance measurement is what is needed to further the = usability and promote the growth of the Internet as well as implementation of IPv6.

 

If other issues or questions exist, relative to this proposal, we = look forward to addressing them.

 


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_4FC37E442D05A748896589E468752CAA0A7E2A84PWN401EA160entc_-- From cb.list6@gmail.com Wed Aug 7 21: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 2205C21F9CC2 for ; Wed, 7 Aug 2013 21:08:31 -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, 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 eC5GjYw515k3 for ; Wed, 7 Aug 2013 21:08:30 -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 4609821F9CBD for ; Wed, 7 Aug 2013 21:08:30 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so2172117wgh.27 for ; Wed, 07 Aug 2013 21:08:29 -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=D4jvcipYK+zsjTwCM3J3AwApFkh5/YRbTKOsXpd2rFU=; b=GNDOdKSPIrfw8JK6s/sSrrutrAEutv5uSQI0tqucF3ZEPYU+H6DgP0l8fNQCiySQ5W uKHa1E0q/MkrZV+CMvNhL/bdSmxeJsiDUCQNcQXZVy+1tKtCr8uiLsEcuXIBJgvTpOVw H4nmVx2f5tVS/HRiYUktaNEjEY6JXGIBhlzFxJr1EQuNMBRh18PmdyPiuqVdpG9HF38p MLD8nVMJMRkmAInhai4FbR7M18nUempFAuWVOxB9+zpq8F8032E16vrbxrswcxCa0GEY XCYxp3J3xrDIwj2HSwy3B5QlfQJ8ku2ff+Wlh5FzpVrbgoRe0hiWZ2+xuhGyscWrs2Qj EV3g== MIME-Version: 1.0 X-Received: by 10.180.95.2 with SMTP id dg2mr3984237wib.34.1375934909079; Wed, 07 Aug 2013 21:08:29 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Wed, 7 Aug 2013 21:08:28 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Wed, 7 Aug 2013 21:08:28 -0700 (PDT) In-Reply-To: <5200804D.2050006@gmail.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> Date: Wed, 7 Aug 2013 21:08:28 -0700 Message-ID: From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d04426c067d688c04e367cffe Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 04:08:31 -0000 --f46d04426c067d688c04e367cffe Content-Type: text/plain; charset=ISO-8859-1 On Aug 5, 2013 9:49 PM, "Brian E Carpenter" wrote: > > On a different topic, section 5 covers IPv6-only issues. > I'm a bit concerned that this might need a health warning: > deploying NAT64/DNS64 might cause pain and suffering. > Perhaps after this text: > > > Together, RFCs > > 6146 and RFC 6147 provide a viable method for an IPv6-only client to > > initiate communications to an IPv4-only server. > > we should add something like: > > At enterprise level, operating NAT64 and DNS64 services for > heavy usage may have significant practical implications. > Can you be more specific? Pratical data? CB > Also, the last paragraph of section 5: > > > It is worth noting that for IPv6-only access networks that use > > technologies such as NAT64, the more content providers (and > > enterprises) that make their content available over IPv6, the less > > the requirement to apply NAT64 to traffic leaving the access network. > > A reference to RFC 6883 would fit nicely there. > > Regards > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f46d04426c067d688c04e367cffe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 5, 2013 9:49 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> On a different topic, section 5 covers IPv6-only issues.
> I'm a bit concerned that this might need a health warning:
> deploying NAT64/DNS64 might cause pain and suffering.
> Perhaps after this text:
>
> > =A0 =A0Together, RFCs
> > =A0 =A06146 and RFC 6147 provide a viable method for an IPv6-only= client to
> > =A0 =A0initiate communications to an IPv4-only server.
>
> we should add something like:
>
> =A0 =A0At enterprise level, operating NAT64 and DNS64 services for
> =A0 =A0heavy usage may have significant practical implications.
>

Can you be more specific? Pratical data?

CB

> Also, the last paragraph of section 5:
>
> > =A0 =A0It is worth noting that for IPv6-only access networks that= use
> > =A0 =A0technologies such as NAT64, the more content providers (an= d
> > =A0 =A0enterprises) that make their content available over IPv6, = the less
> > =A0 =A0the requirement to apply NAT64 to traffic leaving the acce= ss network.
>
> A reference to RFC 6883 would fit nicely there.
>
> Regards
> =A0 =A0Brian
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--f46d04426c067d688c04e367cffe-- From brian.e.carpenter@gmail.com Wed Aug 7 21:24: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 4AF5711E80EF for ; Wed, 7 Aug 2013 21:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=-0.217, 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 B1K5nVujrfvj for ; Wed, 7 Aug 2013 21:24:06 -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 AF28611E81A6 for ; Wed, 7 Aug 2013 21:24:06 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id qd12so1095276ieb.28 for ; Wed, 07 Aug 2013 21:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5DrwIvAXDpJ3COUYhDwDfsK6oL3XBDfMzb8iu6vl42g=; b=Yigdz9FfOE+1SOW+lCstxu/ChPvuzsNxiuTrS4ORtw3OqdgoMrnBO4BWDfZ7uwdDsv Ges8eAO+l84zIO+Rb2gReILtOT1EgVFFXUhI+zBXXqdFSctZCYvVaGxsMTQR7Fn2AzdM 3O6T33bM6dvkNrz7oIMiiICsTKTy2cJNFrrM+sop6LsPiFkMwTqUFjClLrtD8Rw84dW3 Wsr2pOne4g0uBwQ/d1N2QQK0+Cpx8DOvD4OeH5/93Qal5u6uwotb/1xeQXe2PcPReSjH ajsOb5GKJmC0Z9eJaQ1L/JL4BfSJFczu7Uwbi0cn3B6nQ7DNVHB0vn/k5K5/u2eKcQbx xHoQ== X-Received: by 10.50.22.105 with SMTP id c9mr1246302igf.36.1375935846011; Wed, 07 Aug 2013 21:24:06 -0700 (PDT) Received: from [192.168.178.20] (124.195.69.111.dynamic.snap.net.nz. [111.69.195.124]) by mx.google.com with ESMTPSA id ht10sm4210396igb.2.2013.08.07.21.24.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 21:24:05 -0700 (PDT) Message-ID: <52031D69.3070604@gmail.com> Date: Thu, 08 Aug 2013 16:24:09 +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: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 04:24:07 -0000 On 08/08/2013 16:08, cb.list6 wrote: > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" > wrote: >> On a different topic, section 5 covers IPv6-only issues. >> I'm a bit concerned that this might need a health warning: >> deploying NAT64/DNS64 might cause pain and suffering. >> Perhaps after this text: >> >>> Together, RFCs >>> 6146 and RFC 6147 provide a viable method for an IPv6-only client to >>> initiate communications to an IPv4-only server. >> we should add something like: >> >> At enterprise level, operating NAT64 and DNS64 services for >> heavy usage may have significant practical implications. >> > > Can you be more specific? Pratical data? Not really, because I've never operated one in real life. It doesn't strike me as the sort of service that most enterprise network managers will be familiar with, and a v6-only site needing a normal level of access to v4-land would end up sending most of its external traffic via NAT64 and most of its external DNS queries via DNS64. Therefore, these would become an important single point of failure and a potential bottleneck. The text doesn't seem to point this out. Brian > CB > >> Also, the last paragraph of section 5: >> >>> It is worth noting that for IPv6-only access networks that use >>> technologies such as NAT64, the more content providers (and >>> enterprises) that make their content available over IPv6, the less >>> the requirement to apply NAT64 to traffic leaving the access network. >> A reference to RFC 6883 would fit nicely there. >> >> Regards >> Brian >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Thu Aug 8 00:22: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 9FCDD11E80C5 for ; Thu, 8 Aug 2013 00:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 uRG7L5dlV100 for ; Thu, 8 Aug 2013 00:22:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C32E221F9D96 for ; Thu, 8 Aug 2013 00:21:46 -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 r787LitY002697 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 8 Aug 2013 07:21:44 GMT (envelope-from joelja@bogus.com) Message-ID: <52034701.2050806@bogus.com> Date: Thu, 08 Aug 2013 00:21:37 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: Brian E Carpenter , "cb.list6" References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> In-Reply-To: <52031D69.3070604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 08 Aug 2013 07:21:44 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 07:22:15 -0000 On 8/7/13 9:24 PM, Brian E Carpenter wrote: > On 08/08/2013 16:08, cb.list6 wrote: >> On Aug 5, 2013 9:49 PM, "Brian E Carpenter" >> wrote: >>> On a different topic, section 5 covers IPv6-only issues. >>> I'm a bit concerned that this might need a health warning: >>> deploying NAT64/DNS64 might cause pain and suffering. >>> Perhaps after this text: >>> >>>> Together, RFCs >>>> 6146 and RFC 6147 provide a viable method for an IPv6-only client to >>>> initiate communications to an IPv4-only server. >>> we should add something like: >>> >>> At enterprise level, operating NAT64 and DNS64 services for >>> heavy usage may have significant practical implications. >>> >> Can you be more specific? Pratical data? > Not really, because I've never operated one in real life. It doesn't > strike me as the sort of service that most enterprise network > managers will be familiar with, and a v6-only site needing a normal > level of access to v4-land would end up sending most of its external > traffic via NAT64 and most of its external DNS queries via DNS64. > Therefore, these would become an important single point of failure > and a potential bottleneck. The text doesn't seem to point this out. imho the tools you employ to scale this are about the same as those employed for for nat44 or service load balancing. e.g. stateless hashing, horizontal tiers of translators, no state replication, multiple clusters for different regions/pops/offices etc. the solutions in the marketplace more or less follow along those lines. There are implications for both fragmentation and pmtud for some of those cases that have to be managed, but I don't expect that comes as a surprise. > Brian > >> CB >> >>> Also, the last paragraph of section 5: >>> >>>> It is worth noting that for IPv6-only access networks that use >>>> technologies such as NAT64, the more content providers (and >>>> enterprises) that make their content available over IPv6, the less >>>> the requirement to apply NAT64 to traffic leaving the access network. >>> A reference to RFC 6883 would fit nicely there. >>> >>> Regards >>> Brian >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Thu Aug 8 05:45: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 BEDBD21E80AC for ; Thu, 8 Aug 2013 05:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 bUpOk-H1DR8C for ; Thu, 8 Aug 2013 05:45:42 -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 BD75121E80AD for ; Thu, 8 Aug 2013 05:45:33 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi8so520084wib.9 for ; Thu, 08 Aug 2013 05:45: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=EEz87t9FJE8hGzvd2LpvAU0Zep3YLu0bO3mp4QB26zw=; b=p94iCg14BJyWV9uWwyGbamOSAukCY/cabwJvpnDLDmD04IAXtULZ2iN9AaQp2Lf/KH 90Zzkq0px4ZHBn+p+oEEErRuH/zwmL8WRVPhXj33WZ+cDn1qsNoRlHeAjv4L8zNqQkdH FgXJqGjEYMra7ur0ZCmor6F7q6qbR72+QOSFEFTpAJMEehzL+L909XCVM0ew1UqUTUXY yDjE131nlNrUrnWFo0sD/6DhXimlDm6O1yZBGrZlnD6/k5cJX+Csj8HC52INK4JBbh8Y 1Q7slcwYra4w419QK0OAF2UfOPpp+eykUx2BTsRJVCKnhIKFCQy8tAdzttvrsWImM7gO Sp2Q== MIME-Version: 1.0 X-Received: by 10.180.188.49 with SMTP id fx17mr4948185wic.49.1375965932745; Thu, 08 Aug 2013 05:45:32 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Thu, 8 Aug 2013 05:45:32 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Thu, 8 Aug 2013 05:45:32 -0700 (PDT) In-Reply-To: <52031D69.3070604@gmail.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> Date: Thu, 8 Aug 2013 05:45:32 -0700 Message-ID: From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c25bdaa4f93104e36f08a4 Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 12:45:42 -0000 --001a11c25bdaa4f93104e36f08a4 Content-Type: text/plain; charset=ISO-8859-1 On Aug 7, 2013 9:24 PM, "Brian E Carpenter" wrote: > > On 08/08/2013 16:08, cb.list6 wrote: > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" > > wrote: > >> On a different topic, section 5 covers IPv6-only issues. > >> I'm a bit concerned that this might need a health warning: > >> deploying NAT64/DNS64 might cause pain and suffering. > >> Perhaps after this text: > >> > >>> Together, RFCs > >>> 6146 and RFC 6147 provide a viable method for an IPv6-only client to > >>> initiate communications to an IPv4-only server. > >> we should add something like: > >> > >> At enterprise level, operating NAT64 and DNS64 services for > >> heavy usage may have significant practical implications. > >> > > > > Can you be more specific? Pratical data? > > Not really, because I've never operated one in real life. It doesn't > strike me as the sort of service that most enterprise network > managers will be familiar with, and a v6-only site needing a normal > level of access to v4-land would end up sending most of its external > traffic via NAT64 and most of its external DNS queries via DNS64. > Therefore, these would become an important single point of failure > and a potential bottleneck. The text doesn't seem to point this out. > Agree with Joel, nat64 will be parity with common nat44 and firewalls in terms of availability Regarding majority of traffic, i believe the scales have tipped to show v6 is the majority for campus networks, which is the best proxy in the available data http://www.worldipv6launch.org/measurements/ These numbers also skew low since Apple has a non-deterministic happy eyeballs Given that enterprises and all users of IP are out of ipv4, so they need to not use ipv4 yet have access to it, guidance against nat64 will frustrate the issue. Guidance should be given to make as many flow v6 e2e. Full stop. CB > Brian > > > CB > > > >> Also, the last paragraph of section 5: > >> > >>> It is worth noting that for IPv6-only access networks that use > >>> technologies such as NAT64, the more content providers (and > >>> enterprises) that make their content available over IPv6, the less > >>> the requirement to apply NAT64 to traffic leaving the access network. > >> A reference to RFC 6883 would fit nicely there. > >> > >> Regards > >> Brian > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c25bdaa4f93104e36f08a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2013 9:24 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> On 08/08/2013 16:08, cb.list6 wrote:
> > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>=
> > wrote:
> >> On a different topic, section 5 covers IPv6-only issues.
> >> I'm a bit concerned that this might need a health warning= :
> >> deploying NAT64/DNS64 might cause pain and suffering.
> >> Perhaps after this text:
> >>
> >>> =A0 =A0Together, RFCs
> >>> =A0 =A06146 and RFC 6147 provide a viable method for an I= Pv6-only client to
> >>> =A0 =A0initiate communications to an IPv4-only server. > >> we should add something like:
> >>
> >> =A0 =A0At enterprise level, operating NAT64 and DNS64 service= s for
> >> =A0 =A0heavy usage may have significant practical implication= s.
> >>
> >
> > Can you be more specific? Pratical data?
>
> Not really, because I've never operated one in real life. It doesn= 't
> strike me as the sort of service that most enterprise network
> managers will be familiar with, and a v6-only site needing a normal > level of access to v4-land would end up sending most of its external > traffic via NAT64 and most of its external DNS queries via DNS64.
> Therefore, these would become an important single point of failure
> and a potential bottleneck. The text doesn't seem to point this ou= t.
>

Agree with Joel, nat64 will be parity with common nat44 and = firewalls in terms of availability

Regarding majority of traffic, i believe the scales have tip= ped to show v6 is the majority for campus networks, which is the best proxy= in the available data

htt= p://www.worldipv6launch.org/measurements/

These numbers also skew low since Apple has a non-determinis= tic happy eyeballs

Given that enterprises and all users of IP are out of ipv4, = so they need to not use ipv4 yet have access to it, guidance against nat64 = will frustrate the issue.

Guidance should be given to make as many flow v6 e2e. Full s= top.

CB
> =A0 =A0Brian
>
> > CB
> >
> >> Also, the last paragraph of section 5:
> >>
> >>> =A0 =A0It is worth noting that for IPv6-only access netwo= rks that use
> >>> =A0 =A0technologies such as NAT64, the more content provi= ders (and
> >>> =A0 =A0enterprises) that make their content available ove= r IPv6, the less
> >>> =A0 =A0the requirement to apply NAT64 to traffic leaving = the access network.
> >> A reference to RFC 6883 would fit nicely there.
> >>
> >> Regards
> >> =A0 =A0Brian
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/v6ops
> >

--001a11c25bdaa4f93104e36f08a4-- From nygren@gmail.com Thu Aug 8 06:37: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 24AEC21F918C for ; Thu, 8 Aug 2013 06:37:26 -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 ykh3lmgpFzL5 for ; Thu, 8 Aug 2013 06:37:25 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5B91E21E804E for ; Thu, 8 Aug 2013 06:37:23 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz11so3039155veb.22 for ; Thu, 08 Aug 2013 06:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QvmNOniPXvrXeKLk6ga6rmtvDCj2pgKTO2zvcMipgHg=; b=jJL+roEvRRJrnpyy8qgpXLyKfTgFzSoOmZ/iyS8iFGvFMwfJdNuBz6ps/cw6alI7nk g/882oE5KqkYAVmoJG0bVHd1NAs9Cib5RcXhEG5sfmRHvC2H0zEOTVpgo1+BhFvPSnKF X2TbH4nB0BNFcvX6FMaH6eW8egcVmnygwcgDZRC1gKnDZqO/xg74ifVmzxLjdYxMcN6B Xkr9rXj/8K1QuADqEoqDc/HYJXU6LOehcJxf6ei4c5FT7HJrbr5iPBFp30TFEut8RWBm 3P3R37c2YBQbWyCPhtVVdec3Xl+1VH310tIZuQtjBPqnwG/qVhZQijsNTWVGw6b5H647 ncsw== MIME-Version: 1.0 X-Received: by 10.220.89.73 with SMTP id d9mr3978843vcm.87.1375969040444; Thu, 08 Aug 2013 06:37:20 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.91.132 with HTTP; Thu, 8 Aug 2013 06:37:20 -0700 (PDT) In-Reply-To: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> Date: Thu, 8 Aug 2013 09:37:20 -0400 X-Google-Sender-Auth: Q33hOBqs9Ua5MU9gKfTAOHsR-EQ Message-ID: From: Erik Nygren To: "cb.list6" Content-Type: multipart/alternative; boundary=047d7b3a8e94e0b4e904e36fc1f8 Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:37:27 -0000 --047d7b3a8e94e0b4e904e36fc1f8 Content-Type: text/plain; charset=ISO-8859-1 It's also likely the case that at least some enterprises control portions of their environments well enough that mostly-IPv6 could potentially be much more viable than a residential environment. For example, a retail store chain using HTTP-based POS terminals and kiosks may have enough control over their environment that they could ideally deploy an IPv6-only environment and just use NAT64/DNS64 to get to some of their supplier websites that still require IPv4. It might also be attractive to some US Government agencies who control the devices and clients within their network to use this approach as part of meeting the OMB September 2014 mandate for IPv6 client support. That could be simpler for those agencies than rolling out a dual-stack environment. (I'm very curious if either of these cases exists in production in the field today...) Erik On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 wrote: > > On Aug 7, 2013 9:24 PM, "Brian E Carpenter" > wrote: > > > > On 08/08/2013 16:08, cb.list6 wrote: > > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" < > brian.e.carpenter@gmail.com> > > > wrote: > > >> On a different topic, section 5 covers IPv6-only issues. > > >> I'm a bit concerned that this might need a health warning: > > >> deploying NAT64/DNS64 might cause pain and suffering. > > >> Perhaps after this text: > > >> > > >>> Together, RFCs > > >>> 6146 and RFC 6147 provide a viable method for an IPv6-only client > to > > >>> initiate communications to an IPv4-only server. > > >> we should add something like: > > >> > > >> At enterprise level, operating NAT64 and DNS64 services for > > >> heavy usage may have significant practical implications. > > >> > > > > > > Can you be more specific? Pratical data? > > > > Not really, because I've never operated one in real life. It doesn't > > strike me as the sort of service that most enterprise network > > managers will be familiar with, and a v6-only site needing a normal > > level of access to v4-land would end up sending most of its external > > traffic via NAT64 and most of its external DNS queries via DNS64. > > Therefore, these would become an important single point of failure > > and a potential bottleneck. The text doesn't seem to point this out. > > > > Agree with Joel, nat64 will be parity with common nat44 and firewalls in > terms of availability > > Regarding majority of traffic, i believe the scales have tipped to show v6 > is the majority for campus networks, which is the best proxy in the > available data > > http://www.worldipv6launch.org/measurements/ > > These numbers also skew low since Apple has a non-deterministic happy > eyeballs > > Given that enterprises and all users of IP are out of ipv4, so they need > to not use ipv4 yet have access to it, guidance against nat64 will > frustrate the issue. > > Guidance should be given to make as many flow v6 e2e. Full stop. > > CB > > > Brian > > > > > CB > > > > > >> Also, the last paragraph of section 5: > > >> > > >>> It is worth noting that for IPv6-only access networks that use > > >>> technologies such as NAT64, the more content providers (and > > >>> enterprises) that make their content available over IPv6, the less > > >>> the requirement to apply NAT64 to traffic leaving the access > network. > > >> A reference to RFC 6883 would fit nicely there. > > >> > > >> Regards > > >> Brian > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b3a8e94e0b4e904e36fc1f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's also likely the case that at least some enterprises control portio= ns of
their environments well enough that mostly-IPv6 could potentially= be much
more viable than a residential environment.=A0 For example, a r= etail store chain using
HTTP-based POS terminals and kiosks may have enough control over their envi= ronment
that they could ideally deploy an IPv6-only environment and just= use NAT64/DNS64
to get to some of their supplier websites that still re= quire IPv4.
It might also be attractive to some US Government agencies who control
t= he devices and clients within their network to use this approach as partof meeting the OMB September 2014 mandate for IPv6 client support.=A0
That could be simpler for those agencies than rolling out a dual-stack envi= ronment.
(I'm very curious if either of these cases exists in produc= tion in the field today...)

=A0=A0=A0=A0=A0 Erik


On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 <cb.list6@gmail.com> wrote:


On Aug 7, 2013 9:24 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com= > wrote:
>
> On 08/08/2013 16:08, cb.list6 wrote:
> > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" <brian.e.carpenter= @gmail.com>
> > wrote:
> >> On a different topic, section 5 covers IPv6-only issues.
> >> I'm a bit concerned that this might need a health warning= :
> >> deploying NAT64/DNS64 might cause pain and suffering.
> >> Perhaps after this text:
> >>
> >>> =A0 =A0Together, RFCs
> >>> =A0 =A06146 and RFC 6147 provide a viable method for an I= Pv6-only client to
> >>> =A0 =A0initiate communications to an IPv4-only server. > >> we should add something like:
> >>
> >> =A0 =A0At enterprise level, operating NAT64 and DNS64 service= s for
> >> =A0 =A0heavy usage may have significant practical implication= s.
> >>
> >
> > Can you be more specific? Pratical data?
>
> Not really, because I've never operated one in real life. It doesn= 't
> strike me as the sort of service that most enterprise network
> managers will be familiar with, and a v6-only site needing a normal > level of access to v4-land would end up sending most of its external > traffic via NAT64 and most of its external DNS queries via DNS64.
> Therefore, these would become an important single point of failure
> and a potential bottleneck. The text doesn't seem to point this ou= t.
>

Agree with Joel, nat64 will be parity with common nat4= 4 and firewalls in terms of availability

Regarding majority of traffic, i believe the scales have tip= ped to show v6 is the majority for campus networks, which is the best proxy= in the available data

http://www.worldipv6launch.org/measurements/

These numbers also skew low since Apple has a non-determinis= tic happy eyeballs

Given that enterprises and all users of IP are out of ipv4, = so they need to not use ipv4 yet have access to it, guidance against nat64 = will frustrate the issue.

Guidance should be given to make as many flow v6 e2e. Full s= top.

CB


> =A0 =A0Brian
>
> > CB
> >
> >> Also, the last paragraph of section 5:
> >>
> >>> =A0 =A0It is worth noting that for IPv6-only access netwo= rks that use
> >>> =A0 =A0technologies such as NAT64, the more content provi= ders (and
> >>> =A0 =A0enterprises) that make their content available ove= r IPv6, the less
> >>> =A0 =A0the requirement to apply NAT64 to traffic leaving = the access network.
> >> A reference to RFC 6883 would fit nicely there.
> >>
> >> Regards
> >> =A0 =A0Brian
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >


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


--047d7b3a8e94e0b4e904e36fc1f8-- From v6ops@globis.net Thu Aug 8 09:31:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13EF21E8089 for ; Thu, 8 Aug 2013 09:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VouFOq6k-GBX for ; Thu, 8 Aug 2013 09:31:57 -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 85FA911E8152 for ; Thu, 8 Aug 2013 09:31:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2AEC08700DF; Thu, 8 Aug 2013 18:31:40 +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 YplzXTzPPAlF; Thu, 8 Aug 2013 18:31:40 +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 DE521870025; Thu, 8 Aug 2013 18:31:39 +0200 (CEST) Message-ID: <5203C7E5.3060106@globis.net> Date: Thu, 08 Aug 2013 18:31:33 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Erik Nygren References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 16:31:57 -0000 Erik Nygren wrote: > It's also likely the case that at least some enterprises control > portions of > their environments well enough that mostly-IPv6 could potentially be much > more viable than a residential environment. For example, a retail > store chain using > HTTP-based POS terminals and kiosks may have enough control over their > environment > that they could ideally deploy an IPv6-only environment and just use > NAT64/DNS64 > to get to some of their supplier websites that still require IPv4. > It might also be attractive to some US Government agencies who control > the devices and clients within their network to use this approach as part > of meeting the OMB September 2014 mandate for IPv6 client support. > That could be simpler for those agencies than rolling out a dual-stack > environment. > (I'm very curious if either of these cases exists in production in the > field today...) > > Erik > Why would anyone in their right mind chose to deploy NAT64/DNS64 in a commercial environment given the prices I've seen for that functionality? I can't imagine them wanting something like that in operations either. It's likely to be much cheaper to let legacy applications die off naturally, run dual stack or even dual servers for some systems, and deploy a combination of simple forward and reverse web proxies for the rest (assuming web based apps). AFAIK There's still stuff happily running Bisync (BSC) out there (over IP tunnels) and support for that was deprecated in the 1970's in favour of SNA. So I wouldn't hold your breathe waiting for 100% migration to IPv6. It's going to be pretty easy to maintain a private IPv4 - IPv4 network over a GRE tunnel over an IPv6 Internet for a very long time yet. > > On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 > wrote: > > > On Aug 7, 2013 9:24 PM, "Brian E Carpenter" > > > wrote: > > > > On 08/08/2013 16:08, cb.list6 wrote: > > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" > > > > > wrote: > > >> On a different topic, section 5 covers IPv6-only issues. > > >> I'm a bit concerned that this might need a health warning: > > >> deploying NAT64/DNS64 might cause pain and suffering. > > >> Perhaps after this text: > > >> > > >>> Together, RFCs > > >>> 6146 and RFC 6147 provide a viable method for an > IPv6-only client to > > >>> initiate communications to an IPv4-only server. > > >> we should add something like: > > >> > > >> At enterprise level, operating NAT64 and DNS64 services for > > >> heavy usage may have significant practical implications. > > >> > > > > > > Can you be more specific? Pratical data? > > > > Not really, because I've never operated one in real life. It doesn't > > strike me as the sort of service that most enterprise network > > managers will be familiar with, and a v6-only site needing a normal > > level of access to v4-land would end up sending most of its external > > traffic via NAT64 and most of its external DNS queries via DNS64. > > Therefore, these would become an important single point of failure > > and a potential bottleneck. The text doesn't seem to point this out. > > > > Agree with Joel, nat64 will be parity with common nat44 and > firewalls in terms of availability > > Regarding majority of traffic, i believe the scales have tipped to > show v6 is the majority for campus networks, which is the best > proxy in the available data > > http://www.worldipv6launch.org/measurements/ > > These numbers also skew low since Apple has a non-deterministic > happy eyeballs > > Given that enterprises and all users of IP are out of ipv4, so > they need to not use ipv4 yet have access to it, guidance against > nat64 will frustrate the issue. > > Guidance should be given to make as many flow v6 e2e. Full stop. > > CB > > > > Brian > > > > > CB > > > > > >> Also, the last paragraph of section 5: > > >> > > >>> It is worth noting that for IPv6-only access networks > that use > > >>> technologies such as NAT64, the more content providers (and > > >>> enterprises) that make their content available over IPv6, > the less > > >>> the requirement to apply NAT64 to traffic leaving the > access network. > > >> A reference to RFC 6883 would fit nicely there. > > >> > > >> Regards > > >> Brian > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- Regards, RayH From cb.list6@gmail.com Thu Aug 8 10:00:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDA211E81F5 for ; Thu, 8 Aug 2013 10:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 nBwKqeT-832R for ; Thu, 8 Aug 2013 10:00:37 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65721F9FF3 for ; Thu, 8 Aug 2013 10:00:36 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z12so2827430wgg.22 for ; Thu, 08 Aug 2013 10:00:36 -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=2miApMDB1WBpP/sMUXCERRlMBA5GxTs+SQxmStHTU8M=; b=nCJ7w11hSntkbHE4V3GX6zWoOZgUwmjKj9OQVG1uxPWOb1m8qgR3/QS7eKZgzKr7ec aoHnb8C4i3vG5vtbMyVUYBi+iubfyn+oddKEskHiE4E0gwWdGL3jlWLR6b1vCs+rnUOb B6Bw0fLld3wWte8HHxtrTw3f1DUkfvU/i+x4x9i5SSSyuoit7794rPJGR2ziuZFL04ce Te8VljHtVzFvco5Z8Ite/KIa7yCIWb3tZU8BaG36WBxX0mdYKNy2Bt6U68bnGjB2Kowy 4dhKvDG5TkOmnvtzFw6y+2YW/cilC6IRJUF4P4qz8v8ZDnAuWVT9csq4XUAfHYAmr5fV 7zng== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr4070620wjn.23.1375981235979; Thu, 08 Aug 2013 10:00:35 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Thu, 8 Aug 2013 10:00:35 -0700 (PDT) In-Reply-To: <5203C7E5.3060106@globis.net> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> Date: Thu, 8 Aug 2013 10:00:35 -0700 Message-ID: From: "cb.list6" To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:00:38 -0000 On Thu, Aug 8, 2013 at 9:31 AM, Ray Hunter wrote: > Erik Nygren wrote: >> It's also likely the case that at least some enterprises control >> portions of >> their environments well enough that mostly-IPv6 could potentially be much >> more viable than a residential environment. For example, a retail >> store chain using >> HTTP-based POS terminals and kiosks may have enough control over their >> environment >> that they could ideally deploy an IPv6-only environment and just use >> NAT64/DNS64 >> to get to some of their supplier websites that still require IPv4. >> It might also be attractive to some US Government agencies who control >> the devices and clients within their network to use this approach as part >> of meeting the OMB September 2014 mandate for IPv6 client support. >> That could be simpler for those agencies than rolling out a dual-stack >> environment. >> (I'm very curious if either of these cases exists in production in the >> field today...) >> >> Erik >> > > Why would anyone in their right mind chose to deploy NAT64/DNS64 in a > commercial environment given the prices I've seen for that functionality? > If your situation is that you need a middlebox as part of an IPv4 exhaustion remediation, NAT44 and NAT64 are largely the same costs in my experience. YMMV. For the particularly cost conscious and FOSS friendly, there are FOSS options for both. NAT64 is in-fact cheaper since only non-IPv6 flows need translation as where NAT44 requires translation of all flows. CB > I can't imagine them wanting something like that in operations either. > > It's likely to be much cheaper to let legacy applications die off > naturally, run dual stack or even dual servers for some systems, and > deploy a combination of simple forward and reverse web proxies for the > rest (assuming web based apps). > > AFAIK There's still stuff happily running Bisync (BSC) out there (over > IP tunnels) and support for that was deprecated in the 1970's in favour > of SNA. So I wouldn't hold your breathe waiting for 100% migration to > IPv6. It's going to be pretty easy to maintain a private IPv4 - IPv4 > network over a GRE tunnel over an IPv6 Internet for a very long time yet. > >> >> On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 > > wrote: >> >> >> On Aug 7, 2013 9:24 PM, "Brian E Carpenter" >> > >> wrote: >> > >> > On 08/08/2013 16:08, cb.list6 wrote: >> > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" >> > >> > > wrote: >> > >> On a different topic, section 5 covers IPv6-only issues. >> > >> I'm a bit concerned that this might need a health warning: >> > >> deploying NAT64/DNS64 might cause pain and suffering. >> > >> Perhaps after this text: >> > >> >> > >>> Together, RFCs >> > >>> 6146 and RFC 6147 provide a viable method for an >> IPv6-only client to >> > >>> initiate communications to an IPv4-only server. >> > >> we should add something like: >> > >> >> > >> At enterprise level, operating NAT64 and DNS64 services for >> > >> heavy usage may have significant practical implications. >> > >> >> > > >> > > Can you be more specific? Pratical data? >> > >> > Not really, because I've never operated one in real life. It doesn't >> > strike me as the sort of service that most enterprise network >> > managers will be familiar with, and a v6-only site needing a normal >> > level of access to v4-land would end up sending most of its external >> > traffic via NAT64 and most of its external DNS queries via DNS64. >> > Therefore, these would become an important single point of failure >> > and a potential bottleneck. The text doesn't seem to point this out. >> > >> >> Agree with Joel, nat64 will be parity with common nat44 and >> firewalls in terms of availability >> >> Regarding majority of traffic, i believe the scales have tipped to >> show v6 is the majority for campus networks, which is the best >> proxy in the available data >> >> http://www.worldipv6launch.org/measurements/ >> >> These numbers also skew low since Apple has a non-deterministic >> happy eyeballs >> >> Given that enterprises and all users of IP are out of ipv4, so >> they need to not use ipv4 yet have access to it, guidance against >> nat64 will frustrate the issue. >> >> Guidance should be given to make as many flow v6 e2e. Full stop. >> >> CB >> >> >> > Brian >> > >> > > CB >> > > >> > >> Also, the last paragraph of section 5: >> > >> >> > >>> It is worth noting that for IPv6-only access networks >> that use >> > >>> technologies such as NAT64, the more content providers (and >> > >>> enterprises) that make their content available over IPv6, >> the less >> > >>> the requirement to apply NAT64 to traffic leaving the >> access network. >> > >> A reference to RFC 6883 would fit nicely there. >> > >> >> > >> Regards >> > >> Brian >> > >> _______________________________________________ >> > >> v6ops mailing list >> > >> v6ops@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/v6ops >> > > >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > -- > Regards, > RayH > From gert@space.net Thu Aug 8 10:05: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 7BA4411E8135 for ; Thu, 8 Aug 2013 10:05:42 -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 okKbnntq0XhM for ; Thu, 8 Aug 2013 10:05:41 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 1143011E81F5 for ; Thu, 8 Aug 2013 10:05:41 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2F9776081F for ; Thu, 8 Aug 2013 19:05:34 +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 078B46085B for ; Thu, 8 Aug 2013 19:05:34 +0200 (CEST) Received: (qmail 66904 invoked by uid 1007); 8 Aug 2013 19:05:33 +0200 Date: Thu, 8 Aug 2013 19:05:33 +0200 From: Gert Doering To: Ray Hunter Message-ID: <20130808170533.GI65295@Space.Net> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5203C7E5.3060106@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:05:42 -0000 Hi, On Thu, Aug 08, 2013 at 06:31:33PM +0200, Ray Hunter wrote: > Why would anyone in their right mind chose to deploy NAT64/DNS64 in a > commercial environment given the prices I've seen for that functionality? To get rid of dual-stack operations, while still being able to benefit from the large address space of IPv6 inside the enterprise? Dual-stack is a major cost factor. 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 v6ops@globis.net Thu Aug 8 10:28:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E990811E81E1 for ; Thu, 8 Aug 2013 10:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 Mv5cFesKcZzI for ; Thu, 8 Aug 2013 10:28:40 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB81211E815B for ; Thu, 8 Aug 2013 10:28:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9D5458700EA; Thu, 8 Aug 2013 19:28:23 +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 JWTHid2ddx2E; Thu, 8 Aug 2013 19:28:23 +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 6A8E68700E1; Thu, 8 Aug 2013 19:28:23 +0200 (CEST) Message-ID: <5203D531.1080207@globis.net> Date: Thu, 08 Aug 2013 19:28:17 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Gert Doering References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> In-Reply-To: <20130808170533.GI65295@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:28:41 -0000 > Gert Doering > 8 August 2013 19:05 > Hi, > > To get rid of dual-stack operations, while still being able to benefit > from the large address space of IPv6 inside the enterprise? Who has an IPv4 address shortage *inside* the enterprise? And what are these benefits *inside* the enterprise? LAN switches are written off over at least 10 years in the book keeping. AFAICS the only thing most large enterprises are worried about right now is the border, and Internet and outward facing systems (and rightly so). They'll be able to run *private* IPv4 networks over MPLS or GRE or something else for many many years to come, with all of their important partners, and there'll be plenty of vendors wiling to support them on old kit at cut prices. If SNA or DECnet IV is any transition model to go by, it took about 20 years for them to die inside most enterprises, whilst they generally died much quicker at the border. It went something like: native SNA or native routed DECnet IV on original vendor equipment -> multi-protocol routers -> tunnelled SNA or DECnet IV -> islands with gateways -> islands -> switch off. The final straw was making end users pay pro-rata for the support costs of the shrinking infra. IMVHO Whilst there's still economies of scale, there's simply no business case *inside* the enterprise except for opportunistic switch on at standard scheduled lifecycle renewal. I've been through this loop myself. But then again, why should the IETF care what happens in that case if the border interface is clean and IPv6 only? > > Dual-stack is a major cost factor. > > Gert Doering > -- NetMaster > Ray Hunter > 8 August 2013 18:31 > Erik Nygren wrote: >> It's also likely the case that at least some enterprises control >> portions of >> their environments well enough that mostly-IPv6 could potentially be much >> more viable than a residential environment. For example, a retail >> store chain using >> HTTP-based POS terminals and kiosks may have enough control over their >> environment >> that they could ideally deploy an IPv6-only environment and just use >> NAT64/DNS64 >> to get to some of their supplier websites that still require IPv4. >> It might also be attractive to some US Government agencies who control >> the devices and clients within their network to use this approach as part >> of meeting the OMB September 2014 mandate for IPv6 client support. >> That could be simpler for those agencies than rolling out a dual-stack >> environment. >> (I'm very curious if either of these cases exists in production in the >> field today...) >> >> Erik >> > > Why would anyone in their right mind chose to deploy NAT64/DNS64 in a > commercial environment given the prices I've seen for that functionality? > > I can't imagine them wanting something like that in operations either. > > It's likely to be much cheaper to let legacy applications die off > naturally, run dual stack or even dual servers for some systems, and > deploy a combination of simple forward and reverse web proxies for the > rest (assuming web based apps). > > AFAIK There's still stuff happily running Bisync (BSC) out there (over > IP tunnels) and support for that was deprecated in the 1970's in favour > of SNA. So I wouldn't hold your breathe waiting for 100% migration to > IPv6. It's going to be pretty easy to maintain a private IPv4 - IPv4 > network over a GRE tunnel over an IPv6 Internet for a very long time yet. > >> On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 > > wrote: >> >> >> On Aug 7, 2013 9:24 PM, "Brian E Carpenter" >> > >> wrote: >> > >> > On 08/08/2013 16:08, cb.list6 wrote: >> > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" >> > >> > > wrote: >> > >> On a different topic, section 5 covers IPv6-only issues. >> > >> I'm a bit concerned that this might need a health warning: >> > >> deploying NAT64/DNS64 might cause pain and suffering. >> > >> Perhaps after this text: >> > >> >> > >>> Together, RFCs >> > >>> 6146 and RFC 6147 provide a viable method for an >> IPv6-only client to >> > >>> initiate communications to an IPv4-only server. >> > >> we should add something like: >> > >> >> > >> At enterprise level, operating NAT64 and DNS64 services for >> > >> heavy usage may have significant practical implications. >> > >> >> > > >> > > Can you be more specific? Pratical data? >> > >> > Not really, because I've never operated one in real life. It doesn't >> > strike me as the sort of service that most enterprise network >> > managers will be familiar with, and a v6-only site needing a normal >> > level of access to v4-land would end up sending most of its external >> > traffic via NAT64 and most of its external DNS queries via DNS64. >> > Therefore, these would become an important single point of failure >> > and a potential bottleneck. The text doesn't seem to point this out. >> > >> >> Agree with Joel, nat64 will be parity with common nat44 and >> firewalls in terms of availability >> >> Regarding majority of traffic, i believe the scales have tipped to >> show v6 is the majority for campus networks, which is the best >> proxy in the available data >> >> http://www.worldipv6launch.org/measurements/ >> >> These numbers also skew low since Apple has a non-deterministic >> happy eyeballs >> >> Given that enterprises and all users of IP are out of ipv4, so >> they need to not use ipv4 yet have access to it, guidance against >> nat64 will frustrate the issue. >> >> Guidance should be given to make as many flow v6 e2e. Full stop. >> >> CB >> >> >> > Brian >> > >> > > CB >> > > >> > >> Also, the last paragraph of section 5: >> > >> >> > >>> It is worth noting that for IPv6-only access networks >> that use >> > >>> technologies such as NAT64, the more content providers (and >> > >>> enterprises) that make their content available over IPv6, >> the less >> > >>> the requirement to apply NAT64 to traffic leaving the >> access network. >> > >> A reference to RFC 6883 would fit nicely there. >> > >> >> > >> Regards >> > >> Brian >> > >> _______________________________________________ >> > >> v6ops mailing list >> > >> v6ops@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/v6ops >> > > >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > ------------------------------------------------------------------------ -- Regards, RayH From tore@fud.no Thu Aug 8 10:45: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 D57E011E8205 for ; Thu, 8 Aug 2013 10:45:29 -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 dbMzcIsapnFx for ; Thu, 8 Aug 2013 10:45:29 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 0F65711E81F8 for ; Thu, 8 Aug 2013 10:45:27 -0700 (PDT) Received: from [2a02:fe0:cf16:40:b6b6:76ff:fe17:2e83] (port=56417 helo=sloth.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1V7UH7-0002bE-HU; Thu, 08 Aug 2013 19:45:25 +0200 Message-ID: <5203D935.1090102@fud.no> Date: Thu, 08 Aug 2013 19:45:25 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ray Hunter References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> In-Reply-To: <5203D531.1080207@globis.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:45:30 -0000 * Ray Hunter > Who has an IPv4 address shortage *inside* the enterprise? I do, as do many other. FWIW, these days all sorts of enterprises in the RIPE region become LIRs just to get their hands on a measly /22 for their own use. > And what are these benefits *inside* the enterprise? I'd love to be able to shut off IPv4 completely, as dual stack means ~dual complexity and ~dual operational overhead. > LAN switches are written off over at least 10 years in the book keeping. What does that have to with IPv4 shortage? Tore From gert@space.net Thu Aug 8 10:47: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 4907321F9C0D for ; Thu, 8 Aug 2013 10:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1ZHovoXGj6w for ; Thu, 8 Aug 2013 10:47:03 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC901F0D35 for ; Thu, 8 Aug 2013 10:47:02 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 708C760A24 for ; Thu, 8 Aug 2013 19:47:01 +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 4B41360A19 for ; Thu, 8 Aug 2013 19:47:01 +0200 (CEST) Received: (qmail 80549 invoked by uid 1007); 8 Aug 2013 19:47:01 +0200 Date: Thu, 8 Aug 2013 19:47:01 +0200 From: Gert Doering To: Ray Hunter Message-ID: <20130808174701.GL65295@Space.Net> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U1Fr+mZHKwKJ1EEe" Content-Disposition: inline In-Reply-To: <5203D531.1080207@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:47:04 -0000 --U1Fr+mZHKwKJ1EEe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 08, 2013 at 07:28:17PM +0200, Ray Hunter wrote: > > To get rid of dual-stack operations, while still being able to benefit > > from the large address space of IPv6 inside the enterprise? > Who has an IPv4 address shortage *inside* the enterprise? > And what are these benefits *inside* the enterprise? Well, I see lots of (even small) enterprises that have *collisions* on IPv4 all over the place - mergers, VPNs to partners, etc. - and of course workarounds are found, like "double NAT on VPN links", leading to extra costs that people take for granted. Add to that the usual problem of "how big do I size my subnet", which is also needless annoyance from the past. I don't think running IPv6-only inside an enterprise can be done today (legacy applications being the largest obstacle, plus inertia on the side of enterprise network admins), but I do see quite some benefit in having IPv6 - and if I have that, I want to get rid of IPv4 as fast as possible. > LAN switches are written off over at least 10 years in the book keeping. We started using IPv6 in 1997. Your point being? 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 --U1Fr+mZHKwKJ1EEe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQCVAwUBUgPZlakuBuNlUUl1AQIIUQP9Frla5/beKE0e428L9+T2/RHaU3WUInhh imr2XApeM22a3kgioxygIPcSZm5sGy+2Fp6Tngouz+wjFYJFL0y8BkJ3vrxCIZqn YL85abghLmQMNx//EcBzpQH8kfYs++y7PDweKBOgcCcyXJ2bd1KhBcH8rwkgJCqD b1dNeajb6H0= =/5td -----END PGP SIGNATURE----- --U1Fr+mZHKwKJ1EEe-- From owen@delong.com Thu Aug 8 10: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 3A4ED1F0D38 for ; Thu, 8 Aug 2013 10:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPU8KJXkkdT7 for ; Thu, 8 Aug 2013 10:56:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1B921F9E99 for ; Thu, 8 Aug 2013 10:56:08 -0700 (PDT) Received: from [172.26.54.172] (63-234-219-145.dia.static.qwest.net [63.234.219.145]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r78HsouP010759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Aug 2013 10:54:51 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r78HsouP010759 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1375984492; bh=rE46qutbRjxWD45uHi/m86AjYOE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NaMxMxVfcE61fcexnwOWCA24r5+yCmwbQ+qTZ1jY5E7fBCXMJUlt8PH9mEPkM3Gsl BLVIZlf+OrpvJV7//D/sd1PIMlpmkOyNJyLFDbMU+q+iJZtjXRW+ebTnQOajqj/OYC AZiVqtDvW/ji6aspDdGhlFB8Mq5tViSp9NGq0ZZo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <5203D531.1080207@globis.net> Date: Thu, 8 Aug 2013 10:54:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> To: Ray Hunter 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]); Thu, 08 Aug 2013 10:54:52 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:56:11 -0000 On Aug 8, 2013, at 10:28 AM, Ray Hunter wrote: >> Gert Doering >> 8 August 2013 19:05 >> Hi, >>=20 >> To get rid of dual-stack operations, while still being able to = benefit >> from the large address space of IPv6 inside the enterprise? > Who has an IPv4 address shortage *inside* the enterprise? > And what are these benefits *inside* the enterprise? > LAN switches are written off over at least 10 years in the book = keeping. Arguably, anyone using RFC-1918 space is suffering from an address shortage inside their enterprise. Given the clear and obvious benefits of eliminating NAT and having globally unique addresses for every system which communicates with the internet, I wonder how you can ask such a question with a straight face. A 10 year depreciation on switches is absurd. Most enterprises I know of use either a 3-year or 5-year depreciation schedule for network = equipment such as LAN switches and many end up retiring them faster than they depreciate. > AFAICS the only thing most large enterprises are worried about right = now > is the border, and Internet and outward facing systems (and rightly = so). > They'll be able to run *private* IPv4 networks over MPLS or GRE or > something else for many many years to come, with all of their = important > partners, and there'll be plenty of vendors wiling to support them on > old kit at cut prices. I think you are right about what most enterprises are worried about = right now (if they are even paying attention at all). However, enterprises are not exactly known for paying attention to anything more than 3 months away from now, so I don't think that's a great yardstick. It will be interesting to see how this plays out. I think that the cost = of continuing to support IPv4 in the face of an ever-increasing proportion of the internet not being IPv4 capable will lead enterprises to abandon IPv4 for the most part much faster than is currently anticipated. We saw this with the IPX->IP transition. Everyone thought we'd be running IPX everywhere for 20-30 years, yet once IP gained critical mass in the enterprise, IPX all but disappeared in less than 5 years. > If SNA or DECnet IV is any transition model to go by, it took about 20 > years for them to die inside most enterprises, whilst they generally > died much quicker at the border. It went something like: native SNA or > native routed DECnet IV on original vendor equipment -> multi-protocol > routers -> tunnelled SNA or DECnet IV -> islands with gateways -> > islands -> switch off. I think IPv4 will get to the islands with gateways much faster than = DECNET or SNA. I think that the IPX (and/or Appletalk) transition(s) to IP are = a much more informative model. SNA, especially, was a very different networking model from IP and IBM (as well as HDS and other IBM clones) were very very slow to support TCP/IP other than through gateways. They still depended on SNA for the vast majority of their peripherals, terminals, etc. It wasn't until = most 3270/5250 terminals were replaced by PCs that the real move away from SNA started in earnest. At that point, SNA mostly disappeared = fairly quickly. Much less than 20 years. IPX and Appletalk, OTOH, provided very similar overall services on a = very similar conceptual model to IP. As a result, that transition was quite a = bit easier and the enterprise migration consequently happened quite rapidly. I'm sure you can still point to islands of IPX or Appletalk running here = and there in a few enterprises, but what was once the flagship product of a major player in the industry (IPX / Novelle) is now basically relegated to history and the company is an also-ran at best. > The final straw was making end users pay pro-rata for the support = costs > of the shrinking infra. IMVHO Whilst there's still economies of scale, > there's simply no business case *inside* the enterprise except for > opportunistic switch on at standard scheduled lifecycle renewal. I've > been through this loop myself. But then again, why should the IETF = care > what happens in that case if the border interface is clean and IPv6 = only? The IETF probably shouldn't really care. However, this is an = informational RFC intended to help enterprises get from A to B in an orderly manner. = As such, I think it is appropriate to document that process. Further, I think you will see the escalating cost of IPv4 at the eyeball = ISP as the first driving factor for deprecating IPv4 and I think that will = happen quite a bit faster than most people expect. As a general rule, once CGN starts to be widely deployed and ISPs start having to charge extra to cover the escalating costs of CGN (especially WRT the CALEA implications), you'll see consumers choosing IPv6 only over paying extra for even more degraded IPv4 service. Owen From fred@cisco.com Thu Aug 8 12:02: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 A2B5221F9928 for ; Thu, 8 Aug 2013 12:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.799 X-Spam-Level: X-Spam-Status: No, score=-110.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 NxXIM+5WFxDw for ; Thu, 8 Aug 2013 12:02:27 -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 221BD21F9D04 for ; Thu, 8 Aug 2013 12:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=605; q=dns/txt; s=iport; t=1375988530; x=1377198130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=noecZ6vBktaALLwMisyGHp6o2wKj/04tp6hIBnaEREM=; b=D2ksVWZKGnHPmjCNf3hD/IK6ayTl6waK5SBxMdkhiE+lteK2D6Ig/yvs cZ86BCHowVGK96S2g3QmsZ5eF1SqBv0Yi9XD2nbA2LknDyriKMsL0jGTa 6hjMbTBrdZfvZkwAQAJgHbZ+5tHHd04zCYRZD26zSXpzjTgxf1pi9/Dmd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FANTpA1KtJV2d/2dsb2JhbABbgwY1UIJNu36BGhZ0giQBAQEDATo/BQsCAQgOFBQQMiUCBA4FCIgCBgy4dY9oAjEHgxp0A5kLkCWBX4E5gio X-IronPort-AV: E=Sophos;i="4.89,840,1367971200"; d="scan'208";a="245272532" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 08 Aug 2013 19:02:09 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r78J29So015311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 19:02:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 14:02:09 -0500 From: "Fred Baker (fred)" To: Ray Hunter Thread-Topic: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] Thread-Index: AQHOlGnHgZzdktrmVk21qxmqmvPlwg== Date: Thu, 8 Aug 2013 19:02:08 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B97A0E3@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> In-Reply-To: <5203C7E5.3060106@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.137] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:02:32 -0000 On Aug 8, 2013, at 9:31 AM, Ray Hunter wrote: > Why would anyone in their right mind chose to deploy NAT64/DNS64 in a com= mercial environment given the prices I've seen for that functionality? The place I generally see it called out is between an IPv6-only (portion of= a) network and an IPv4-only (portion of a) network. This may be interestin= g reading - and in a few weeks I'll be seeking opinions on it. http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience "NAT64 Operational Experiences", Gang Chen, Zhen Cao, Chongfeng Xie, David Binet, 2013-07-08 From v6ops@globis.net Thu Aug 8 13:41:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A0921F8F4F for ; Thu, 8 Aug 2013 13:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw1ODqrJCssV for ; Thu, 8 Aug 2013 13:41:21 -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 4622511E8229 for ; Thu, 8 Aug 2013 13:41:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C51CC8700E7; Thu, 8 Aug 2013 22:40:54 +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 e9NcpdtI1rWF; Thu, 8 Aug 2013 22:40:54 +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 97DE28700E1; Thu, 8 Aug 2013 22:40:54 +0200 (CEST) Message-ID: <5204024F.8080703@globis.net> Date: Thu, 08 Aug 2013 22:40:47 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Owen DeLong References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> In-Reply-To: <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:41:22 -0000 > Owen DeLong > 8 August 2013 19:54 > On Aug 8, 2013, at 10:28 AM, Ray Hunter wrote: > >>> Gert Doering >>> 8 August 2013 19:05 >>> Hi, >>> >>> To get rid of dual-stack operations, while still being able to benefit >>> from the large address space of IPv6 inside the enterprise? >> Who has an IPv4 address shortage *inside* the enterprise? >> And what are these benefits *inside* the enterprise? >> LAN switches are written off over at least 10 years in the book keeping. > > Arguably, anyone using RFC-1918 space is suffering from an address > shortage inside their enterprise. Given the clear and obvious benefits > of eliminating NAT and having globally unique addresses for every > system which communicates with the internet, I wonder how you can > ask such a question with a straight face. But that pain has been solved 5 years ago in most places I work. There's no burning platform. How would introducing a new technology like NAT64/DNS64 make things better in places where it hasn't been solved? [the original point of the thread] it's yet another NAT box. > > A 10 year depreciation on switches is absurd. Most enterprises I know of > use either a 3-year or 5-year depreciation schedule for network equipment > such as LAN switches and many end up retiring them faster than they > depreciate. > >> AFAICS the only thing most large enterprises are worried about right now >> is the border, and Internet and outward facing systems (and rightly so). >> They'll be able to run *private* IPv4 networks over MPLS or GRE or >> something else for many many years to come, with all of their important >> partners, and there'll be plenty of vendors wiling to support them on >> old kit at cut prices. > > I think you are right about what most enterprises are worried about right > now (if they are even paying attention at all). However, enterprises are > not exactly known for paying attention to anything more than 3 months > away from now, so I don't think that's a great yardstick. > > It will be interesting to see how this plays out. I think that the cost of > continuing to support IPv4 in the face of an ever-increasing proportion > of the internet not being IPv4 capable will lead enterprises to abandon > IPv4 for the most part much faster than is currently anticipated. > > We saw this with the IPX->IP transition. Everyone thought we'd be > running IPX everywhere for 20-30 years, yet once IP gained critical > mass in the enterprise, IPX all but disappeared in less than 5 years. > >> If SNA or DECnet IV is any transition model to go by, it took about 20 >> years for them to die inside most enterprises, whilst they generally >> died much quicker at the border. It went something like: native SNA or >> native routed DECnet IV on original vendor equipment -> multi-protocol >> routers -> tunnelled SNA or DECnet IV -> islands with gateways -> >> islands -> switch off. > > I think IPv4 will get to the islands with gateways much faster than DECNET > or SNA. I think that the IPX (and/or Appletalk) transition(s) to IP are a much > more informative model. > > SNA, especially, was a very different networking model from IP and IBM > (as well as HDS and other IBM clones) were very very slow to support > TCP/IP other than through gateways. They still depended on SNA for > the vast majority of their peripherals, terminals, etc. It wasn't until most > 3270/5250 terminals were replaced by PCs that the real move away > from SNA started in earnest. At that point, SNA mostly disappeared fairly > quickly. Much less than 20 years. > > IPX and Appletalk, OTOH, provided very similar overall services on a very > similar conceptual model to IP. As a result, that transition was quite a bit > easier and the enterprise migration consequently happened quite rapidly. > > I'm sure you can still point to islands of IPX or Appletalk running here and > there in a few enterprises, but what was once the flagship product of a > major player in the industry (IPX / Novelle) is now basically relegated > to history and the company is an also-ran at best. > >> The final straw was making end users pay pro-rata for the support costs >> of the shrinking infra. IMVHO Whilst there's still economies of scale, >> there's simply no business case *inside* the enterprise except for >> opportunistic switch on at standard scheduled lifecycle renewal. I've >> been through this loop myself. But then again, why should the IETF care >> what happens in that case if the border interface is clean and IPv6 only? > > The IETF probably shouldn't really care. However, this is an informational > RFC intended to help enterprises get from A to B in an orderly manner. As > such, I think it is appropriate to document that process. > > Further, I think you will see the escalating cost of IPv4 at the eyeball ISP as > the first driving factor for deprecating IPv4 and I think that will happen quite > a bit faster than most people expect. > > As a general rule, once CGN starts to be widely deployed and ISPs start > having to charge extra to cover the escalating costs of CGN (especially > WRT the CALEA implications), you'll see consumers choosing IPv6 only > over paying extra for even more degraded IPv4 service. > > Owen > > Actually I think your reasoning and reference to the IPX and Appletalk phase out would suggest it's easier to make a bold call: move to IPv6 ASAP for critical systems via dual stack, and for the rest you draw a box around it and call it legacy and run it on IPv4 until it dies a natural death. IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks you into a transition technology that is expensive and difficult to operate for the life cycle of that box, and which has to remain in place until the last app is migrated or switched off. I've been in a fair number projects where you sometimes just have to dare to cut the cord whilst maintaining a process to find out what has broken. So one valid IPv6 only migration strategy might be: "If it's important, they'll migrate before a flag day date. Otherwise they get cut off." -- Regards, RayH From brian.e.carpenter@gmail.com Thu Aug 8 14:00: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 9910C11E8231 for ; Thu, 8 Aug 2013 14:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HruRJMIv+6Lv for ; Thu, 8 Aug 2013 14:00:42 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2616211E822C for ; Thu, 8 Aug 2013 14:00:42 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so3872400pbb.33 for ; Thu, 08 Aug 2013 14:00: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=HJ+lsQteNGuHsJUXjbk5sXIq0AZjRvX9rJrPqRig3eA=; b=A+7HVgqeKbfTeVkSo03B2AztGpp6Nv1gQR1g9K90RnnA2b99lm6fqAlQGX/oDoa4lA 90VoDlAFrhXOFXMrpcLZkHDzhGK6hnale6VEb0kYAuca6dvI9nnIdEClHEb3uR+3tYvC CMcu3AaId/pj7vNxxDoLYOtOwfVzUNysymU4JvogxBaC6nw/2PksgiHzKMJOuSFIF3/b qfprm/IFOWmkvDyVAuezgPal1kZyeEwQI5ackcP2CUsZsNAGTOmbdDmWzanZlzWuV5I/ 2olCsmG2e1ozir9PXUjK14GfCBwbCLNSeDiv2P86h1WYuKi9KTBoUWxy3Wq0+VmXPo+z K9Aw== X-Received: by 10.66.221.8 with SMTP id qa8mr7884656pac.188.1375995641842; Thu, 08 Aug 2013 14:00:41 -0700 (PDT) Received: from [192.168.178.20] (110.200.69.111.dynamic.snap.net.nz. [111.69.200.110]) by mx.google.com with ESMTPSA id yg1sm16103280pbb.1.2013.08.08.14.00.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 14:00:41 -0700 (PDT) Message-ID: <52040700.2010908@gmail.com> Date: Fri, 09 Aug 2013 09:00:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <8C48B86A895913448548E6D15DA7553B97A0E3@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B97A0E3@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "" Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:00:42 -0000 On 09/08/2013 07:02, Fred Baker (fred) wrote: > On Aug 8, 2013, at 9:31 AM, Ray Hunter wrote: > >> Why would anyone in their right mind chose to deploy NAT64/DNS64 in a commercial environment given the prices I've seen for that functionality? > > The place I generally see it called out is between an IPv6-only (portion of a) network and an IPv4-only (portion of a) network. This may be interesting reading - and in a few weeks I'll be seeking opinions on it. > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience > "NAT64 Operational Experiences", Gang Chen, Zhen Cao, Chongfeng Xie, > David Binet, 2013-07-08 And what I find lacking in the enterprise-incremental-ipv6 draft is a sentence or two pointing out that there are practical issues and tradeoffs - the current text is a rather abstract explanation of the scenarios and standards, which is not generally enough for a enterprise network manager. This discussion has shown that it isn't a clear-cut matter, so some sort of practical guidance is needed. Brian From gert@space.net Thu Aug 8 14:13: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 76EFA11E822C for ; Thu, 8 Aug 2013 14:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP7N2cDpNjXY for ; Thu, 8 Aug 2013 14:13:53 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E202421F9DAF for ; Thu, 8 Aug 2013 14:13:52 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 20CB960A24 for ; Thu, 8 Aug 2013 23:13:47 +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 EAD3D60A1E for ; Thu, 8 Aug 2013 23:13:46 +0200 (CEST) Received: (qmail 81517 invoked by uid 1007); 8 Aug 2013 23:13:46 +0200 Date: Thu, 8 Aug 2013 23:13:46 +0200 From: Gert Doering To: Ray Hunter Message-ID: <20130808211346.GR65295@Space.Net> References: <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> <5204024F.8080703@globis.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="proJWJF/9RxP0DAH" Content-Disposition: inline In-Reply-To: <5204024F.8080703@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:13:53 -0000 --proJWJF/9RxP0DAH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 08, 2013 at 10:40:47PM +0200, Ray Hunter wrote: > IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks > you into a transition technology that is expensive and difficult to > operate for the life cycle of that box, and which has to remain in place > until the last app is migrated or switched off. Maybe you are using the term NAT64/DNS64 in a different way than Cameron and I do that. When I speak about NAT64, it means "go to IPv6-only on the inside, and only use NAT64 to talk to those outside hosts that have no IPv6". NAT64 is not a transition technology for your network, it's a transition technology for "talking to legacy peers". 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 --proJWJF/9RxP0DAH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQCVAwUBUgQKCqkuBuNlUUl1AQLUWAP/aBJAA0WOGUu9Lh5ciOTSehFfw2cYLQSN HRLY4IjxILu7VEjrpYL3OaPfNX4bylRuS2O9oSUM7mRgLyJEAgZN3DJwK2Xshtll g4r17s7M2gDWpUIX3SIqTbvtF5A3daFsi+LsiHstmgpmTTcUjP1Kb0KqSe2oevwC YDqM/SvhcRQ= =OiBW -----END PGP SIGNATURE----- --proJWJF/9RxP0DAH-- From tperrine@scea.com Thu Aug 8 14:43: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 6D57811E8236 for ; Thu, 8 Aug 2013 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCUUkSctf6aa for ; Thu, 8 Aug 2013 14:43:34 -0700 (PDT) Received: from ironport04a.scea.com (ironport04a.scea.com [160.33.44.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4786311E822E for ; Thu, 8 Aug 2013 14:43:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,841,1367996400"; d="scan'208";a="1648807" Received: from inbetweener02.scea.com ([160.33.45.196]) by ironport04a.scea.com with ESMTP; 08 Aug 2013 14:43:32 -0700 Received: from sd-tperrine-mpl.local (unknown [10.56.0.12]) by inbetweener02.scea.com (Postfix) with ESMTP id D79CFB8114 for ; Thu, 8 Aug 2013 14:43:32 -0700 (PDT) Message-ID: <52041104.9030701@scea.com> Date: Thu, 08 Aug 2013 14:43:32 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: v6ops@ietf.org References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> <5204024F.8080703@globis.net> In-Reply-To: <5204024F.8080703@globis.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:43:40 -0000 On 8/8/13 1:40 PM, Ray Hunter wrote: <<<<<<<>>>>>>>>> > Actually I think your reasoning and reference to the IPX and Appletalk > phase out would suggest it's easier to make a bold call: move to IPv6 > ASAP for critical systems via dual stack, and for the rest you draw a > box around it and call it legacy and run it on IPv4 until it dies a > natural death. > > IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks > you into a transition technology that is expensive and difficult to > operate for the life cycle of that box, and which has to remain in place > until the last app is migrated or switched off. > > I've been in a fair number projects where you sometimes just have to > dare to cut the cord whilst maintaining a process to find out what has > broken. So one valid IPv6 only migration strategy might be: "If it's > important, they'll migrate before a flag day date. Otherwise they get > cut off." I cannot agree enough with the "prolongs the pain" observation. I'm planning to have no transition technologies in our internal (corporate) network. "Dual-stack or death!" If something can't be dual-stacked, it goes into the legacy pit of doom and dies a slow painful death. Consumer-facing is different, but I'm still expecting no transition technologies to be needed. This is rather cold-blooded and (I freely admit) a bit of a pipe dream. But if I can make this work, I'll never have to justify, pay for, create, debug, support, and then decommission any of the transition technologies. From avayner@cisco.com Thu Aug 8 22:21:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB37821F9E6A for ; Thu, 8 Aug 2013 22:21:23 -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=[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 RvsFvNk9Hxc2 for ; Thu, 8 Aug 2013 22:21:18 -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 ECC4D21F9E3C for ; Thu, 8 Aug 2013 22:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19102; q=dns/txt; s=iport; t=1376025678; x=1377235278; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CLbMOSS/qvG/+l9vWTjMFX+in/O+w9thwXptwA0qoow=; b=DyVTox9wNx8K91SinqURyxMwzlka2WGtvwQCF65Fy7Vd4ToB/IpohTdL RGJQeWAdirJBdp/3NFx/n+lMuBYKRczc/uNBiLhWvC2Jm+4klDAcyBfbX lSrcMciOKeEF7BYAU4Y6ai9YjazT5p+eoLHw36YbBxUR9q4LyMJBJ5Fmj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAM57BFKtJXG//2dsb2JhbABbgkJENVC+UIEZFnSCJAEBAQMBLUwFCwIBCBEEAQEBCh0HMhQDAQUIAgQBDQUIE4dvBrkGj2oxBgGDGnQDiHOgPYMYgio X-IronPort-AV: E=Sophos;i="4.89,844,1367971200"; d="scan'208,217";a="245355484" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2013 05:21:12 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r795LCE7028777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 05:21:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 00:21:11 -0500 From: "Arie Vayner (avayner)" To: "Eric Vyncke (evyncke)" , Lorenzo Colitti , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkTyDDMSxdUYJukeaGavK35KXPJmGm1kAgACKQoCAAF43gIAAFCCAgAArgQCAAkwdAIACTLxQ Date: Fri, 9 Aug 2013 05:21:10 +0000 Message-ID: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.89.89] Content-Type: multipart/alternative; boundary="_000_CA6D42D0F8A41948AEB3864480C554F104AE7A3Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 05:21:24 -0000 --_000_CA6D42D0F8A41948AEB3864480C554F104AE7A3Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another loosely related point that I think could make sense in such a docum= ent would be the ways to accomplish multi-homing and how it is different th= an today's IPv4 implementations. Many enterprises rely on NAT on the Internet edge as their multi-homing/tra= ffic engineering mechanism with IPv4. If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), = then we need to highlight the symmetry requirement due to stateful security= layers. Traffic leaving from an Internet gateway site to the Internet has to come b= ack through the same site, or the stateful firewalls would break the flow (= well, has to hit the same stateful security layer) Syncing upstream and downstream routing policies is not always an easy task= (but could be relevant in some cases). Linking the Internet gateway layer across sites (before hitting the statefu= l security layer) could be another solution. Do you think a short discussion to raise awareness for this potential issue= could be relevant in such a document? Arie From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of E= ric Vyncke (evyncke) Sent: Wednesday, August 7, 2013 6:08 AM To: Lorenzo Colitti; Fred Baker (fred) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC In short, the debate is not so much about ULA per se (we all know that ther= e are obvious cases - even if rare - where ULA is the obvious choice) but a= bout NPTv6 ;-O What a surprise... I dislike NAT (especially the n:1 stateful one) even more when it is assume= d to add security (cough cough). But, during my day job I talk to enterprise customers (from small SMB with = 3 people - friends and acquaintance - to 1000 people) and to be honest ULA = (and I am ashamed to add NPT6 to the mix) is really what they want and I ca= n understand why: - Having the internal network up when DHCP-PD is failing because WAN = link is down (at least they keep ULA and loose only their GUA), this should= be mentioned in our I-D - Having a simple and cheap way to do multi-homing, search about mult= i-homing, load-balancing, ... for SMB and those boxes uses RFC 1918 inside = + NAT towards two ISP or two links (xDSL & 4G)... Not all SMB will get a PI= space and will run BGP. In short, I am probably the only co-author, that do not want to hide the to= pic under the carpet of another I-D. We could mention the above points (and= others) without taking decisions but referring to the ULA use case I-D. Bu= t, we should mention that there are use case where ULA _APPEARS_ as appeali= ng. -=E9ric (and YES I dislike NAPT for breaking apps, and making security wors= e) From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: mardi 6 ao=FBt 2013 04:03 To: Fred Baker (fred) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC On Tue, Aug 6, 2013 at 8:27 AM, Fred Baker (fred) > wrote: > NAT creates problems for applications not only in the stateful case, but = in the stateless case as well, because with NAT the client must be prepared= for a situation where it does not know its own address. This complicates p= eer-to-peer networking applications such as video chat. I'm not going to argue one way or the other. The substance of my comment re= lated to an address that was not intended to be globally reachable. our tho= ught there? But if it's not indended to be globally reachable... then why is it behind = a NPTv6 box? I'd argue is that it *does* need to be globally reachable, but= "only for certain traffic". For example, "TCP/443 replies from the Windows= Update server". The point is that when people say, "X will never do Y" sometimes it turns o= ut that "never" just means "in the next six months", and what ends up happe= ning is that they need to deal with additional complexity once Y becomes a = requirement. --_000_CA6D42D0F8A41948AEB3864480C554F104AE7A3Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Another loosely related p= oint that I think could make sense in such a document would be the ways to = accomplish multi-homing and how it is different than today’s IPv4 implementations.

 <= /p>

Many enterprises rely on = NAT on the Internet edge as their multi-homing/traffic engineering mechanis= m with IPv4.

 <= /p>

If we recommend against U= LA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highl= ight the symmetry requirement due to stateful security layers.

Traffic leaving from an I= nternet gateway site to the Internet has to come back through the same site= , or the stateful firewalls would break the flow (well, has to hit the same stateful security layer)

 <= /p>

Syncing upstream and down= stream routing policies is not always an easy task (but could be relevant i= n some cases).

Linking the Internet gate= way layer across sites (before hitting the stateful security layer) could b= e another solution.

 <= /p>

Do you think a short disc= ussion to raise awareness for this potential issue could be relevant in suc= h a document?

 <= /p>

Arie

 <= /p>

From: v6ops-= bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: Wednesday, August 7, 2013 6:08 AM
To: Lorenzo Colitti; Fred Baker (fred)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WG= LC

 

In short, the debate is not= so much about ULA per se (we all know that there are obvious cases –= even if rare – where ULA is the obvious choice) but about NPTv6 ;-O What a surprise...

 

I dislike NAT (especially t= he n:1 stateful one) even more when it is assumed to add security (cough co= ugh).

 

But, during my day job I ta= lk to enterprise customers (from small SMB with 3 people – friends an= d acquaintance – to 1000 people) and to be honest ULA (and I am ashamed to add NPT6 to the mix) is really what they want and I can underst= and why:

-    &nb= sp;  Having the internal network up when DHCP-PD is failing because WAN li= nk is down (at least they keep ULA and loose only their GUA), this should be mentioned in our I-D

-    &nb= sp;  Having a simple and cheap way to do multi-homing, search about multi-= homing, load-balancing, ... for SMB and those boxes uses RFC 1918 inside + NAT towards two ISP or two links (xDSL & 4G)... = Not all SMB will get a PI space and will run BGP.<= o:p>

 

In short, I am probably the= only co-author, that do not want to hide the topic under the carpet of ano= ther I-D. We could mention the above points (and others) without taking decisions but referring to the ULA use case I-D. But, we sh= ould mention that there are use case where ULA _APPEARS_ as appealin= g.

 

-=E9ric (and YES I dislike = NAPT for breaking apps, and making security worse)=

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: mardi 6 ao=FBt 2013 04:03
To: Fred Baker (fred)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WG= LC

 

On Tue, Aug 6, 2013 at 8:27 AM, Fr= ed Baker (fred) <fre= d@cisco.com> wrote:

>= ; NAT creates problems for applications not only in the stateful case, but = in the stateless case as well, because with NAT the client must be prepared= for a situation where it does not know its own address. This complicates peer-to-peer networking applications such as= video chat.

I'm not going to argue one way or = the other. The substance of my comment related to an address that was not i= ntended to be globally reachable. our thought there?

 

But if it's not indended to be glo= bally reachable... then why is it behind a NPTv6 box? I'd argue is that it = *does* need to be globally reachable, but "only for certain traffic&qu= ot;. For example, "TCP/443 replies from the Windows Update server".

 

The point is that when people say,= "X will never do Y" sometimes it turns out that "never"= ; just means "in the next six months", and what ends up happening= is that they need to deal with additional complexity once Y becomes a requirement.

--_000_CA6D42D0F8A41948AEB3864480C554F104AE7A3Fxmbrcdx10ciscoc_-- From v6ops@globis.net Fri Aug 9 00:00: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 07C6921F859A for ; Fri, 9 Aug 2013 00:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ1gU1uN2qhQ for ; Thu, 8 Aug 2013 23:59:59 -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 559E521F866E for ; Thu, 8 Aug 2013 23:59:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 274318700EA; Fri, 9 Aug 2013 08:59:43 +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 Br21UET7x7Is; Fri, 9 Aug 2013 08:59:43 +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 F3C008700E1; Fri, 9 Aug 2013 08:59:42 +0200 (CEST) Message-ID: <52049358.9050608@globis.net> Date: Fri, 09 Aug 2013 08:59:36 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Gert Doering References: <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> <5204024F.8080703@globis.net> <20130808211346.GR65295@Space.Net> In-Reply-To: <20130808211346.GR65295@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 07:00:01 -0000 > Gert Doering > 8 August 2013 23:13 > Hi, > > Maybe you are using the term NAT64/DNS64 in a different way than Cameron > and I do that. When I speak about NAT64, it means "go to IPv6-only on > the inside, and only use NAT64 to talk to those outside hosts that have > no IPv6". > > NAT64 is not a transition technology for your network, it's a transition > technology for "talking to legacy peers". Right. But I still don't see a scenario for a hosting location of "legacy peers" where large scale NAT64/DNS64 makes sense compared to any number of alternatives that are already well-known within the enterprise space. If the legacy apps are located within the enterprise relative to their users, there's really no visible cost to running dual stack today or in the foreseeable future. Show me an enterprise carrier or managed service provider or router vendor who charges more for their MPLS solution or managed service or device for IPv4 support. I can show you plenty where IPv6 is a "premium service." Until IPv4 becomes a "premium service" there's simply no business case. That transition has happened on the public Internet: public IPv4 is starting to cost more on the public Internet, and it's visible to consumers. If the legacy apps are located on the Internet, there are already any number of border solutions in place: proxies, gateways, VPN's, and stepping stones that can be adapted to perform the translation at a higher layer, or to tunnel the IPv4 traffic over IPv6, without resorting to DNS64/NAT64. Bearing in mind that most enterprises anyway run split DNS, and resolving Internet addresses by end hosts located within the border is the exception rather than the norm (although that is changing), If the legacy apps are located on trusted 3rd party sites, or hosted provider sites (private-cloud) then IPv4 issues can be solved commercially to ensure native IPv4 support is available for a fixed support period, or by introducing IPv4 over IPv6 tunnels or private links. I agree entirely that the border needs to adapt, and quickly, because that's where the business risks are. I also get why ISP's like DNS64/NAT64 in an "eyeballs network." As to the point of going pure IPv6 only on the inside: that also introduces a new merger and acquisition risk. If your take over target has gone pure IPv6 only, and you are still running dual stack, or vice versa, that's IMHO tougher to transition than if you are both still running dual stack. I wouldn't want to be the guy who had to go to my boss and say "we need to turn IPv4 back on and it's going to cost us X" after having spent a fortune on going IPv6 only. Specifically looking at the draft text. "the long term enterprise network roadmap should include steps on gradually deprecating IPv4 from the dual-stack network" Why gradually? As Owen points out, IPX and appletalk phase out was disruptive and fast. Depending on the enterprise's strategic plan, a flag day approach to turning off IPv4 is equally valid IMHO. Never mind the technical aspects, a cut off date concentrates people's minds. Equally, given the history of the SNA, DECnet phase out, a strategy of declaring certain systems "legacy" and running them as-is using native protocols on the long-term until they reach a natural end of life would also seem a valid strategy . A network might never reach pure IPv6 only, and that IMHO would not be a problem. "However, in the current environment, given that IPv4 is the dominant protocol on the Internet, an IPv6-only node most likely needs to talk to an IPv4-only node on the Internet." I question this statement. There are plenty of enterprises that do not allow any direct IP level session from an end node within the enterprise to a server located on the public Internet. The adaptation can then take place in a border system e.g. proxy or ALG, and both end-user devices see their own native protocols. "It is therefore important to provide such nodes with a translation mechanism to ensure communication between nodes configured with different address families." Why? That's just one of many options. Proxies and ALGs are well-known practice in the enterprise, they are already deployed and well-understood, and IMHO there's no need to deviate from that solution just to obtain IPv6 support on the outside interface of the border unless there are other benefits. So just adding IPv6 to the outside interface of these services is a perfectly valid long-term solution IMHO. That also means you have less touch-points in your migration plan. I also have a customer who has specifically stated "there shall be no address family translation within the network transport service" and "we shall transport native protocols only end-to-end between end user systems" (tunnels are OK but they must terminate on network equipment, not end nodes). There are no magic boxes to make the pain go away. And they just don't want the complexity and costs in that layer. > > Gert Doering > -- NetMaster > Ray Hunter > 8 August 2013 22:40 >> Owen DeLong >> 8 August 2013 19:54 >> On Aug 8, 2013, at 10:28 AM, Ray Hunter wrote: >> >>>> Gert Doering >>>> 8 August 2013 19:05 >>>> Hi, >>>> >>>> To get rid of dual-stack operations, while still being able to benefit >>>> from the large address space of IPv6 inside the enterprise? >>> Who has an IPv4 address shortage *inside* the enterprise? >>> And what are these benefits *inside* the enterprise? >>> LAN switches are written off over at least 10 years in the book keeping. >> Arguably, anyone using RFC-1918 space is suffering from an address >> shortage inside their enterprise. Given the clear and obvious benefits >> of eliminating NAT and having globally unique addresses for every >> system which communicates with the internet, I wonder how you can >> ask such a question with a straight face. > But that pain has been solved 5 years ago in most places I work. There's > no burning platform. > > How would introducing a new technology like NAT64/DNS64 make things > better in places where it hasn't been solved? > [the original point of the thread] it's yet another NAT box. >> A 10 year depreciation on switches is absurd. Most enterprises I know of >> use either a 3-year or 5-year depreciation schedule for network equipment >> such as LAN switches and many end up retiring them faster than they >> depreciate. >> >>> AFAICS the only thing most large enterprises are worried about right now >>> is the border, and Internet and outward facing systems (and rightly so). >>> They'll be able to run *private* IPv4 networks over MPLS or GRE or >>> something else for many many years to come, with all of their important >>> partners, and there'll be plenty of vendors wiling to support them on >>> old kit at cut prices. >> I think you are right about what most enterprises are worried about right >> now (if they are even paying attention at all). However, enterprises are >> not exactly known for paying attention to anything more than 3 months >> away from now, so I don't think that's a great yardstick. >> >> It will be interesting to see how this plays out. I think that the cost of >> continuing to support IPv4 in the face of an ever-increasing proportion >> of the internet not being IPv4 capable will lead enterprises to abandon >> IPv4 for the most part much faster than is currently anticipated. >> >> We saw this with the IPX->IP transition. Everyone thought we'd be >> running IPX everywhere for 20-30 years, yet once IP gained critical >> mass in the enterprise, IPX all but disappeared in less than 5 years. >> >>> If SNA or DECnet IV is any transition model to go by, it took about 20 >>> years for them to die inside most enterprises, whilst they generally >>> died much quicker at the border. It went something like: native SNA or >>> native routed DECnet IV on original vendor equipment -> multi-protocol >>> routers -> tunnelled SNA or DECnet IV -> islands with gateways -> >>> islands -> switch off. >> I think IPv4 will get to the islands with gateways much faster than DECNET >> or SNA. I think that the IPX (and/or Appletalk) transition(s) to IP are a much >> more informative model. >> >> SNA, especially, was a very different networking model from IP and IBM >> (as well as HDS and other IBM clones) were very very slow to support >> TCP/IP other than through gateways. They still depended on SNA for >> the vast majority of their peripherals, terminals, etc. It wasn't until most >> 3270/5250 terminals were replaced by PCs that the real move away >> from SNA started in earnest. At that point, SNA mostly disappeared fairly >> quickly. Much less than 20 years. >> >> IPX and Appletalk, OTOH, provided very similar overall services on a very >> similar conceptual model to IP. As a result, that transition was quite a bit >> easier and the enterprise migration consequently happened quite rapidly. >> >> I'm sure you can still point to islands of IPX or Appletalk running here and >> there in a few enterprises, but what was once the flagship product of a >> major player in the industry (IPX / Novelle) is now basically relegated >> to history and the company is an also-ran at best. >> >>> The final straw was making end users pay pro-rata for the support costs >>> of the shrinking infra. IMVHO Whilst there's still economies of scale, >>> there's simply no business case *inside* the enterprise except for >>> opportunistic switch on at standard scheduled lifecycle renewal. I've >>> been through this loop myself. But then again, why should the IETF care >>> what happens in that case if the border interface is clean and IPv6 only? >> The IETF probably shouldn't really care. However, this is an informational >> RFC intended to help enterprises get from A to B in an orderly manner. As >> such, I think it is appropriate to document that process. >> >> Further, I think you will see the escalating cost of IPv4 at the eyeball ISP as >> the first driving factor for deprecating IPv4 and I think that will happen quite >> a bit faster than most people expect. >> >> As a general rule, once CGN starts to be widely deployed and ISPs start >> having to charge extra to cover the escalating costs of CGN (especially >> WRT the CALEA implications), you'll see consumers choosing IPv6 only >> over paying extra for even more degraded IPv4 service. >> >> Owen >> >> > Actually I think your reasoning and reference to the IPX and Appletalk > phase out would suggest it's easier to make a bold call: move to IPv6 > ASAP for critical systems via dual stack, and for the rest you draw a > box around it and call it legacy and run it on IPv4 until it dies a > natural death. > > IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks > you into a transition technology that is expensive and difficult to > operate for the life cycle of that box, and which has to remain in place > until the last app is migrated or switched off. > > I've been in a fair number projects where you sometimes just have to > dare to cut the cord whilst maintaining a process to find out what has > broken. So one valid IPv6 only migration strategy might be: "If it's > important, they'll migrate before a flag day date. Otherwise they get > cut off." > > -- Regards, RayH From gert@space.net Fri Aug 9 00:02:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B52011E8166 for ; Fri, 9 Aug 2013 00:02:47 -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 u2toogZNhMKb for ; Fri, 9 Aug 2013 00:02:47 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id DB10411E8133 for ; Fri, 9 Aug 2013 00:02:45 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5A10060A0F for ; Fri, 9 Aug 2013 09:02:44 +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 42B73607FD for ; Fri, 9 Aug 2013 09:02:44 +0200 (CEST) Received: (qmail 93953 invoked by uid 1007); 9 Aug 2013 09:02:44 +0200 Date: Fri, 9 Aug 2013 09:02:44 +0200 From: Gert Doering To: Ray Hunter Message-ID: <20130809070244.GV65295@Space.Net> References: <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> <5204024F.8080703@globis.net> <20130808211346.GR65295@Space.Net> <52049358.9050608@globis.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j4RN9nyOJty92gQL" Content-Disposition: inline In-Reply-To: <52049358.9050608@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 07:02:47 -0000 --j4RN9nyOJty92gQL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Aug 09, 2013 at 08:59:36AM +0200, Ray Hunter wrote: > Show me an enterprise carrier or managed service provider or router > vendor who charges more for their MPLS solution or managed service or > device for IPv4 support. I can show you plenty where IPv6 is a "premium > service." Until IPv4 becomes a "premium service" there's simply no > business case. Vendor costs are not the point. The point is that operationally (OPEX), a dual-stack network costs more than a single-stack network. Maybe you should just try this for a while, so you know what it feels to have to do every DNS change twice, maintain two sets of firewall rules, etc...? 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 --j4RN9nyOJty92gQL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQCVAwUBUgSUFKkuBuNlUUl1AQKQ4QP/S+G2iuJSj7G0fc5hSEzw9JzVz/9DGps0 xsXwyofm5qPEr1y7ZYrjq75CSj4cLN6sYxENHpBaa3ImQX6tHss/+4fEhZ/riSvS UMB03jpXgmmlcjTxtCS4X2Pyj8p92A3NekNmnqaNesMbRV8T73KTGjZeMse+tAbg u5VO+0FXM0I= =fKyk -----END PGP SIGNATURE----- --j4RN9nyOJty92gQL-- From v6ops@globis.net Fri Aug 9 00:46: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 D2DDD21F9EE9 for ; Fri, 9 Aug 2013 00:46:01 -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 c32SHO8yHc37 for ; Fri, 9 Aug 2013 00:46:01 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0C021F9DDC for ; Fri, 9 Aug 2013 00:45:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1BE2E8700DF; Fri, 9 Aug 2013 09:45:42 +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 yk3xx7rKK7mD; Fri, 9 Aug 2013 09:45:42 +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 D6F45870025; Fri, 9 Aug 2013 09:45:41 +0200 (CEST) Message-ID: <52049E1F.1080708@globis.net> Date: Fri, 09 Aug 2013 09:45:35 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Gert Doering References: <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> <5204024F.8080703@globis.net> <20130808211346.GR65295@Space.Net> <52049358.9050608@globis.net> <20130809070244.GV65295@Space.Net> In-Reply-To: <20130809070244.GV65295@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 07:46:02 -0000 > Gert Doering > 9 August 2013 09:02 > Hi, > > Vendor costs are not the point. The point is that operationally (OPEX), > a dual-stack network costs more than a single-stack network. > I hear you. But the OPEX seen by the key decision maker has not increased at all (taking into account "vendor" includes managed service provider) > Maybe you should just try this for a while, so you know what it feels > to have to do every DNS change twice, maintain two sets of firewall > rules, etc...? > At large enterprise level: someone else's problem. The outsourcing contract has not gone up in price (yet). And the service provider needs to improve their tooling to cope with this as part of normal operational efficiency. Use a complete life-cycle-cost business case to compare that operational delta of dual stack operation (2 or 3 operational FTE) to the cost of a green field roll out of all new kit for pure IPv6 (including converting legacy gear that's only going to run for a pre-determined period), plus associated transition project costs, and business downtime to get it all running, and you'll find it's just noise. Sorry to sound blunt, but that's pretty much current enterprise thinking in my experience. > Gert Doering > -- NetMaster -- Regards, RayH From owen@delong.com Fri Aug 9 12:23:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9511E81BD for ; Fri, 9 Aug 2013 12:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDSe5OEPWvz0 for ; Fri, 9 Aug 2013 12:23:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4571621F9D2C for ; Fri, 9 Aug 2013 12:16: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 r79JBHjc019115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 12:11:17 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r79JBHjc019115 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376075479; bh=5IDreec5ttNCw7KGsVj96C/0+a0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=g0xfeJmDkz1fJCryV5y42M1wlurJ84OuS0X+8KGc3FLZL8gs3r6OMr5ko0fRObP24 gBLf5g6V4g+hVgwDrCk57L/xcEvH8K25zbsohs2Aw4PKhgPeCuL4gUAyPtOX1gfOIr yWWIBY8VMctPXBLW26UDSQL2WlQulqEl76NQ6GJo= 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: <5204024F.8080703@globis.net> Date: Fri, 9 Aug 2013 12:11:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> <5204024F.8080703@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 09 Aug 2013 12:11:19 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:23:02 -0000 On Aug 8, 2013, at 13:40 , Ray Hunter wrote: >> Owen DeLong >> 8 August 2013 19:54 >> On Aug 8, 2013, at 10:28 AM, Ray Hunter wrote: >>=20 >>>> Gert Doering >>>> 8 August 2013 19:05 >>>> Hi, >>>>=20 >>>> To get rid of dual-stack operations, while still being able to = benefit >>>> from the large address space of IPv6 inside the enterprise? >>> Who has an IPv4 address shortage *inside* the enterprise? >>> And what are these benefits *inside* the enterprise? >>> LAN switches are written off over at least 10 years in the book = keeping. >>=20 >> Arguably, anyone using RFC-1918 space is suffering from an address >> shortage inside their enterprise. Given the clear and obvious = benefits >> of eliminating NAT and having globally unique addresses for every >> system which communicates with the internet, I wonder how you can >> ask such a question with a straight face. > But that pain has been solved 5 years ago in most places I work. = There's > no burning platform. >=20 > How would introducing a new technology like NAT64/DNS64 make things > better in places where it hasn't been solved? > [the original point of the thread] it's yet another NAT box. The pain hasn't been solved, we've decided to live with it. However, that aside, I'm not arguing for NAT64/DNS64. I'm saying that eliminating NAT is obviously beneficial. NAT64 is jut another broken = form of NAT. NAT is inherently problematic and breaks things. It causes pain. Yes, I'm familiar with your argument of "if it doesn't work through NAT, = then I don't want it to work." I suppose that's one way to view the world, = but I would argue it's akin to insisting that your vehicle run on fossil = fuels, even if there were a viable truly cleaner sustainable alternative. NAT is a form of toxic pollutant on the internet, whether the polluters = see that or not. >>=20 >> A 10 year depreciation on switches is absurd. Most enterprises I know = of >> use either a 3-year or 5-year depreciation schedule for network = equipment >> such as LAN switches and many end up retiring them faster than they >> depreciate. >>=20 >>> AFAICS the only thing most large enterprises are worried about right = now >>> is the border, and Internet and outward facing systems (and rightly = so). >>> They'll be able to run *private* IPv4 networks over MPLS or GRE or >>> something else for many many years to come, with all of their = important >>> partners, and there'll be plenty of vendors wiling to support them = on >>> old kit at cut prices. >>=20 >> I think you are right about what most enterprises are worried about = right >> now (if they are even paying attention at all). However, enterprises = are >> not exactly known for paying attention to anything more than 3 months >> away from now, so I don't think that's a great yardstick. >>=20 >> It will be interesting to see how this plays out. I think that the = cost of >> continuing to support IPv4 in the face of an ever-increasing = proportion >> of the internet not being IPv4 capable will lead enterprises to = abandon >> IPv4 for the most part much faster than is currently anticipated. >>=20 >> We saw this with the IPX->IP transition. Everyone thought we'd be >> running IPX everywhere for 20-30 years, yet once IP gained critical >> mass in the enterprise, IPX all but disappeared in less than 5 years. >>=20 >>> If SNA or DECnet IV is any transition model to go by, it took about = 20 >>> years for them to die inside most enterprises, whilst they generally >>> died much quicker at the border. It went something like: native SNA = or >>> native routed DECnet IV on original vendor equipment -> = multi-protocol >>> routers -> tunnelled SNA or DECnet IV -> islands with gateways -> >>> islands -> switch off. >>=20 >> I think IPv4 will get to the islands with gateways much faster than = DECNET >> or SNA. I think that the IPX (and/or Appletalk) transition(s) to IP = are a much >> more informative model. >>=20 >> SNA, especially, was a very different networking model from IP and = IBM >> (as well as HDS and other IBM clones) were very very slow to support >> TCP/IP other than through gateways. They still depended on SNA for >> the vast majority of their peripherals, terminals, etc. It wasn't = until most >> 3270/5250 terminals were replaced by PCs that the real move away >> from SNA started in earnest. At that point, SNA mostly disappeared = fairly >> quickly. Much less than 20 years. >>=20 >> IPX and Appletalk, OTOH, provided very similar overall services on a = very >> similar conceptual model to IP. As a result, that transition was = quite a bit >> easier and the enterprise migration consequently happened quite = rapidly. >>=20 >> I'm sure you can still point to islands of IPX or Appletalk running = here and >> there in a few enterprises, but what was once the flagship product of = a >> major player in the industry (IPX / Novelle) is now basically = relegated >> to history and the company is an also-ran at best. >>=20 >>> The final straw was making end users pay pro-rata for the support = costs >>> of the shrinking infra. IMVHO Whilst there's still economies of = scale, >>> there's simply no business case *inside* the enterprise except for >>> opportunistic switch on at standard scheduled lifecycle renewal. = I've >>> been through this loop myself. But then again, why should the IETF = care >>> what happens in that case if the border interface is clean and IPv6 = only? >>=20 >> The IETF probably shouldn't really care. However, this is an = informational >> RFC intended to help enterprises get from A to B in an orderly = manner. As >> such, I think it is appropriate to document that process. >>=20 >> Further, I think you will see the escalating cost of IPv4 at the = eyeball ISP as >> the first driving factor for deprecating IPv4 and I think that will = happen quite >> a bit faster than most people expect. >>=20 >> As a general rule, once CGN starts to be widely deployed and ISPs = start >> having to charge extra to cover the escalating costs of CGN = (especially >> WRT the CALEA implications), you'll see consumers choosing IPv6 only >> over paying extra for even more degraded IPv4 service. >>=20 >> Owen >>=20 >>=20 > Actually I think your reasoning and reference to the IPX and Appletalk > phase out would suggest it's easier to make a bold call: move to IPv6 > ASAP for critical systems via dual stack, and for the rest you draw a > box around it and call it legacy and run it on IPv4 until it dies a > natural death. That's certainly one approach. In my experience, that's not what = happened with most enterprises. Most enterprises ran both IPX and IP clients on = their workstations for a few years until they could kill off all the servers = that were inside those "legacy" boxes you drew. > IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks > you into a transition technology that is expensive and difficult to > operate for the life cycle of that box, and which has to remain in = place > until the last app is migrated or switched off. Nothing I said was intended to support or encourage NAT64. It's simply awful. It might be a better alternative than CGN or certain other things in SOME very limited circumstances, but NAT64 is usually just a worse form of NAT than traditional NAT. > I've been in a fair number projects where you sometimes just have to > dare to cut the cord whilst maintaining a process to find out what has > broken. So one valid IPv6 only migration strategy might be: "If it's > important, they'll migrate before a flag day date. Otherwise they get > cut off." It might be, but it's one that most IT managers will be very uneasy = about implementing (at least in my experience). Owen From owen@delong.com Fri Aug 9 12:27: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 8377D11E817C for ; Fri, 9 Aug 2013 12:27: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=[AWL=-0.001, 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 RxKHgfnAyuJe for ; Fri, 9 Aug 2013 12:27:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FC11E8175 for ; Fri, 9 Aug 2013 12:21:35 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r79JHLdg019217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 12:17:21 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r79JHLdg019217 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376075841; bh=PHNtEaFFh40X/jlD1JpSKfEyqdE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=3iZtIK2LZlqhuDoyuyTxMSb0LHoXrfgMtGxOYXlUyxdrson3RBb6PViYD8DtRzXDj WO93V86mMqEIlxfNTSpsmKdcp//GHANl/+EVMm3+swXWuM9CYkxPZ5VDGz21tjrklc MNQbW7x/AmLQd8PLP62PzUDdmqyuqJYVutmhChSk= Content-Type: multipart/alternative; boundary="Apple-Mail=_B99E2586-CD61-405F-8596-0ED2DF59D622" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: Date: Fri, 9 Aug 2013 12:17:23 -0700 Message-Id: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> To: Arie Vayner (avayner) 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, 09 Aug 2013 12:17:21 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:27:55 -0000 --Apple-Mail=_B99E2586-CD61-405F-8596-0ED2DF59D622 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) = wrote: > Another loosely related point that I think could make sense in such a = document would be the ways to accomplish multi-homing and how it is = different than today=92s IPv4 implementations. > =20 > Many enterprises rely on NAT on the Internet edge as their = multi-homing/traffic engineering mechanism with IPv4. > =20 > If we recommend against ULA+NPTv6 (or just NPTv6 for traffic = engineering), then we need to highlight the symmetry requirement due to = stateful security layers. > Traffic leaving from an Internet gateway site to the Internet has to = come back through the same site, or the stateful firewalls would break = the flow (well, has to hit the same stateful security layer) Or stateful firewalls have to get better about sharing state. There are = two things that can help with this... 1. Put your firewalls as close to the end systems they protect as = possible. Make your security zones relatively small and place the = firewalls closer together at those narrower borders. This will often require more firewall units, but it helps in a = number of ways: A. Firewall policy tends to be much simpler (and as a = result less error prone and more reliable) B. The hardware demands on the firewall tend to be lower so = you can buy cheaper units. C. The simpler rulesets can be more easily tailored to meet = business requirements as they evolve. 2. Improve firewalls. Give the firewalls that all protect the same = boundary a way to mesh-peer with each other and exchange information = about the state tables such that triangle routing is no longer = problematic. > Syncing upstream and downstream routing policies is not always an easy = task (but could be relevant in some cases). > Linking the Internet gateway layer across sites (before hitting the = stateful security layer) could be another solution. If we make the changes above to the firewalls, this could be a lot less = relevant in most cases. > Do you think a short discussion to raise awareness for this potential = issue could be relevant in such a document? It's certainly worth documenting. I'm not sure whether it belongs in = this document or not. Owen --Apple-Mail=_B99E2586-CD61-405F-8596-0ED2DF59D622 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 avayner@cisco.com> = wrote:

Another loosely related = point that I think could make sense in such a document would be the ways = to accomplish multi-homing and how it is different than today=92s IPv4 = implementations.
 
Many enterprises rely on NAT on the Internet = edge as their multi-homing/traffic engineering mechanism with = IPv4.
 
If we recommend against ULA+NPTv6 (or just = NPTv6 for traffic engineering), then we need to highlight the symmetry = requirement due to stateful security layers.
Traffic leaving from an = Internet gateway site to the Internet has to come back through the same = site, or the stateful firewalls would break the flow (well, has to hit = the same stateful security = layer)

Or stateful = firewalls have to get better about sharing state. There are two things = that can help with this...

1. Put your = firewalls as close to the end systems they protect as possible. Make = your security zones relatively small and place the firewalls closer = together at those narrower borders.
This will = often require more firewall units, but it helps in a number of = ways:
= A. = Firewall policy tends to be much simpler (and as a result less = error prone and more reliable)
B. The hardware demands on the = firewall tend to be lower so you can buy cheaper units.
C. The = simpler rulesets can be more easily tailored to meet business = requirements as they evolve.

2. Improve = firewalls. Give the firewalls that all protect the same boundary a way = to mesh-peer with each other and exchange information about the state = tables such that triangle routing is no longer = problematic.

Syncing upstream and downstream routing policies is = not always an easy task (but could be relevant in some = cases).
Do you think a short discussion to raise awareness = for this potential issue could be relevant in such a = document?

It's = certainly worth documenting. I'm not sure whether it belongs in this = document or = not.

Owen


= --Apple-Mail=_B99E2586-CD61-405F-8596-0ED2DF59D622-- From fred@cisco.com Sun Aug 11 11:05: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 75CEB21F9B57 for ; Sun, 11 Aug 2013 11:05:59 -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 odGNms0Kk4HT for ; Sun, 11 Aug 2013 11:05:53 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9D421F9AC4 for ; Sun, 11 Aug 2013 11:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1376244006; x=1377453606; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=NQmnSkayLco5uu3I48CIzj9ss/UNSJPwMps+qiV3SXclMLEVqT/+fWLE 3NqHUTOk5hjUVLkG8YdKoOG+FPKw9skjJ5TSjfreVaQPk1G6nhfVn/SJB 2Rate0J4sOOtkR/T8iIr833GO5G+mLFAd6De8jeGDTY5kwBhox0mpx6od A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAHjQB1KrRDoH/2dsb2JhbABagwatbwGRdoEZFnSCSFw8NIhwtUiQOx2DewOJLaAIgzs X-IronPort-AV: E=Sophos;i="4.89,857,1367971200"; d="scan'208";a="88910194" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 11 Aug 2013 18:00:06 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7BI04lg025098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Aug 2013 18:00:04 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r7BI04VN006517; Sun, 11 Aug 2013 11:00:04 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r7BI04gI006516; Sun, 11 Aug 2013 11:00:04 -0700 (PDT) Date: Sun, 11 Aug 2013 11:00:04 -0700 (PDT) From: Fred Baker Message-Id: <201308111800.r7BI04gI006516@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 18:05:59 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From moreiras@nic.br Sun Aug 11 12:23: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 6141411E80F8 for ; Sun, 11 Aug 2013 12:23:56 -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 IaFIx4xGIq5D for ; Sun, 11 Aug 2013 12:23:55 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4F50921F93C4 for ; Sun, 11 Aug 2013 12:16:43 -0700 (PDT) Received: from [192.168.0.200] (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id DB8112080194; Sun, 11 Aug 2013 16:16:41 -0300 (BRT) Message-ID: <5207E319.6070601@nic.br> Date: Sun, 11 Aug 2013 16:16:41 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5207D42F.2030302@nic.br> In-Reply-To: <5207D42F.2030302@nic.br> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <5207D42F.2030302@nic.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alejandro Acosta Subject: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 19:23:56 -0000 Hi. I would like to ask you to please review and comment the following draft: http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 It intends to ask IANA to reserve another IPv6 prefix for documentation. Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago. The prefix 2001:db8::/32 showed to be very useful. It is widely used. But we are still facing the same problem that RFC 3849 tried to address: in some kind of documents, tutorials and didactic laboratories, we have been using other prefixes, because a /32 isn't enough to represent the scenario. We consider that a /20 would be enough. If possible, we would like to ask IANA to reserve something easy to remember, and self explaining, such as: 2D0C::/20 but *this suggestion is not stated in the document*. This prefix is from the global unicast space, and 2d00::/8 is currently marked as reserved by IANA [1], so it would be possible. Anyway, we think it would be better to discuss the question in the mailing-list. Reviewing the archives from when draft-huston-ipv6-documentation-prefix (that became RFC 3849) was being discussed, both questions (the necessity of a larger prefix, or multiple prefixes, and the possibility to reserve something easier to remember and self explaining) were raised. I am not sure why none of them led to something concrete. Probably because the draft just intended to document an allocation already made by APNIC, and maybe it was not so clear then how useful it would be. If you agree in principle with the proposal, other point to discuss is if this subject is compatible with v6ops. Maybe it should be addressed in 6man, or other place. Thanks. Moreiras. [1] http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml From owen@delong.com Sun Aug 11 15:38: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 6418911E8101 for ; Sun, 11 Aug 2013 15:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 h+tzJyQPc92U for ; Sun, 11 Aug 2013 15:38: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 3469F11E8141 for ; Sun, 11 Aug 2013 15:31: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 r7BMSwlO017379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 11 Aug 2013 15:28:58 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7BMSwlO017379 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376260142; bh=d14AKEPNUAUtlHbm+rKsWBizE68=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DcxNf58tPxCYyCGxfThbTBwK2GiuYFuWUJSnWy/MT6jLOmnI+CWgdG23crC5LI70x pUgwYPSOm+WQ2JqRv7JzGkXXB+O5Lm2hgrouGX3QM68VHJCEvqjFpMeiIktLTh76lE PRk8yeXincZ/GLQcp2SUt22OWls8zPQxK9ybrg6o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <5207E319.6070601@nic.br> Date: Sun, 11 Aug 2013 15:29:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> To: "Antonio M. Moreiras" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 11 Aug 2013 15:29:02 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 22:38:18 -0000 I support the idea. It might be worth also asking for a ULA Doc slice at = the same time. I think a /48 is probably sufficient for most ULA examples. But I think it would be good to be able to write up ULA examples and = training that use actual ULA prefixes intended for documentation. Owen On Aug 11, 2013, at 12:16 , "Antonio M. Moreiras" = wrote: > Hi. >=20 > I would like to ask you to please review and comment the following = draft: >=20 > http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 >=20 > It intends to ask IANA to reserve another IPv6 prefix for = documentation. > Something larger than the 2001:db8::/32, reserved by APNIC 10 years = ago. >=20 > The prefix 2001:db8::/32 showed to be very useful. It is widely used. > But we are still facing the same problem that RFC 3849 tried to = address: > in some kind of documents, tutorials and didactic laboratories, we = have > been using other prefixes, because a /32 isn't enough to represent the > scenario. >=20 > We consider that a /20 would be enough. >=20 > If possible, we would like to ask IANA to reserve something easy to > remember, and self explaining, such as: >=20 > 2D0C::/20 >=20 > but *this suggestion is not stated in the document*. This prefix is = from > the global unicast space, and 2d00::/8 is currently marked as reserved > by IANA [1], so it would be possible. Anyway, we think it would be > better to discuss the question in the mailing-list. >=20 > Reviewing the archives from when = draft-huston-ipv6-documentation-prefix > (that became RFC 3849) was being discussed, both questions (the > necessity of a larger prefix, or multiple prefixes, and the = possibility > to reserve something easier to remember and self explaining) were > raised. I am not sure why none of them led to something concrete. > Probably because the draft just intended to document an allocation > already made by APNIC, and maybe it was not so clear then how useful = it > would be. >=20 > If you agree in principle with the proposal, other point to discuss is > if this subject is compatible with v6ops. Maybe it should be addressed > in 6man, or other place. >=20 > Thanks. > Moreiras. >=20 > [1] > = http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic= ast-address-assignments.xhtml >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Sun Aug 11 16:44: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 CB7B421E808E for ; Sun, 11 Aug 2013 16:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.138, 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 MakozMnrSnDq for ; Sun, 11 Aug 2013 16:44: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 EDD2621F9D33 for ; Sun, 11 Aug 2013 16:38:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C1A79C9428; Sun, 11 Aug 2013 23:38:24 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376264318; bh=OHENm4yFugvDUGITG8BnC2SGn+zGTPcSSmo1v1B4ypY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=vCiytD2dErdW1waaBmH1XEZez+x745EZT5rdTnt5i+xpYzo2nLt3lGdl/MVE/p+8Y LxvcMqxjNSWbJHdfFgw5GnkNjpWSZq4elJLVKu8fK4FQH0FyYfqpw5qqAoCbOYYQRg YZ/alUFZOxBS6WvUzIzkponO3hMHgvRqQ5EprtNI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sun, 11 Aug 2013 23:38:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D27416042F; Sun, 11 Aug 2013 23:43:00 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id OyJjsqqDLNl4; Sun, 11 Aug 2013 23:42:58 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 878B416042E; Sun, 11 Aug 2013 23:42:58 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1E9BE16042D; Sun, 11 Aug 2013 23:42:58 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AE71C383CF0C; Mon, 12 Aug 2013 09:38:19 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> In-reply-to: Your message of "Sun, 11 Aug 2013 15:29:02 -0700." Date: Mon, 12 Aug 2013 09:38:19 +1000 Message-Id: <20130811233819.AE71C383CF0C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 23:44:51 -0000 In message , Owen DeLong write s: > I support the idea. It might be worth also asking for a ULA Doc slice at the > same time. I think a /48 is probably sufficient for most ULA examples. > > But I think it would be good to be able to write up ULA examples and training > that use actual ULA prefixes intended for documentation. Why? The purpose of reserving a prefix for documentation is to ensure that documentation prefixes doesn't clash with ones assigned by a registries. For locally assigned ULA don't need a reserved prefix because there is no registry assignments to clash with. For centrally assigned ULA there is no registry yet so no practical examples can exist. When such a registry is assigned we can document a prefix in the meantime just generate a new prefix when you write your documentation. dd if=/dev/random bs=5 count=1 | od -tx1 | awk '/000000/ { print "fd" $2 ":" $3 $4 ":" $5 $6 ; exit} Or flip a coin 40 times. Heads 1, tails 0. Mark > Owen > > On Aug 11, 2013, at 12:16 , "Antonio M. Moreiras" wrote: > > > Hi. > > > > I would like to ask you to please review and comment the following draft: > > > > http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 > > > > It intends to ask IANA to reserve another IPv6 prefix for documentation. > > Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago. > > > > The prefix 2001:db8::/32 showed to be very useful. It is widely used. > > But we are still facing the same problem that RFC 3849 tried to address: > > in some kind of documents, tutorials and didactic laboratories, we have > > been using other prefixes, because a /32 isn't enough to represent the > > scenario. > > > > We consider that a /20 would be enough. > > > > If possible, we would like to ask IANA to reserve something easy to > > remember, and self explaining, such as: > > > > 2D0C::/20 > > > > but *this suggestion is not stated in the document*. This prefix is from > > the global unicast space, and 2d00::/8 is currently marked as reserved > > by IANA [1], so it would be possible. Anyway, we think it would be > > better to discuss the question in the mailing-list. > > > > Reviewing the archives from when draft-huston-ipv6-documentation-prefix > > (that became RFC 3849) was being discussed, both questions (the > > necessity of a larger prefix, or multiple prefixes, and the possibility > > to reserve something easier to remember and self explaining) were > > raised. I am not sure why none of them led to something concrete. > > Probably because the draft just intended to document an allocation > > already made by APNIC, and maybe it was not so clear then how useful it > > would be. > > > > If you agree in principle with the proposal, other point to discuss is > > if this subject is compatible with v6ops. Maybe it should be addressed > > in 6man, or other place. > > > > Thanks. > > Moreiras. > > > > [1] > > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unica > st-address-assignments.xhtml > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From moreiras@nic.br Sun Aug 11 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 51A0011E80EE for ; Sun, 11 Aug 2013 16:47:39 -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 NtUaqyJqjHmg for ; Sun, 11 Aug 2013 16:47:38 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id ACF1C11E8106 for ; Sun, 11 Aug 2013 16:41:31 -0700 (PDT) Received: from [192.168.0.200] (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 4DA1920801DA; Sun, 11 Aug 2013 20:41:29 -0300 (BRT) Message-ID: <52082128.5090503@nic.br> Date: Sun, 11 Aug 2013 20:41:28 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alejandro Acosta Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 23:47:39 -0000 On 11/08/13 19:29, Owen DeLong wrote: > I support the idea. It might be worth also asking for a ULA Doc slice at the same time. > I think a /48 is probably sufficient for most ULA examples. > > But I think it would be good to be able to write up ULA examples and training that use > actual ULA prefixes intended for documentation. I agree. An organization could generate an ULA prefix specifically to use in a course, or document. But it could be copied and used in production environments. This would break the "global uniqueness", and could lead to other problems. It would be nice to have a specific ULA documentation prefix. I would suggest a prefix with the L bit cleared, easy to remember, and maybe slightly shorter than /48. For example FC00:0:D0C0::/44. []s Moreiras. From marka@isc.org Sun Aug 11 17:33: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 C093421F9A37 for ; Sun, 11 Aug 2013 17:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=-0.130, 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 Pe4u0lxTNwAh for ; Sun, 11 Aug 2013 17:33:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC4E21F96EF for ; Sun, 11 Aug 2013 17:27:57 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F0DF3C9496; Mon, 12 Aug 2013 00:27:43 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376267277; bh=C53Zt4Xeo4jeOW/fKXS+/s7x5+7+fKreWD1BQLtTYac=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=hzmKb9qgiT6VWniDhrbt9IE3xhON7fyFiZH9M7Ch6zWEg9qblfWge5jtyA5dWKzw4 eZwucAMeB2waF91BFTDh7raZjKjFZTAsOyxm0toLXdivfn0O72KJFBIpOWmi2XB988 G0ovCFkQl+VnaNMvr4axJmZKiNVRiGe1Br9XOYqQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 12 Aug 2013 00:27:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 62D5016042F; Mon, 12 Aug 2013 00:32:19 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9UmW2UatdWif; Mon, 12 Aug 2013 00:32:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0868F16042E; Mon, 12 Aug 2013 00:32:18 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id C95E016042D; Mon, 12 Aug 2013 00:32:17 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 34191383D34B; Mon, 12 Aug 2013 10:27:40 +1000 (EST) To: "Antonio M. Moreiras" From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> In-reply-to: Your message of "Sun, 11 Aug 2013 20:41:28 -0300." <52082128.5090503@nic.br> Date: Mon, 12 Aug 2013 10:27:40 +1000 Message-Id: <20130812002740.34191383D34B@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 00:33:38 -0000 In message <52082128.5090503@nic.br>, "Antonio M. Moreiras" writes: > On 11/08/13 19:29, Owen DeLong wrote: > > I support the idea. It might be worth also asking for a ULA Doc slice at th > e same time. > > I think a /48 is probably sufficient for most ULA examples. > > > > But I think it would be good to be able to write up ULA examples and traini > ng that use > > actual ULA prefixes intended for documentation. > > I agree. An organization could generate an ULA prefix specifically to > use in a course, or document. But it could be copied and used in > production environments. This would break the "global uniqueness", and > could lead to other problems. FUD. You either do the correct thing and generate your own prefix or you don't and copy one and hope that no one else has copied it that you are connecting to. Having a reserved prefix will not help you here. ULA are not "globally unique", they are locally unique with a extrememly low probability of collision when *locally* connecting. If you use them in a global context (i.e. publish to the world in AAAA records) without some global differentiator you will cause problems. All a documentation prefix will do is have one potentially toxic prefix compared to a handful of potentially toxic prefixes. There are 1099511627776 prefixes in fd00::/8. Even if there were thousands of documentation prefixes the odds of you hitting one when generating your own prefix are astronomically small. Additionally the more prefixes that are used in documentation the less toxic a particular prefix will be. Mark > It would be nice to have a specific ULA documentation prefix. > > I would suggest a prefix with the L bit cleared, easy to remember, and > maybe slightly shorter than /48. For example FC00:0:D0C0::/44. > > []s > Moreiras. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cb.list6@gmail.com Sun Aug 11 17:44: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 AE6C221F9F84 for ; Sun, 11 Aug 2013 17:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 LeNIcwqnwDHM for ; Sun, 11 Aug 2013 17:44:00 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8911E813D for ; Sun, 11 Aug 2013 17:36:20 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so5038346wgh.32 for ; Sun, 11 Aug 2013 17:36:19 -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=eeXRNwoPEW/2r69XJSh7wM1AKZeobJ8RvlASPiFVMUY=; b=zM13j6rM+xE2WGw3LugJS2K2m4SolQBVUwn+odtro9zuP8AYLIS1UxAp7OG9hcinkq /wLdHlGNyGo0kv1xIPilXsR3UejDJEDsxnTODLCWRvmMbllB1kg+aVvf8aKRo6stZpvz HW1HbebZrqWW3Sh3nmLVjuc5YREdp92t/HaDwWOMxTkla2HEc7RFSCq8lRo1w6+6q90y QjS36eTyYWPHerdL68ik4EGGFEHclvrhrSLe3CGOUo+BXb1e2kMOpmOYor++e6K+kBqH hpm14/1pNbaAT1xEF3HI5TJjG9osukyXbOsyyF9stVkLrMPDrq4I3zVpIJ5lgrJ6dypg 6cTQ== MIME-Version: 1.0 X-Received: by 10.180.188.97 with SMTP id fz1mr5151740wic.34.1376267778737; Sun, 11 Aug 2013 17:36:18 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Sun, 11 Aug 2013 17:36:18 -0700 (PDT) Received: by 10.216.15.68 with HTTP; Sun, 11 Aug 2013 17:36:18 -0700 (PDT) In-Reply-To: <5207E319.6070601@nic.br> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> Date: Sun, 11 Aug 2013 17:36:18 -0700 Message-ID: From: "cb.list6" To: "Antonio M. Moreiras" Content-Type: multipart/alternative; boundary=001a11c38dc0114d3a04e3b55039 Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 00:44:01 -0000 --001a11c38dc0114d3a04e3b55039 Content-Type: text/plain; charset=ISO-8859-1 On Aug 11, 2013 12:24 PM, "Antonio M. Moreiras" wrote: > > Hi. > > I would like to ask you to please review and comment the following draft: > > http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 > > It intends to ask IANA to reserve another IPv6 prefix for documentation. > Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago. > > The prefix 2001:db8::/32 showed to be very useful. It is widely used. > But we are still facing the same problem that RFC 3849 tried to address: > in some kind of documents, tutorials and didactic laboratories, we have > been using other prefixes, because a /32 isn't enough to represent the > scenario. > > We consider that a /20 would be enough. > > If possible, we would like to ask IANA to reserve something easy to > remember, and self explaining, such as: > > 2D0C::/20 > > but *this suggestion is not stated in the document*. This prefix is from > the global unicast space, and 2d00::/8 is currently marked as reserved > by IANA [1], so it would be possible. Anyway, we think it would be > better to discuss the question in the mailing-list. > > Reviewing the archives from when draft-huston-ipv6-documentation-prefix > (that became RFC 3849) was being discussed, both questions (the > necessity of a larger prefix, or multiple prefixes, and the possibility > to reserve something easier to remember and self explaining) were > raised. I am not sure why none of them led to something concrete. > Probably because the draft just intended to document an allocation > already made by APNIC, and maybe it was not so clear then how useful it > would be. > > If you agree in principle with the proposal, other point to discuss is > if this subject is compatible with v6ops. Maybe it should be addressed > in 6man, or other place. > As a network operator i already must block the documentation prefix today. I see no good reason why i must update all my acls for this new prefix If your docs require more than /32, use ULA. If you must make another official documentation prefix do not take it from 2000/3 If you take it from 2000/3 you are creating work for network operators CB > Thanks. > Moreiras. > > [1] > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a11c38dc0114d3a04e3b55039 Content-Type: text/html; charset=ISO-8859-1


On Aug 11, 2013 12:24 PM, "Antonio M. Moreiras" <moreiras@nic.br> wrote:
>
> Hi.
>
> I would like to ask you to please review and comment the following draft:
>
> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00
>
> It intends to ask IANA to reserve another IPv6 prefix for documentation.
> Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago.
>
> The prefix 2001:db8::/32 showed to be very useful. It is widely used.
> But we are still facing the same problem that RFC 3849 tried to address:
> in some kind of documents, tutorials and didactic laboratories, we have
> been using other prefixes, because a /32 isn't enough to represent the
> scenario.
>
> We consider that a /20 would be enough.
>
> If possible, we would like to ask IANA to reserve something easy to
> remember, and self explaining, such as:
>
> 2D0C::/20
>
> but *this suggestion is not stated in the document*. This prefix is from
> the global unicast space, and 2d00::/8 is currently marked as reserved
> by IANA [1], so it would be possible. Anyway, we think it would be
> better to discuss the question in the mailing-list.
>
> Reviewing the archives from when draft-huston-ipv6-documentation-prefix
> (that became RFC 3849) was being discussed, both questions (the
> necessity of a larger prefix, or multiple prefixes, and the possibility
> to reserve something easier to remember and self explaining) were
> raised. I am not sure why none of them led to something concrete.
> Probably because the draft just intended to document an allocation
> already made by APNIC, and maybe it was not so clear then how useful it
> would be.
>
> If you agree in principle with the proposal, other point to discuss is
> if this subject is compatible with v6ops. Maybe it should be addressed
> in 6man, or other place.
>

As a network operator i already must block the documentation prefix today.

I see no good reason why i must update all my acls for this new prefix

If your docs require more than /32, use ULA. If you must make another official documentation prefix do not take it from 2000/3

If you take it from 2000/3 you are creating work for network operators

CB

> Thanks.
> Moreiras.
>
> [1]
> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--001a11c38dc0114d3a04e3b55039-- From moreiras@nic.br Sun Aug 11 19:05: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 309D721F9D95 for ; Sun, 11 Aug 2013 19:05:04 -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 yLhPYsyHCWIx for ; Sun, 11 Aug 2013 19:05:03 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5011E812A for ; Sun, 11 Aug 2013 18:58:17 -0700 (PDT) Received: from [192.168.0.200] (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 4FE272080207; Sun, 11 Aug 2013 22:58:16 -0300 (BRT) Message-ID: <52084137.3000602@nic.br> Date: Sun, 11 Aug 2013 22:58:15 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> In-Reply-To: <20130812002740.34191383D34B@drugs.dv.isc.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 02:05:04 -0000 On 11/08/13 21:27, Mark Andrews wrote: > In message <52082128.5090503@nic.br>, "Antonio M. Moreiras" writes: >> On 11/08/13 19:29, Owen DeLong wrote: >>> I support the idea. It might be worth also asking for a ULA Doc slice at th >> e same time. >>> I think a /48 is probably sufficient for most ULA examples. >>> >>> But I think it would be good to be able to write up ULA examples and traini >> ng that use >>> actual ULA prefixes intended for documentation. >> >> I agree. An organization could generate an ULA prefix specifically to >> use in a course, or document. But it could be copied and used in >> production environments. This would break the "global uniqueness", and >> could lead to other problems. > > FUD. > > You either do the correct thing and generate your own prefix or you > don't and copy one and hope that no one else has copied it that you > are connecting to. Having a reserved prefix will not help you here. I can agree with you, in parts. We should expect that people generate their own ULA prefix, following RFC 4193. But can we count on that? I think that one of the points in having documentation prefixes it's because they can be filtered "in advance" in our networks. So if an intern, a trainee, or a newbie just copy the configs from a howto document, and manages to put it in our production environment, we will be safe. So, let's suppose that you write a brilliant book, or howto, about how to use ULA addresses in some kind of application for a corporate network. Let's suppose that you generate your own ULA for your document. Your prefix may be copied and implemented in hundreds, maybe thousands of networks. It isn't a big problem, because ULA is for private use. But if two of these companies merge, or have some kind of private agreement and want to connect their networks and make their ULA blocks reachable, it would be a problem... Ok, it is a big if. But, what would be the downside of having an ULA prefix reserved for documentation? If the local filters are updated and block this prefix, when a newbie try to copy your example and put it to work, it will not work. He will realize that he is doing something wrong, and maybe he can learn how he can use ULA addresses in the right way. Please let's also remember that the current version of the *draft is not asking for an ULA documentation prefix*. The draft is asking for a bigger *unicast global* prefix for documentation. > ULA are not "globally unique", they are locally unique with a > extrememly low probability of collision when *locally* connecting. > If you use them in a global context (i.e. publish to the world in > AAAA records) without some global differentiator you will cause > problems. > > All a documentation prefix will do is have one potentially toxic > prefix compared to a handful of potentially toxic prefixes. There > are 1099511627776 prefixes in fd00::/8. Even if there were thousands > of documentation prefixes the odds of you hitting one when generating > your own prefix are astronomically small. Additionally the more > prefixes that are used in documentation the less toxic a particular > prefix will be. > > Mark > >> It would be nice to have a specific ULA documentation prefix. >> >> I would suggest a prefix with the L bit cleared, easy to remember, and >> maybe slightly shorter than /48. For example FC00:0:D0C0::/44. >> >> []s >> Moreiras. From marka@isc.org Sun Aug 11 20:00: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 87A8121E80B0 for ; Sun, 11 Aug 2013 20:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX4xqkstJRmC for ; Sun, 11 Aug 2013 20:00:23 -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 ACEAC21E805A for ; Sun, 11 Aug 2013 19:54:01 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 733FDC9432; Mon, 12 Aug 2013 02:53:46 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376276039; bh=q9/dQScfS0qEmjT+KHTIWrDkjMXevu7Tvyqm2hQELhU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Zoe6+sxIQy2YEmJ1VIbMYVPcLpanpBjyfLh2CNzWsW+oWU3IbfjbiduPAg7OFbYGb 7bj05wPA4e1AZhwmTGYefMUrixNU91K5Epgd/0L5wRartAtu6lttPxL3n70nPN7sYe +bgmwGqbZLQxzRhwTT7KhCVam8+KhFIMhfBBvOUA= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 12 Aug 2013 02:53:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55FD516030C; Mon, 12 Aug 2013 02:58:22 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GVFdfqbeSbdc; Mon, 12 Aug 2013 02:58:21 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C96F616042F; Mon, 12 Aug 2013 02:58:21 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5FF6716042E; Mon, 12 Aug 2013 02:58:21 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AB2E6383EF22; Mon, 12 Aug 2013 12:53:42 +1000 (EST) To: "Antonio M. Moreiras" From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> <52084137.3000602@nic.br> In-reply-to: Your message of "Sun, 11 Aug 2013 22:58:15 -0300." <52084137.3000602@nic.br> Date: Mon, 12 Aug 2013 12:53:42 +1000 Message-Id: <20130812025342.AB2E6383EF22@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 03:00:29 -0000 In message <52084137.3000602@nic.br>, "Antonio M. Moreiras" writes: > On 11/08/13 21:27, Mark Andrews wrote: > > In message <52082128.5090503@nic.br>, "Antonio M. Moreiras" writes: > >> On 11/08/13 19:29, Owen DeLong wrote: > >>> I support the idea. It might be worth also asking for a ULA Doc slice at th > >> e same time. > >>> I think a /48 is probably sufficient for most ULA examples. > >>> > >>> But I think it would be good to be able to write up ULA examples and traini > >> ng that use > >>> actual ULA prefixes intended for documentation. > >> > >> I agree. An organization could generate an ULA prefix specifically to > >> use in a course, or document. But it could be copied and used in > >> production environments. This would break the "global uniqueness", and > >> could lead to other problems. > > > > FUD. > > > > You either do the correct thing and generate your own prefix or you > > don't and copy one and hope that no one else has copied it that you > > are connecting to. Having a reserved prefix will not help you here. > > I can agree with you, in parts. > > We should expect that people generate their own ULA prefix, following > RFC 4193. > > But can we count on that? I think that one of the points in having > documentation prefixes it's because they can be filtered "in advance" in > our networks. So if an intern, a trainee, or a newbie just copy the > configs from a howto document, and manages to put it in our production > environment, we will be safe. > > So, let's suppose that you write a brilliant book, or howto, about how > to use ULA addresses in some kind of application for a corporate > network. Let's suppose that you generate your own ULA for your document. > Your prefix may be copied and implemented in hundreds, maybe thousands > of networks. > > It isn't a big problem, because ULA is for private use. But if two of > these companies merge, or have some kind of private agreement and want > to connect their networks and make their ULA blocks reachable, it would > be a problem... Ok, it is a big if. Then both of the companies had to be stupid and they need to renumber one or both of the networks as part of the merger. This is a cost of being clueless. Having a reserved prefix does not help with this sort of cluelessness. It just makes it worse. > But, what would be the downside of having an ULA prefix reserved for > documentation? Because it actually makes the clueless problem worse. > If the local filters are updated and block this prefix, when a newbie > try to copy your example and put it to work, it will not work. He will > realize that he is doing something wrong, and maybe he can learn how he > can use ULA addresses in the right way. You should be filtering all of fc00::/7 anyway at the border / bgp feeds anyway. When you merge you add exceptions. Locally assigned ULA are not the same as global addresses. The do not have the same security properties as GUA. You have to assume that the sites you connect to will have choosen the same prefix as you have choosen as there is no one co-ordinating things. > Please let's also remember that the current version of the *draft is not > asking for an ULA documentation prefix*. > > The draft is asking for a bigger *unicast global* prefix for documentation. > > > ULA are not "globally unique", they are locally unique with a > > extrememly low probability of collision when *locally* connecting. > > If you use them in a global context (i.e. publish to the world in > > AAAA records) without some global differentiator you will cause > > problems. > > > > All a documentation prefix will do is have one potentially toxic > > prefix compared to a handful of potentially toxic prefixes. There > > are 1099511627776 prefixes in fd00::/8. Even if there were thousands > > of documentation prefixes the odds of you hitting one when generating > > your own prefix are astronomically small. Additionally the more > > prefixes that are used in documentation the less toxic a particular > > prefix will be. > > > > Mark > > > >> It would be nice to have a specific ULA documentation prefix. > >> > >> I would suggest a prefix with the L bit cleared, easy to remember, and > >> maybe slightly shorter than /48. For example FC00:0:D0C0::/44. > >> > >> []s > >> Moreiras. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From moreiras@nic.br Sun Aug 11 20:34: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 02B5B21F898A for ; Sun, 11 Aug 2013 20:34:03 -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 7Sj+QLkXotnZ for ; Sun, 11 Aug 2013 20:34:02 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0E28E21F8ECA for ; Sun, 11 Aug 2013 20:27:27 -0700 (PDT) Received: from [192.168.0.200] (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 7A5F72080187; Mon, 12 Aug 2013 00:27:26 -0300 (BRT) Message-ID: <5208561E.4050606@nic.br> Date: Mon, 12 Aug 2013 00:27:26 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "cb.list6" References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 03:34:03 -0000 On 11/08/13 21:36, cb.list6 wrote: > As a network operator i already must block the documentation prefix today. > > I see no good reason why i must update all my acls for this new prefix > > If your docs require more than /32, use ULA. If you must make another > official documentation prefix do not take it from 2000/3 > > If you take it from 2000/3 you are creating work for network operators > > CB This is a very good point, thank you for your comment. I work with IPv6 trainings for network operators, and my team writes a lot of documentation (regarding these trainings). There are a some situations where we have to use prefixes shorter than /32. In our trainings for Autonomous Systems, for example, we need at least a /27 in order to correctly represent the scenario for the laboratory. I don't want to use ULA addresses for teaching IPv6, in these trainings, or to write the examples and documentation. I will try to explain why. Generally these trainings are the first contact with IPv6 for our students. Their biggest difficulties generally lies in understanding the IPv6 addresses. The types of addresses, where to use each of them, the new format, etc. From a didactic point of view, it would be a very bad idea to use ULAs and tell them: please don't forget to pretend that this ULA block is our Global Unicast block, and this other ULA prefix will be the "real" ULA in our lab. It also would be a bad idea to give them a /48 and just tell: please, let's pretend that it is a /32, and work in the address plan for your ISP. We have a really bad time trying to convince people that private addresses and NATs are not necessary in all situations. Using ULAs in the practice, instead of Globals, would not help. I fear that using ULAs in the labs and examples could lead us to a situation where some networks would finish having just ULA addresses, and NAT66, in scenarios where it would not be the better choice. Maybe we could use addresses outside 2000::/3 for documentation. One of the other authors was trying to convince me that would be better ask IANA for something like 4D0C::/20, before this comment. Personally I think that something outside 2000::/3 is bad for didactic. I also think that it would just postpone the problem. Probably the chosen block would be assigned as Global Unicast sometime in the future. And it would be very strange if the block were assigned to something other than global. But maybe it would be acceptable. I can't argue against the point presented. With a new block, there would be extra work for some networks. What I can do is to ask how bad it would be? I would like also to consider that people are already using other prefixes than 2001:db8::/32 in laboratories, and documentation. Wouldn't be better to define one new prefix, and have the possibility to update the filters to prevent operational problems? Please, let's also consider that the IPv6 deployment in the Internet is far from reach the majority of the networks. So, for most of them, the filters are not yet implemented, and there wouldn't be extra work. Moreiras. From alejandroacostaalamo@gmail.com Sun Aug 11 20:44:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4938811E80FE for ; Sun, 11 Aug 2013 20:44:38 -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 oUtCxlfkYClQ for ; Sun, 11 Aug 2013 20:44:37 -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 3F1F511E8122 for ; Sun, 11 Aug 2013 20:36:24 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so5112529wgh.9 for ; Sun, 11 Aug 2013 20:36:23 -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=A7SwEgekwXrk/r85/e4Xr/lgGmA/lfet6n2fCoyMXh0=; b=0/cDnhbGnmx1NPVHeJ5qv139ar9JW+gRXRuuxdE0FaMfy3eQnjmxR+WkFOKj55V46B hEU/CFSrstS4bHCnW/JZtGivWdS5OAn+G9lafRY04OQIgZYhQpoo9z589kuxoMX9YOyR 7E8dUgie7qy+U8Kjlo9j+YU0dZtESpcTsmGLGTXocgfVKHwHnGomvS2qKhqkHPlUnSeT NsSegmnrN1wNf/knd/EaGCnBAnH9FVXlFt/hZRap9OSRbKz30d7Lpg46+WyzmD7MOvdc TsnJWgiNXmlv11AX6kGjHMAkiqx30LEb8TsvEQjpVmYfl0d53YJot912p1mnkr0nV1pl d91Q== MIME-Version: 1.0 X-Received: by 10.180.75.148 with SMTP id c20mr5369756wiw.25.1376278583346; Sun, 11 Aug 2013 20:36:23 -0700 (PDT) Received: by 10.217.143.196 with HTTP; Sun, 11 Aug 2013 20:36:23 -0700 (PDT) In-Reply-To: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> Date: Sun, 11 Aug 2013 23:06:23 -0430 Message-ID: From: Alejandro Acosta To: "cb.list6" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 03:44:38 -0000 My comments below: On 8/11/13, cb.list6 wrote: > On Aug 11, 2013 12:24 PM, "Antonio M. Moreiras" wrote: >> >> Hi. >> >> I would like to ask you to please review and comment the following draft: >> >> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 >> >> It intends to ask IANA to reserve another IPv6 prefix for documentation. >> Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago. >> >> The prefix 2001:db8::/32 showed to be very useful. It is widely used. >> But we are still facing the same problem that RFC 3849 tried to address: >> in some kind of documents, tutorials and didactic laboratories, we have >> been using other prefixes, because a /32 isn't enough to represent the >> scenario. >> >> We consider that a /20 would be enough. >> >> If possible, we would like to ask IANA to reserve something easy to >> remember, and self explaining, such as: >> >> 2D0C::/20 >> >> but *this suggestion is not stated in the document*. This prefix is from >> the global unicast space, and 2d00::/8 is currently marked as reserved >> by IANA [1], so it would be possible. Anyway, we think it would be >> better to discuss the question in the mailing-list. >> >> Reviewing the archives from when draft-huston-ipv6-documentation-prefix >> (that became RFC 3849) was being discussed, both questions (the >> necessity of a larger prefix, or multiple prefixes, and the possibility >> to reserve something easier to remember and self explaining) were >> raised. I am not sure why none of them led to something concrete. >> Probably because the draft just intended to document an allocation >> already made by APNIC, and maybe it was not so clear then how useful it >> would be. >> >> If you agree in principle with the proposal, other point to discuss is >> if this subject is compatible with v6ops. Maybe it should be addressed >> in 6man, or other place. >> > > As a network operator i already must block the documentation prefix today. As most of us. > > I see no good reason why i must update all my acls for this new prefix We tried to explain the reasons in the drafts. So far the documentation prefix has been incredible useful at all levels, however we know that there are _many_ cases where a /32 for documentation is not enough, we mentioned many situations in the draft and I do not doubt that there are probably more. > > If your docs require more than /32, use ULA. If you must make another > official documentation prefix do not take it from 2000/3 In that case let's obsolete 3849.., sorry just kidding. > > If you take it from 2000/3 you are creating work for network operators In somehow the authors considered the idea of using 4D0C::/20 instead of using 2D0C::/20 however we really want to hear everyone opinions here. In this case, using 4D0C nobody need to update the ACLs as you mention. Thanks, Alejandro, > > CB > >> Thanks. >> Moreiras. >> >> [1] >> > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > -- ===== ^A.......o$ From avayner@cisco.com Sun Aug 11 22:34: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 3C73521E8084 for ; Sun, 11 Aug 2013 22:34:07 -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=[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 EshBcVE8HJlK for ; Sun, 11 Aug 2013 22:34: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 93D6621F8427 for ; Sun, 11 Aug 2013 22:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14309; q=dns/txt; s=iport; t=1376285264; x=1377494864; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wCrrjQfwoVjBFh8NPK+IRtvNgYCLTHOqKPaKnbTfTIA=; b=PdLp8+jZUaKjAW27MSLMaUo7K1HMkinfxZ4maYcKMv2+GWSiayGgN/24 Z9UqqTzFd9G/I4KRsnxjFhAwxUwZkGLZuJIASihPdPgfK24yaG90wlEDb kcq0otNPab88OW520l2yG3jmTxMR4zOG9phnRxTrEuMsGXjPWQmsw86Zx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAIpxCFKtJV2a/2dsb2JhbABagkJENVC+VYEaFnSCJAEBAQQtTBACAQgRBAEBCx0HMhQJCAIEDgUIE4d1tWGQCjEGAYMbdgOpNYMbgio X-IronPort-AV: E=Sophos;i="4.89,859,1367971200"; d="scan'208,217";a="246101127" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2013 05:27:43 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7C5Rg8t012105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 05:27:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 00:27:42 -0500 From: "Arie Vayner (avayner)" To: Owen DeLong Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkTyDDMSxdUYJukeaGavK35KXPJmGm1kAgACKQoCAAF43gIAAFCCAgAArgQCAAkwdAIACTLxQgAE/M4CAA3qcsA== Date: Mon, 12 Aug 2013 05:27:42 +0000 Message-ID: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.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.89.89] Content-Type: multipart/alternative; boundary="_000_CA6D42D0F8A41948AEB3864480C554F104AEAABExmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 05:34:07 -0000 --_000_CA6D42D0F8A41948AEB3864480C554F104AEAABExmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Owen, While the arguments about moving the firewalls closer to the users are vali= d they are often are not practical (or at least the customers I worked with= would not implement this option). Imagine an enterprise network with 300 spoke sites, but only 2 or 3 Interne= t gateway locations (with some private WAN in between). Moving the firewalls to the spoke sites would increase the number of firewa= lls from ~3 to ~300 (I am ignoring redundancy and scale for a second)... Th= is is a major CAPEX and OPEX impact... Arie From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, August 9, 2013 12:17 PM To: Arie Vayner (avayner) Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); v6ops@ietf.o= rg Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) > wrote: Another loosely related point that I think could make sense in such a docum= ent would be the ways to accomplish multi-homing and how it is different th= an today's IPv4 implementations. Many enterprises rely on NAT on the Internet edge as their multi-homing/tra= ffic engineering mechanism with IPv4. If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), = then we need to highlight the symmetry requirement due to stateful security= layers. Traffic leaving from an Internet gateway site to the Internet has to come b= ack through the same site, or the stateful firewalls would break the flow (= well, has to hit the same stateful security layer) Or stateful firewalls have to get better about sharing state. There are two= things that can help with this... 1. Put your firewalls as close to the end systems they protect as p= ossible. Make your security zones relatively small and place the firewalls = closer together at those narrower borders. This will often require more firewall units, but it helps in a = number of ways: A. Firewall policy tends to be much simpler (and as a re= sult less error prone and more reliable) B. The hardware demands on the firewall tend to be lower= so you can buy cheaper units. C. The simpler rulesets can be more easily tailored to m= eet business requirements as they evolve. 2. Improve firewalls. Give the firewalls that all protect the same = boundary a way to mesh-peer with each other and exchange information about = the state tables such that triangle routing is no longer problematic. Syncing upstream and downstream routing policies is not always an easy task= (but could be relevant in some cases). Linking the Internet gateway layer across sites (before hitting the statefu= l security layer) could be another solution. If we make the changes above to the firewalls, this could be a lot less re= levant in most cases. Do you think a short discussion to raise awareness for this potential issue= could be relevant in such a document? It's certainly worth documenting. I'm not sure whether it belongs in this d= ocument or not. Owen --_000_CA6D42D0F8A41948AEB3864480C554F104AEAABExmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Owen,

 <= /p>

While the arguments about= moving the firewalls closer to the users are valid they are often are not = practical (or at least the customers I worked with would not implement this option).

Imagine an enterprise net= work with 300 spoke sites, but only 2 or 3 Internet gateway locations (with= some private WAN in between).

Moving the firewalls to t= he spoke sites would increase the number of firewalls from ~3 to ~300 (I am= ignoring redundancy and scale for a second)… This is a major CAPEX and OPEX impact…

 <= /p>

Arie

 <= /p>

From: Owen D= eLong [mailto:owen@delong.com]
Sent: Friday, August 9, 2013 12:17 PM
To: Arie Vayner (avayner)
Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); v6ops= @ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WG= LC

 

 

On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) <= ;avayner@cisco.com> wrote:=



Another loosely related p= oint that I think could make sense in such a document would be the ways to = accomplish multi-homing and how it is different than today’s IPv4 implementations.

 <= /p>

Many enterprises rely on = NAT on the Internet edge as their multi-homing/traffic engineering mechanis= m with IPv4.

 <= /p>

If we recommend against U= LA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highl= ight the symmetry requirement due to stateful security layers.<= /o:p>

Traffic leaving from an I= nternet gateway site to the Internet has to come back through the same site= , or the stateful firewalls would break the flow (well, has to hit the same stateful security layer)

 

Or stateful firewalls have to get better about shari= ng state. There are two things that can help with this...

 

1.   &= nbsp;     Put your firewalls as close to the end= systems they protect as possible. Make your security zones relatively smal= l and place the firewalls closer together at those narrower borders.

   &nb= sp;        This will often requir= e more firewall units, but it helps in a number of ways:

   &nb= sp;        A.        Firewall policy tends to be much simpler (and as a result less error= prone and more reliable)

   &nb= sp;        B.        The hardware demands on the firewall tend to be lower so you can buy= cheaper units.

   &nb= sp;        C.        The simpler rulesets can be more easily tailored to meet business re= quirements as they evolve.

 <= /p>

 <= /p>

 

2.   &= nbsp;     Improve firewalls. Give the firewalls = that all protect the same boundary a way to mesh-peer with each other and e= xchange information about the state tables such that triangle routing is no longer problematic.



Syncing upstream and down= stream routing policies is not always an easy task (but could be relevant i= n some cases).

Linking the Internet gate= way layer across sites (before hitting the stateful security layer) could b= e another solution.

 

If we make the changes above to the firewalls, this = could be  a lot less relevant in most cases.



Do you think a short disc= ussion to raise awareness for this potential issue could be relevant in suc= h a document?

 

It's certainly worth documenting. I'm not sure wheth= er it belongs in this document or not.

 

Owen

 

 

--_000_CA6D42D0F8A41948AEB3864480C554F104AEAABExmbrcdx10ciscoc_-- From lorenzo@google.com Sun Aug 11 22:42: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 2EE4F21F9CFB for ; Sun, 11 Aug 2013 22:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.014, 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 oZe5MeVrQ-5f for ; Sun, 11 Aug 2013 22:42:49 -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 07D6C21E80A5 for ; Sun, 11 Aug 2013 22:35:01 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id aq17so7509921iec.39 for ; Sun, 11 Aug 2013 22:35:01 -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=R5x11hWaeNx2xrY5XycXiMxCHkcHaHJgUnRFnEXnRpI=; b=e92AlHXaR6Mj5bBz8W1SXwBXSIU6Ul135QIze6O9W9c7qUi5u8AZQwrR+thtKAAyn9 EzI6lbANRIhYMNOfy/ghpUQNppO+ugiV2YKVn7EygCY9nwiuOPg5usCCvNOx9Bj8+WHy 1RC/fc+s+c7CrCdxhDxos2/L2A15ZfrrZ8YmBVdgmDjJgTxlFuwjz/rIHtCMFZ/tD0gv FH2DciVgRuoK/WIV2FtEc2U8K6bX+uGGDZ2zCA5IwsX4KaOe2qHpEn1lfjZarhip51/9 tvDr6BEo7E6FqCYivD3KeRnps2876+Ua/pj2cLemLfOQILDdWS2qSfocrV6JC5spZQ+l WHzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R5x11hWaeNx2xrY5XycXiMxCHkcHaHJgUnRFnEXnRpI=; b=VAwxaQ9xhSAWjvhS2bZHEyQQheLKtW27u1vjnSZROPDOOpaP1Cy335uLm8sV+McuIg e3mg/jGh9IMbFDh0JIl02AFzBdG7UMdbDAt1cK8n2qrFWjOg5SIPMiO6RxWaTAtXumA3 rukCe5bA1QgszouXQbPiLadg8a/ZzpSYNVPuragfi4ELC6kIkuxr/lnoOnSHqMtnH0fu 5Mx/KOOyY8AH7Xr80FhyMmRKXFWo8IOjmR10g6HIiS2SUux0rB9JXYrPqszlwOA7+KNX UbHV3pTckiY6OOZY1RnUVMFCJyP5MjLBONhaqEbpYmwSti1bs+5V1WfdFwrg6oUdk/UM mDfQ== X-Gm-Message-State: ALoCoQn7nTI5ZVd5KYp97ZanICGSThonSULszNMNaG6POvUmdQCKbW9Nkwz9TsLebD9/nFasJhC71wyL4Phh3F5Xf+W0FX+XXYhM+j1fQqRMl7qr8lgkfKtwK47lX1UJsn/BZIdeI0t+Nk+P1gwdUGhgy1fFPNmDHD3xWSx8ybSthXyhYe+06ALdAs4qZv+zIKA0PhOZ1dCU X-Received: by 10.43.148.69 with SMTP id kf5mr8501798icc.41.1376285701407; Sun, 11 Aug 2013 22:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.181.72 with HTTP; Sun, 11 Aug 2013 22:34:41 -0700 (PDT) In-Reply-To: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> From: Lorenzo Colitti Date: Mon, 12 Aug 2013 14:34:41 +0900 Message-ID: To: "Arie Vayner (avayner)" Content-Type: multipart/alternative; boundary=001a11c2d21457b1ef04e3b97cf2 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 05:42:50 -0000 --001a11c2d21457b1ef04e3b97cf2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner) wrote: > Many enterprises rely on NAT on the Internet edge as their > multi-homing/traffic engineering mechanism with IPv4. > > ** ** > > If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), > then we need to highlight the symmetry requirement due to stateful security > layers.**** > > Traffic leaving from an Internet gateway site to the Internet has to come > back through the same site, or the stateful firewalls would break the flow > (well, has to hit the same stateful security layer) > By itself, NPTv6 doesn't protect against this problem because it's not stateful. It only protects against this problem if each egress point is only reachable using one prefix (which is not a requirement for doing NPTv6 - you could just as well do it by configuring all multiple exit points to use the same prefix, or to use all prefixes from all exit points). What does protect you against this is using source+destination routing, which is what this draft should recommend instead of recommending NPTv6. --001a11c2d21457b1ef04e3b97cf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner) <av= ayner@cisco.com> wrote:

Many enterprises rely on NAT on the Internet= edge as their multi-homing/traffic engineering mechanism with IPv4.=

=A0<= /p>

If we recommend against U= LA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highlight= the symmetry requirement due to stateful security layers.

Traffic leaving from an I= nternet gateway site to the Internet has to come back through the same site= , or the stateful firewalls would break the flow (well, has to hit the same stateful security layer)


By itself, NPTv6 doesn't protect against this= problem because it's not stateful. It only protects against this probl= em if each egress point is only reachable using one prefix (which is not a = requirement for doing NPTv6 - you could just as well do it by configuring a= ll multiple exit points to use the same prefix, or to use all prefixes from= all exit points).

What does protect you against this is using source+dest= ination routing, which is what this draft should recommend instead of recom= mending NPTv6.
--001a11c2d21457b1ef04e3b97cf2-- From owen@delong.com Mon Aug 12 10:11: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 B240B21F994B for ; Mon, 12 Aug 2013 10:11:42 -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, 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 KmponFSUcH-W for ; Mon, 12 Aug 2013 10:11: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 C13AD21F9A38 for ; Mon, 12 Aug 2013 09:55: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 r7CGsa6B012141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 09:54:36 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CGsa6B012141 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376326478; bh=Hle7yFFbTgATolkaVwHWnQoqO1s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nqeog4As9R251XnPVWjQzChALX0t7z3dMleH1zQndhxeq4Rqx7oKxzUni/ndb0xtd xGLurP7s4g9QT0DgP3gvp14vun3QIUX3mwWf/zWXRSDeo4ehGmh1PdLKoiLsgFzQfN Z2sSUjfjZArOAWn+8iRSruj2p0LliziiJXiaC+k0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <20130811233819.AE71C383CF0C@drugs.dv.isc.org> Date: Mon, 12 Aug 2013 09:54:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 09:54:38 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:11:51 -0000 On Aug 11, 2013, at 16:38 , Mark Andrews wrote: >=20 > In message , Owen = DeLong write > s: >> I support the idea. It might be worth also asking for a ULA Doc slice = at the=20 >> same time. I think a /48 is probably sufficient for most ULA = examples. >>=20 >> But I think it would be good to be able to write up ULA examples and = training >> that use actual ULA prefixes intended for documentation. >=20 > Why? >=20 > The purpose of reserving a prefix for documentation is to ensure > that documentation prefixes doesn't clash with ones assigned by a > registries. For locally assigned ULA don't need a reserved prefix > because there is no registry assignments to clash with. For centrally > assigned ULA there is no registry yet so no practical examples can > exist. When such a registry is assigned we can document a prefix in = the > meantime just generate a new prefix when you write your documentation. >=20 > dd if=3D/dev/random bs=3D5 count=3D1 | od -tx1 | > awk '/000000/ { print "fd" $2 ":" $3 $4 ":" $5 $6 ; exit} >=20 Because, as history has shown, if there isn't a prefix documented as = "you should use this for documentation and training only", people tend to = copy examples verbatim instead. Admittedly, I still run into the occasional internal network numbered = out of doc-prefix space in IPv4 because they copied the examples, but I run into a lot more cases where they improperly copied examples that used other prefixes than the documentation prefix. The point of a documentation prefix is not only to avoid clashing with registry space. It is also so that if you blindly copy examples, this = fact is instantly obvious to any network engineer who knows what they are doing and can be more easily identified and corrected (hopefully before it becomes entrenched beyond repair). Owen From owen@delong.com Mon Aug 12 10:15: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 34FC721F9298 for ; Mon, 12 Aug 2013 10:15:57 -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 xujwMq4c1fww for ; Mon, 12 Aug 2013 10:15:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D8CC421E8054 for ; Mon, 12 Aug 2013 10:01:26 -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 r7CGsa6C012141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 09:55:34 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CGsa6C012141 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376326535; bh=sE88zefdWP/sHdxWxOFo6TrKKqs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=idBn4Ry+McO2GKLuyQrRuUU6dN/W5OB8m6VqsVjl8FI5rZaHilYZqiK93RWD72Jzv JS/xE9cYfKBt84c4TwdiX6h7/dpcufX0cmRQTcxw8qRBJPWRfnpPfPGSsa3MDY4JQ2 cwAG6ug5bKxH3ppNiMBgMjiM3b+g/FKxGR+qDBmo= 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: <52082128.5090503@nic.br> Date: Mon, 12 Aug 2013 09:55:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> To: "Antonio M. Moreiras" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 09:55:35 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:15:57 -0000 On Aug 11, 2013, at 16:41 , Antonio M. Moreiras wrote: > On 11/08/13 19:29, Owen DeLong wrote: >> I support the idea. It might be worth also asking for a ULA Doc slice = at the same time. >> I think a /48 is probably sufficient for most ULA examples. >>=20 >> But I think it would be good to be able to write up ULA examples and = training that use >> actual ULA prefixes intended for documentation. >=20 > I agree. An organization could generate an ULA prefix specifically to > use in a course, or document. But it could be copied and used in > production environments. This would break the "global uniqueness", and > could lead to other problems. It would be nice to have a specific ULA > documentation prefix. >=20 > I would suggest a prefix with the L bit cleared, easy to remember, and > maybe slightly shorter than /48. For example FC00:0:D0C0::/44. >=20 > []s > Moreiras. That would certainly be an acceptable solution as far as I am concerned. Owen From owen@delong.com Mon Aug 12 10:17: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 AD04521F9BAB for ; Mon, 12 Aug 2013 10:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik0b67u8NMw1 for ; Mon, 12 Aug 2013 10:17:38 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 70EFC21F944C for ; Mon, 12 Aug 2013 10:06:02 -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 r7CH0Vru012281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 10:00:31 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CH0Vru012281 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376326832; bh=Gcu+TftE7zBx9nydV4TqmPL7LGU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=deLNoYr2GM2edi1+m7+qetuWlIoDQsMKm+dyG2uFxaxykzg8C7eDzcr4nKGEcuKPR urOjL6uSZ/ddvxQN+GnHCu+LBGp1tXQEV33wJHRKUe7SN0Q26tYLntYFGmUMFHq2ER hZv+lrYXNaSTnGf17PjEtAjBfvpB5Q9EEPFKCx2E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <20130812002740.34191383D34B@drugs.dv.isc.org> Date: Mon, 12 Aug 2013 10:00:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 10:00:32 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:17:39 -0000 On Aug 11, 2013, at 17:27 , Mark Andrews wrote: >=20 > In message <52082128.5090503@nic.br>, "Antonio M. Moreiras" writes: >> On 11/08/13 19:29, Owen DeLong wrote: >>> I support the idea. It might be worth also asking for a ULA Doc = slice at th >> e same time. >>> I think a /48 is probably sufficient for most ULA examples. >>>=20 >>> But I think it would be good to be able to write up ULA examples and = traini >> ng that use >>> actual ULA prefixes intended for documentation. >>=20 >> I agree. An organization could generate an ULA prefix specifically to >> use in a course, or document. But it could be copied and used in >> production environments. This would break the "global uniqueness", = and >> could lead to other problems. >=20 > FUD. >=20 Is FUD actually FUD when there is proof that it has happened before? > You either do the correct thing and generate your own prefix or you > don't and copy one and hope that no one else has copied it that you > are connecting to. Having a reserved prefix will not help you here. I disagree. See my previous message. It has helped in IPv4 and I see no reason it would not help in IPv6. It may not do much to prevent mistakes, but it makes them much easier to identify and resolve. > ULA are not "globally unique", they are locally unique with a > extrememly low probability of collision when *locally* connecting. > If you use them in a global context (i.e. publish to the world in > AAAA records) without some global differentiator you will cause > problems. Q.E.D.: route-views>sh ip bgp 10.0.0.0/8 longer-prefixes=20 BGP table version is 297146110, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - = internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.30.10.0/24 217.75.96.60 0 0 16150 31027 = 35376 i route-views>sh ip bgp 172.12.0.0/12 long route-views>sh ip bgp 172.12.0.0/12 longer-prefixes=20 BGP table version is 297170440, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - = internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 172.0.0.0/12 154.11.11.113 0 0 852 2914 = 7018 i * 208.74.64.40 0 19214 174 = 7018 i * 4.69.184.193 0 0 3356 7018 i * 194.85.102.33 0 3277 3267 = 3356 7018 i * 154.11.98.225 0 0 852 2914 = 7018 i * 207.172.6.20 0 0 6079 3356 = 7018 i * 193.0.0.56 0 3333 3356 = 7018 i * 69.31.111.244 3 0 4436 2914 = 7018 i * 66.59.190.221 0 6539 577 = 7018 i * 194.85.40.15 0 3267 3356 = 7018 i * 209.124.176.223 0 101 101 = 7018 i * 128.223.253.10 0 3582 3701 = 3356 7018 i * 207.172.6.1 0 0 6079 3356 = 7018 i * 134.222.87.1 0 286 7018 i * 157.130.10.233 0 701 7018 i * 66.185.128.48 7 0 1668 7018 i * 202.249.2.86 0 7500 2497 = 7018 i * 216.218.252.164 0 6939 1299 = 7018 i * 114.31.199.1 0 0 4826 6939 = 1299 7018 i * 144.228.241.130 0 1239 7018 i * 208.51.134.254 0 0 3549 7018 i * 207.46.32.34 0 8075 7018 i * 129.250.0.11 7 0 2914 7018 i * 217.75.96.60 0 0 16150 1299 = 7018 i * 202.232.0.2 0 2497 7018 i * 89.149.178.10 10 0 3257 7018 i * 66.110.0.86 0 6453 7018 i * 203.62.252.186 0 1221 4637 = 3561 7018 i * 203.181.248.168 0 7660 2516 = 3356 7018 i * 164.128.32.11 0 3303 3320 = 7018 i * 206.24.210.102 0 3561 7018 i *> 12.0.1.63 0 7018 i route-views>sh ip bgp 192.168.0.0/16 lon route-views>sh ip bgp 192.168.0.0/16 longer-prefixes=20 route-views> >=20 > All a documentation prefix will do is have one potentially toxic > prefix compared to a handful of potentially toxic prefixes. There > are 1099511627776 prefixes in fd00::/8. Even if there were thousands > of documentation prefixes the odds of you hitting one when generating > your own prefix are astronomically small. Additionally the more > prefixes that are used in documentation the less toxic a particular > prefix will be. No, it will also help to constrain such errors to an easily identifiable = single prefix which will make the errors easier to identify and correct. This = is, IMHO, a worth while goal in the real world where operators actually run = networks and have to deal with less than ideally trained predecessors and = colleagues. Owen From fred@cisco.com Mon Aug 12 10:22:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE3F21F84A8 for ; Mon, 12 Aug 2013 10:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=-0.482, 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 CTBcqq07+Sps for ; Mon, 12 Aug 2013 10:22:27 -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 955F021F944C for ; Mon, 12 Aug 2013 10:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2848; q=dns/txt; s=iport; t=1376327860; x=1377537460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S69C+AdxUs0uJTJskNZJtf3YHg/IN26WKoD0FIcfeu8=; b=U9SSNFvEbFAwVlCYit5AbrS6TGDMcr8ljRAArufrq2DVe4RdXbJXGFyl tVRsnnVAi8te6SgYS9CeD7gYDnXDzpjRou2nO19JsMDWT/n57F1VUB1/B wK0jsTiRYkvMG61I4KY9+bipQ1+5sc2CrcYPvANufJzBAcHG3VV77r8BS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALIXCVKtJV2a/2dsb2JhbABbgwY1UL5UgRoWdIIkAQEBAwEBAQE3NAsFCwIBCCIUECcLJQIEDgUIAYgBBgy2YZAIAjEHgxt2A5kQkCWDG4Iq X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208";a="246440030" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 12 Aug 2013 17:17:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7CHHdH9013858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 17:17:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 12:17:39 -0500 From: "Fred Baker (fred)" To: "Antonio M. Moreiras" Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: AQHOl3/Ycww6z2JuGk6Yd/lgbySy6Q== Date: Mon, 12 Aug 2013 17:17:39 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> In-Reply-To: <5207E319.6070601@nic.br> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <434EAAB0F34D9947B79103E8920D4766@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alejandro Acosta , "" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:22:32 -0000 Speaking as a chair, I don't have a problem with it being discussed in v6op= s, but I think the issue belongs in 6man by charter. Speaking as a document author (think of RFCs 6052, 6144, 6145, 6146, and 61= 47, which I helped edit or write), I'm not sure I have ever had a case in w= hich a /32 was not enough. I might, for example, need to use layers of pref= ixes like 2001:db8::/32 2001:db8:100::/40 2001:db8:202::/48 2001:db8:300:300::/56 2001:db8:400:440::/60 2001:db8:400:444::/64 but I seem to have plenty of layers at my disposal. I'd be interested to un= derstand the cases in which you find yourself cramped? On Aug 11, 2013, at 12:16 PM, Antonio M. Moreiras wrote: > Hi. >=20 > I would like to ask you to please review and comment the following draft: >=20 > http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 >=20 > It intends to ask IANA to reserve another IPv6 prefix for documentation. > Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago. >=20 > The prefix 2001:db8::/32 showed to be very useful. It is widely used. > But we are still facing the same problem that RFC 3849 tried to address: > in some kind of documents, tutorials and didactic laboratories, we have > been using other prefixes, because a /32 isn't enough to represent the > scenario. >=20 > We consider that a /20 would be enough. >=20 > If possible, we would like to ask IANA to reserve something easy to > remember, and self explaining, such as: >=20 > 2D0C::/20 >=20 > but *this suggestion is not stated in the document*. This prefix is from > the global unicast space, and 2d00::/8 is currently marked as reserved > by IANA [1], so it would be possible. Anyway, we think it would be > better to discuss the question in the mailing-list. >=20 > Reviewing the archives from when draft-huston-ipv6-documentation-prefix > (that became RFC 3849) was being discussed, both questions (the > necessity of a larger prefix, or multiple prefixes, and the possibility > to reserve something easier to remember and self explaining) were > raised. I am not sure why none of them led to something concrete. > Probably because the draft just intended to document an allocation > already made by APNIC, and maybe it was not so clear then how useful it > would be. >=20 > If you agree in principle with the proposal, other point to discuss is > if this subject is compatible with v6ops. Maybe it should be addressed > in 6man, or other place. >=20 > Thanks. > Moreiras. >=20 > [1] > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-uni= cast-address-assignments.xhtml >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Mon Aug 12 10:25: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 A3BEC21F9BCA for ; Mon, 12 Aug 2013 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ekk+bl22AKyr for ; Mon, 12 Aug 2013 10:25:49 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5E121F8616 for ; Mon, 12 Aug 2013 10:22:15 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7CHGfmN012709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 10:16:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CHGfmN012709 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376327801; bh=f+KT3F2yil1wT7j3EH+MSk9cQYw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Vlb5/JBCyF9c1OfEOw4+0uGg++IJJ5Cpq9W+eyokL+ceFuhMBVsVNvO7y+fFWkFYx p7mQo2iTYh/e2xmvVIrmktAsBWxxl8Tf3in8mE2o/qujUKn/xvDI3Vnxhz1nAjTVBS 8s21LyV/+RRj1GYhG/xxnm8wrKe7B5FcXQP5xinc= Content-Type: multipart/alternative; boundary="Apple-Mail=_B2122261-0D1B-4650-A7C8-5B87F2BAB021" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: Date: Mon, 12 Aug 2013 10:16:43 -0700 Message-Id: <875AA51D-5AFF-4378-80F9-E3FF5FA0491A@delong.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> To: "Arie Vayner (avayner)" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 10:16:41 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:25:51 -0000 --Apple-Mail=_B2122261-0D1B-4650-A7C8-5B87F2BAB021 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Not necessarily. You are thinking of moving them physically closer. I'm = suggesting moving them topologically closer. Imagine that the WN links are not private, but instead are public. Each = site doesn't necessarily have a firewall, but it does need a VPN device = (good practice anyway, since you can't trust your WAN links to be truly = private[1]). These VPN gateways would have some level of mesh (ideally = matching the phsyical topology relatively closely) to link the internal = networks at all the sites over the WAN links. At that point, the = firewalls may be physically at any or all of the internet gateway = locations, but may serve different subsets of users or may be = partitioned into virtual firewalls that are connected to different = subsets of the internal network that travel through different VPNs, etc. There are many ways to virtualize and abstract topology in order to = enable this without necessarily increasing or moving physical hardware. Owen On Aug 11, 2013, at 22:27 , "Arie Vayner (avayner)" = wrote: > Owen, > =20 > While the arguments about moving the firewalls closer to the users are = valid they are often are not practical (or at least the customers I = worked with would not implement this option). > Imagine an enterprise network with 300 spoke sites, but only 2 or 3 = Internet gateway locations (with some private WAN in between). > Moving the firewalls to the spoke sites would increase the number of = firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a = second)=85 This is a major CAPEX and OPEX impact=85 > =20 > Arie > =20 > From: Owen DeLong [mailto:owen@delong.com]=20 > Sent: Friday, August 9, 2013 12:17 PM > To: Arie Vayner (avayner) > Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); = v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC > =20 > =20 > On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) = wrote: >=20 >=20 > Another loosely related point that I think could make sense in such a = document would be the ways to accomplish multi-homing and how it is = different than today=92s IPv4 implementations. > =20 > Many enterprises rely on NAT on the Internet edge as their = multi-homing/traffic engineering mechanism with IPv4. > =20 > If we recommend against ULA+NPTv6 (or just NPTv6 for traffic = engineering), then we need to highlight the symmetry requirement due to = stateful security layers. > Traffic leaving from an Internet gateway site to the Internet has to = come back through the same site, or the stateful firewalls would break = the flow (well, has to hit the same stateful security layer) > =20 > Or stateful firewalls have to get better about sharing state. There = are two things that can help with this... > =20 > 1. Put your firewalls as close to the end systems they protect = as possible. Make your security zones relatively small and place the = firewalls closer together at those narrower borders. > This will often require more firewall units, but it helps = in a number of ways: > A. Firewall policy tends to be much simpler (and as = a result less error prone and more reliable) > B. The hardware demands on the firewall tend to be = lower so you can buy cheaper units. > C. The simpler rulesets can be more easily tailored = to meet business requirements as they evolve. > =20 > =20 > =20 > 2. Improve firewalls. Give the firewalls that all protect the = same boundary a way to mesh-peer with each other and exchange = information about the state tables such that triangle routing is no = longer problematic. >=20 >=20 > Syncing upstream and downstream routing policies is not always an easy = task (but could be relevant in some cases). > Linking the Internet gateway layer across sites (before hitting the = stateful security layer) could be another solution. > =20 > If we make the changes above to the firewalls, this could be a lot = less relevant in most cases. >=20 >=20 > Do you think a short discussion to raise awareness for this potential = issue could be relevant in such a document? > =20 > It's certainly worth documenting. I'm not sure whether it belongs in = this document or not. > =20 > Owen > =20 --Apple-Mail=_B2122261-0D1B-4650-A7C8-5B87F2BAB021 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Not = necessarily. You are thinking of moving them physically closer. I'm = suggesting moving them topologically closer.

Imagine = that the WN links are not private, but instead are public. Each site = doesn't necessarily have a firewall, but it does need a VPN device (good = practice anyway, since you can't trust your WAN links to be truly = private[1]). These VPN gateways would have some level of mesh (ideally = matching the phsyical topology relatively closely) to link the internal = networks at all the sites over the WAN links. At that point, the = firewalls may be physically at any or all of the internet gateway = locations, but may serve different subsets of users or may be = partitioned into virtual firewalls that are connected to different = subsets of the internal network that travel through different VPNs, = etc.

There are many ways to virtualize and = abstract topology in order to enable this without necessarily increasing = or moving physical = hardware.

Owen

On Aug = 11, 2013, at 22:27 , "Arie Vayner (avayner)" <avayner@cisco.com> = wrote:

 
While the arguments about moving the = firewalls closer to the users are valid they are often are not practical = (or at least the customers I worked with would not implement this = option).
Imagine an enterprise network with 300 spoke sites, = but only 2 or 3 Internet gateway locations (with some private WAN in = between).
Moving the firewalls to the spoke sites would = increase the number of firewalls from ~3 to ~300 (I am ignoring = redundancy and scale for a second)=85 This is a major CAPEX and OPEX = impact=85
 
Arie
From: Owen DeLong [mailto:owen@delong.com] 
Sent: Friday, August 9, 2013 = 12:17 PM
To: Arie Vayner = (avayner)
Cc: Eric Vyncke (evyncke); = Lorenzo Colitti; Fred Baker (fred); v6ops@ietf.org
Subject: Re: [v6ops] = draft-ietf-v6ops-enterprise-incremental-ipv6 = WGLC
On = Aug 8, 2013, at 22:21 , Arie Vayner (avayner) <avayner@cisco.com> = wrote:
Another loosely related point that I think could = make sense in such a document would be the ways to accomplish = multi-homing and how it is different than today=92s IPv4 = implementations.
Many enterprises rely on NAT on the Internet = edge as their multi-homing/traffic engineering mechanism with = IPv4.
 
If we recommend against = ULA+NPTv6 (or just NPTv6 for traffic engineering), then we need to = highlight the symmetry requirement due to stateful security = layers.
Traffic leaving from an Internet gateway site = to the Internet has to come back through the same site, or the stateful = firewalls would break the flow (well, has to hit the same stateful = security layer)
 
Or stateful firewalls have to get better about sharing state. = There are two things that can help with = this...
        <= span class=3D"Apple-converted-space"> Put your = firewalls as close to the end systems they protect as possible. Make = your security zones relatively small and place the firewalls closer = together at those narrower borders.
        &= nbsp;   This will often = require more firewall units, but it helps in a number of = ways:
        &= nbsp;   A.        Firewall policy = tends to be much simpler (and as a result less error prone and more = reliable)
        &= nbsp;   B.        The hardware demands = on the firewall tend to be lower so you can buy cheaper = units.
        &= nbsp;   C.        The simpler rulesets = can be more easily tailored to meet business requirements as they = evolve.
 
 
 
2.        <= span class=3D"Apple-converted-space"> Improve = firewalls. Give the firewalls that all protect the same boundary a way = to mesh-peer with each other and exchange information about the state = tables such that triangle routing is no longer = problematic.
Syncing upstream and downstream routing policies is = not always an easy task (but could be relevant in some = cases).
Linking the Internet gateway layer across = sites (before hitting the stateful security layer) could be another = solution.
 
If we make the changes above to the firewalls, this could be =  a lot less relevant in most cases.


Do you think a short discussion = to raise awareness for this potential issue could be relevant in such a = document?
 
It's = certainly worth documenting. I'm not sure whether it belongs in this = document or not.


= --Apple-Mail=_B2122261-0D1B-4650-A7C8-5B87F2BAB021-- From avayner@cisco.com Mon Aug 12 10: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 EBDE321F8C11 for ; Mon, 12 Aug 2013 10:37:36 -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=[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 VjMZpkB8Dh-N for ; Mon, 12 Aug 2013 10:37:31 -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 9187A21F9956 for ; Mon, 12 Aug 2013 10:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8307; q=dns/txt; s=iport; t=1376328878; x=1377538478; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ll6bpXndl1N7U0WZnZJIHvL2pniO/OBuaByV4zo/A+A=; b=P9kHbenErVLQ9c/jZ1QUQaM2wHd3ajq87k5tpVv1sS/FpVvllDNK2taA TQQBWkRAggrf4NWLKfZlmUAc8mfIVJw/0ZrpZkCwQ8PRBBGZ5uCj72lFN IT8oDJZf5AV3JmT06oAuT1hz31BwlL15C9JxFEJGBQZempuGPDMn6O0L4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAKobCVKtJV2d/2dsb2JhbABbgkJENVC+VIEaFnSCJAEBAQQtTBACAQgRBAEBCx0HMhQJCAIEDgUIiAi2X5AKMQYBgxt2A6k1gxuCKg X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208,217";a="246361299" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2013 17:34:32 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7CHYVHY027210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 17:34:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 12:34:31 -0500 From: "Arie Vayner (avayner)" To: Lorenzo Colitti Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkTyDDMSxdUYJukeaGavK35KXPJmGm1kAgACKQoCAAF43gIAAFCCAgAArgQCAAkwdAIACTLxQgAUQVYCAAHTskA== Date: Mon, 12 Aug 2013 17:34:31 +0000 Message-ID: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.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.21.127.133] Content-Type: multipart/alternative; boundary="_000_CA6D42D0F8A41948AEB3864480C554F104AEB134xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:37:37 -0000 --_000_CA6D42D0F8A41948AEB3864480C554F104AEB134xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, you can use NPTv6 to protect against it... If I have an external pool per site, traffic egressing that site would get = a source routed back only to that site... Am I missing something? I agree there could be other ways to solve it, but this is how many enterpr= ises solve it today with IPv4... Arie From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Sunday, August 11, 2013 22:35 PM To: Arie Vayner (avayner) Cc: Eric Vyncke (evyncke); Fred Baker (fred); v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner) > wrote: Many enterprises rely on NAT on the Internet edge as their multi-homing/tra= ffic engineering mechanism with IPv4. If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), = then we need to highlight the symmetry requirement due to stateful security= layers. Traffic leaving from an Internet gateway site to the Internet has to come b= ack through the same site, or the stateful firewalls would break the flow (= well, has to hit the same stateful security layer) By itself, NPTv6 doesn't protect against this problem because it's not stat= eful. It only protects against this problem if each egress point is only re= achable using one prefix (which is not a requirement for doing NPTv6 - you = could just as well do it by configuring all multiple exit points to use the= same prefix, or to use all prefixes from all exit points). What does protect you against this is using source+destination routing, whi= ch is what this draft should recommend instead of recommending NPTv6. --_000_CA6D42D0F8A41948AEB3864480C554F104AEB134xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, you can use NPT= v6 to protect against it…

If I have an external poo= l per site, traffic egressing that site would get a source routed back only= to that site… Am I missing something?

 <= /p>

I agree there could be ot= her ways to solve it, but this is how many enterprises solve it today with = IPv4…

 <= /p>

Arie

 <= /p>

From: Lorenz= o Colitti [mailto:lorenzo@google.com]
Sent: Sunday, August 11, 2013 22:35 PM
To: Arie Vayner (avayner)
Cc: Eric Vyncke (evyncke); Fred Baker (fred); v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WG= LC

 

On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner= ) <avayner@cisco.= com> wrote:

Many enterprises rely on NAT on the Int= ernet edge as their multi-homing/traffic engineering mechanism with IPv4.

 

If we recommend against ULA+NPTv6 (= or just NPTv6 for traffic engineering), then we need to highlight the symmetry requirement due to stateful security layers.

Traffic leaving from an Internet gatewa= y site to the Internet has to come back through the same site, or the stateful firewalls would break the flow (well, has to hit the same = stateful security layer)

 

By itself, NPTv6 doesn't protect against this proble= m because it's not stateful. It only protects against this problem if each = egress point is only reachable using one prefix (which is not a requirement= for doing NPTv6 - you could just as well do it by configuring all multiple exit points to use the same pref= ix, or to use all prefixes from all exit points).

 

What does protect you against this is using source&#= 43;destination routing, which is what this draft should recommend instead o= f recommending NPTv6.

--_000_CA6D42D0F8A41948AEB3864480C554F104AEB134xmbrcdx10ciscoc_-- From bill.jouris@insidethestack.com Mon Aug 12 10:57: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 B3B5A21F9DA0 for ; Mon, 12 Aug 2013 10:57: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 KhecwdcuIC79 for ; Mon, 12 Aug 2013 10:57:30 -0700 (PDT) Received: from nm20-vm1.access.bullet.mail.gq1.yahoo.com (nm20-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF0AE21F9D9C for ; Mon, 12 Aug 2013 10:57:29 -0700 (PDT) Received: from [216.39.60.166] by nm20.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Aug 2013 17:57:28 -0000 Received: from [216.39.60.233] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Aug 2013 17:57:28 -0000 Received: from [127.0.0.1] by omp1004.access.mail.gq1.yahoo.com with NNFMP; 12 Aug 2013 17:57:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 571958.69624.bm@omp1004.access.mail.gq1.yahoo.com Received: (qmail 41924 invoked by uid 60001); 12 Aug 2013 17:57:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376330248; bh=9bNouxr1EBG1ffNUfjoJrjyUC03zATL8+ujltBcm/y4=; 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=h6q9Xx4/ckOyWrKGryQiwtMk7Gfd3ZiB8n/CjTkeeq5d/48DpEVN7yCJ0JIZbJl5BiUoKZabZRoxTxQ3mWkkQ6RtfcUn63WAIALhtn5zkBm9MfdLK8T8yulhVq/j3euScOD8QLaNPnDd6QXXt6KacoBb949Z9pDA9X3upSUsAeU= X-YMail-OSG: eRB2GcoVM1ke3fJTBF2nDD3K9a0DvTNwSJTqpW9oSCmtG.I mG__WruVIeog2wG9E4gqTtmjrpyRK8BpAxqDvZ.w2zvZJwXDT8_nf37fF7OU BZe45HwkWL.X59sGcu7r7yNv97HzfWZ3u_W3rpOgBOPWt4o1XtFtVuajHELj VC2JBhFzRca8iPAfkuM1ONqqniK7gW_5QzJ2P37BlTkI0fPpM5js3IMkfhg7 nPHf.YRxfKA5DZmVwKjYMY9O2jP37R5YTAkFTzqaR479VWJoRBbizDiROmRI 93ifnjoUKBKkmYgq.xE_Qh5u6WcjD.LZLsARIKVMr2iDLgGFcxqCwuk6Mjha BaizJ0s897F9Mf6NUJQUKUdfFz.QO1GfoDkA0m88erU3ZPipTpoEEt4OK89S dK1yGIn.gotgiVnWK3HKwyBYu0806ob8NbFDvaZcwlgtNqbqXBRDFTlcDgLD eQlppIfrVA4hMG31GDrXcgooKYlvZTGDvLQHYHrmQ.riYqDZ4mdCvIZVh1cu 7s07fY0qEbaVQUdevMXquGt7VXNbMMtz5TjV1BD9eblWvdP3vC.F7RF.T0mT ZTC8JKp6WNNUAjE4Di_rzF7ITJunMgMOdW9uTS4J405dzzQWuRhkE5taQIF8 daDIug4WxvUGKTNPWu8hfeGPU3RYZeYIxPAVkpCN1Fe5UV3LXxWiFjNk- Received: from [50.143.174.186] by web2806.biz.mail.ne1.yahoo.com via HTTP; Mon, 12 Aug 2013 10:57:27 PDT X-Rocket-MIMEInfo: 002.001, PiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBNYXJrIEFuZHJld3MgPG1hcmthQGlzYy5vcmc.IAo.IENjOiBBbGVqYW5kcm8gQWNvc3RhIDxhYWNvc3RhQHJvY2tldG1haWwuY29tPjsgdjZvcHNAaWV0Zi5vcmcgCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTIsIDIwMTMgMTA6MDAgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1tb3JlaXJhcy12Nm9wcy1yZmMzODQ5YmlzLTAwCiAKPgo.PiAKPj4gQWxsIGEgZG9jdW1lbnRhdGlvbiBwcmVmaXggd2lsbCBkbyBpcyBoYXYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> Message-ID: <1376330247.41781.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Mon, 12 Aug 2013 10:57:27 -0700 (PDT) From: Bill Jouris To: Owen DeLong In-Reply-To: <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1351415829-1376330247=:41781" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 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: Mon, 12 Aug 2013 17:57:36 -0000 --1510626085-1351415829-1376330247=:41781 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > From: Owen DeLong =0A> To: Mark Andrews = =0A> Cc: Alejandro Acosta ; v6ops@ietf.org =0A> Sen= t: Monday, August 12, 2013 10:00 AM=0A> Subject: Re: [v6ops] draft-moreiras= -v6ops-rfc3849bis-00=0A =0A>=0A>> =0A>> All a documentation prefix will do = is have one potentially toxic=0A>> prefix compared to a handful of potentia= lly toxic prefixes.=A0 There=0A>> are 1099511627776 prefixes in fd00::/8.= =A0 Even if there were thousands=0A>> of documentation prefixes the odds of= you hitting one when generating=0A>> your own prefix are astronomically sm= all.=A0 Additionally the more=0A>> prefixes that are used in documentation = the less toxic a particular=0A>> prefix will be.=0A=0A> No, it will also he= lp to constrain such errors to an easily identifiable single=0A> prefix whi= ch will make the errors easier to identify and correct. This is, IMHO,=0A> = a worth while goal in the real world where operators actually run networks= =0A> and have to deal with less than ideally trained predecessors and colle= agues.=0A>=0A> Owen=0A=0AOne other thing: if you have a single documentatio= n prefix, you can actually build that knowledge into your firewalls and rou= ters -- meaning that anyone who does a copy without change will immediately= find that his addresses simply don't work.=A0 Making that particular error= essentially self-correcting,=0A=0ABill Jouris=0AInside Products, Inc.=0Aww= w.insidethestack.com=0A831-659-8360=0A925-855-9512 (direct)=0A --1510626085-1351415829-1376330247=:41781 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> From:= Owen DeLong <owen@delong.com>
> To: Mark Andrews <marka@isc.org>
<= b>> Cc: Alejandro Acosta &= lt;aacosta@rocketmail.com>; v6ops@ietf.org
> Sent: Monday, August 12, 2013 10:00 AM
> Subject: Re: [v6ops] dr= aft-moreiras-v6ops-rfc3849bis-00
>
>>
>> All a documentation prefix will do is= have one potentially toxic
>> prefix compared to a handful of potentially = toxic prefixes.  There
>> are 1099511627776 prefixes in fd00:= :/8.  Even if there were thousands
>> of documentation prefix= es the odds of you hitting one when generating
>> your own prefix = are astronomically small.  Additionally the more
>> prefixes = that are used in documentation the less toxic a particular
>> pref= ix will be.

> No, it will also help to constrain such errors to a= n easily identifiable single
> prefix which will make the errors easi= er to identify and correct. This is, IMHO,
> a worth while goal in th= e real world where operators actually run networks
> and have to deal= with less than ideally trained predecessors and colleagues.
>
>= ; Owen

One other thing: if you have a single documentation prefix, y= ou can actually build that knowledge into your firewalls and routers -- meaning that anyone who does a copy without change will immediately fin= d that his addresses simply don't work.  Making that particular error = essentially self-correcting,

Bill Jouris
= Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direc= t)
--1510626085-1351415829-1376330247=:41781-- From owen@delong.com Mon Aug 12 11:36:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784E121F9EA3 for ; Mon, 12 Aug 2013 11:36: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 JT8wz+GNW19C for ; Mon, 12 Aug 2013 11:36:44 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA921F9E8B for ; Mon, 12 Aug 2013 11:36:40 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7CIVDb9014741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 11:31:14 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CIVDb9014741 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376332275; bh=jyCehuZiIAWMD4l6BVWEQWXjKKQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fwLpuJ8iGUgEf3oTnnuTANSODdOXmoHj+6VBR2hGA8PNzFYELZkhhN/cFPRi2fkBy nvQPL8xrgAORmw8MDhyP84xtf70WJvgK3YGEgm8cJpDd3fC7KinQxaDkPNI3lDudeo 97fRusVohQL8+7hW3VHqB10VlQTMvd1vlKBbKDEo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> Date: Mon, 12 Aug 2013 11:31:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> To: "Fred Baker (fred)" 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]); Mon, 12 Aug 2013 11:31:15 -0700 (PDT) Cc: Alejandro Acosta , "" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 18:36:45 -0000 If you are trying to demonstrate or teach peerings across multiple ASNs = and show examples of how multiple ISPs might carve up their /32s (or = larger) differently, it's very hard to do all of that within a single = /32. Antonio and I do very similar types of training from the sounds of it = and we have encountered the same issues. A larger doc prefix would be useful. I don't see it as critical, but I = don't see any significant reason not to do so. I understand the = objection raised by Cameron, but, really, anything the IETF does likely = creates some amount of work for operators. Thus is the nature of = operating a network built on an evolving technology. You knew the job = was dangerous when you took it. Owen On Aug 12, 2013, at 10:17 , "Fred Baker (fred)" wrote: > Speaking as a chair, I don't have a problem with it being discussed in = v6ops, but I think the issue belongs in 6man by charter. >=20 > Speaking as a document author (think of RFCs 6052, 6144, 6145, 6146, = and 6147, which I helped edit or write), I'm not sure I have ever had a = case in which a /32 was not enough. I might, for example, need to use = layers of prefixes like > 2001:db8::/32 > 2001:db8:100::/40 > 2001:db8:202::/48 > 2001:db8:300:300::/56 > 2001:db8:400:440::/60 > 2001:db8:400:444::/64 > but I seem to have plenty of layers at my disposal. I'd be interested = to understand the cases in which you find yourself cramped? >=20 > On Aug 11, 2013, at 12:16 PM, Antonio M. Moreiras = wrote: >=20 >> Hi. >>=20 >> I would like to ask you to please review and comment the following = draft: >>=20 >> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 >>=20 >> It intends to ask IANA to reserve another IPv6 prefix for = documentation. >> Something larger than the 2001:db8::/32, reserved by APNIC 10 years = ago. >>=20 >> The prefix 2001:db8::/32 showed to be very useful. It is widely used. >> But we are still facing the same problem that RFC 3849 tried to = address: >> in some kind of documents, tutorials and didactic laboratories, we = have >> been using other prefixes, because a /32 isn't enough to represent = the >> scenario. >>=20 >> We consider that a /20 would be enough. >>=20 >> If possible, we would like to ask IANA to reserve something easy to >> remember, and self explaining, such as: >>=20 >> 2D0C::/20 >>=20 >> but *this suggestion is not stated in the document*. This prefix is = from >> the global unicast space, and 2d00::/8 is currently marked as = reserved >> by IANA [1], so it would be possible. Anyway, we think it would be >> better to discuss the question in the mailing-list. >>=20 >> Reviewing the archives from when = draft-huston-ipv6-documentation-prefix >> (that became RFC 3849) was being discussed, both questions (the >> necessity of a larger prefix, or multiple prefixes, and the = possibility >> to reserve something easier to remember and self explaining) were >> raised. I am not sure why none of them led to something concrete. >> Probably because the draft just intended to document an allocation >> already made by APNIC, and maybe it was not so clear then how useful = it >> would be. >>=20 >> If you agree in principle with the proposal, other point to discuss = is >> if this subject is compatible with v6ops. Maybe it should be = addressed >> in 6man, or other place. >>=20 >> Thanks. >> Moreiras. >>=20 >> [1] >> = http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic= ast-address-assignments.xhtml >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From carlosm3011@gmail.com Mon Aug 12 12:30: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 2626F21F99A1 for ; Mon, 12 Aug 2013 12:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 OKd4AQIx+DOk for ; Mon, 12 Aug 2013 12:30:13 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A743921F997D for ; Mon, 12 Aug 2013 12:30:12 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id t13so5098460lbd.2 for ; Mon, 12 Aug 2013 12:30:11 -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:date:message-id :subject:from:to:cc:content-type; bh=JG7/PKZ2HLF+pmP5X5ZQvi5iHUUzgkIrdivoJjENxQo=; b=cV89Q+AJ8SNx04fmph9uUF47P2FfsuNnl9MDw1JIo3Ijsr0+o18yHa1zPiLEIi9mih xQ+xz70LUNsrqwAqe3QM+ok9HOCi2mxuEIzOvKHp5EYWH8c4aDzMwfutv6cfZUHi0SwJ AMZp2/Y79Hr7UOmD6LrupnJwwinI8/WaECECm/aDGHu3zSLpddw7iJIGshFASgdz9fx4 OA1385zAl1NfXbmdmUC11A4z0VsxZa81mBgGOuQiaJd8DZbZvXub34fJ13zcbZNB5bec TzGlmKEutgNNFB1WK5iFWfblY520eELKhfEE9KVnJ5buA6xqDnXDAy2mDintt0TKpHy4 45AA== MIME-Version: 1.0 X-Received: by 10.152.22.65 with SMTP id b1mr176786laf.46.1376335811380; Mon, 12 Aug 2013 12:30:11 -0700 (PDT) Received: by 10.112.168.225 with HTTP; Mon, 12 Aug 2013 12:30:11 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> Date: Mon, 12 Aug 2013 16:30:11 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e0158b92a210b5704e3c527a1 Cc: Alejandro Acosta , "" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:30:14 -0000 --089e0158b92a210b5704e3c527a1 Content-Type: text/plain; charset=ISO-8859-1 As far as I understand, Antonio does some training involving 6RD deployments, where each 'team' needs its own /32. There might be other cases though, like for example doing some work involving BGP routing between different teams and for which you expect each one of them to carve a /32. For an IPv6 veteran, carving a /32 is no different from carving a /48 or carving a /64 into smaller chunks. However, for newbies it just doesn't work. Sure, each could work on 2001:db8, but then if you want to implement such a plan on a live lab, you have a problem. cheers, ~Carlos On Mon, Aug 12, 2013 at 2:17 PM, Fred Baker (fred) wrote: > Speaking as a chair, I don't have a problem with it being discussed in > v6ops, but I think the issue belongs in 6man by charter. > > Speaking as a document author (think of RFCs 6052, 6144, 6145, 6146, and > 6147, which I helped edit or write), I'm not sure I have ever had a case in > which a /32 was not enough. I might, for example, need to use layers of > prefixes like > 2001:db8::/32 > 2001:db8:100::/40 > 2001:db8:202::/48 > 2001:db8:300:300::/56 > 2001:db8:400:440::/60 > 2001:db8:400:444::/64 > but I seem to have plenty of layers at my disposal. I'd be interested to > understand the cases in which you find yourself cramped? > > On Aug 11, 2013, at 12:16 PM, Antonio M. Moreiras wrote: > > > Hi. > > > > I would like to ask you to please review and comment the following draft: > > > > http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 > > > > It intends to ask IANA to reserve another IPv6 prefix for documentation. > > Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago. > > > > The prefix 2001:db8::/32 showed to be very useful. It is widely used. > > But we are still facing the same problem that RFC 3849 tried to address: > > in some kind of documents, tutorials and didactic laboratories, we have > > been using other prefixes, because a /32 isn't enough to represent the > > scenario. > > > > We consider that a /20 would be enough. > > > > If possible, we would like to ask IANA to reserve something easy to > > remember, and self explaining, such as: > > > > 2D0C::/20 > > > > but *this suggestion is not stated in the document*. This prefix is from > > the global unicast space, and 2d00::/8 is currently marked as reserved > > by IANA [1], so it would be possible. Anyway, we think it would be > > better to discuss the question in the mailing-list. > > > > Reviewing the archives from when draft-huston-ipv6-documentation-prefix > > (that became RFC 3849) was being discussed, both questions (the > > necessity of a larger prefix, or multiple prefixes, and the possibility > > to reserve something easier to remember and self explaining) were > > raised. I am not sure why none of them led to something concrete. > > Probably because the draft just intended to document an allocation > > already made by APNIC, and maybe it was not so clear then how useful it > > would be. > > > > If you agree in principle with the proposal, other point to discuss is > > if this subject is compatible with v6ops. Maybe it should be addressed > > in 6man, or other place. > > > > Thanks. > > Moreiras. > > > > [1] > > > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml > > > > > > _______________________________________________ > > 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 > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= --089e0158b92a210b5704e3c527a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As far as I understand, Antonio does some training involvi= ng 6RD deployments, where each 'team' needs its own /32. There migh= t be other cases though, like for example doing some work involving BGP rou= ting between different teams and for which you expect each one of them to c= arve a /32.

For an IPv6 veteran, carving a /32 is no different from carv= ing a /48 or carving a /64 into smaller chunks. However, for newbies it jus= t doesn't work. Sure, each could work on 2001:db8, but then if you want= to implement such a plan on a live lab, you have a problem.

cheers,

~Carlos


On Mon, Aug 12, = 2013 at 2:17 PM, Fred Baker (fred) <fred@cisco.com> wrote:
Speaking as a chair, I don't have a prob= lem with it being discussed in v6ops, but I think the issue belongs in 6man= by charter.

Speaking as a document author (think of RFCs 6052, 6144, 6145, 6146, and 61= 47, which I helped edit or write), I'm not sure I have ever had a case = in which a /32 was not enough. I might, for example, need to use layers of = prefixes like
=A0 =A0 2001:db8::/32
=A0 =A0 2001:db8:100::/40
=A0 =A0 2001:db8:202::/48
=A0 =A0 2001:db8:300:300::/56
=A0 =A0 2001:db8:400:440::/60
=A0 =A0 2001:db8:400:444::/64
but I seem to have plenty of layers at my disposal. I'd be interested t= o understand the cases in which you find yourself cramped?

On Aug 11, 2013, at 12:16 PM, Antonio M. Moreiras <moreiras@nic.br> wrote:

> Hi.
>
> I would like to ask you to please review and comment the following dra= ft:
>
> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc38= 49bis-00
>
> It intends to ask IANA to reserve another IPv6 prefix for documentatio= n.
> Something larger than the 2001:db8::/32, reserved by APNIC 10 years ag= o.
>
> The prefix 2001:db8::/32 showed to be very useful. It is widely used.<= br> > But we are still facing the same problem that RFC 3849 tried to addres= s:
> in some kind of documents, tutorials and didactic laboratories, we hav= e
> been using other prefixes, because a /32 isn't enough to represent= the
> scenario.
>
> We consider that a /20 would be enough.
>
> If possible, we would like to ask IANA to reserve something easy to > remember, and self explaining, such as:
>
> 2D0C::/20
>
> but *this suggestion is not stated in the document*. This prefix is fr= om
> the global unicast space, and 2d00::/8 is currently marked as reserved=
> by IANA [1], so it would be possible. Anyway, we think it would be
> better to discuss the question in the mailing-list.
>
> Reviewing the archives from when draft-huston-ipv6-documentation-prefi= x
> (that became RFC 3849) was being discussed, both questions (the
> necessity of a larger prefix, or multiple prefixes, and the possibilit= y
> to reserve something easier to remember and self explaining) were
> raised. I am not sure why none of them led to something concrete.
> Probably because the draft just intended to document an allocation
> already made by APNIC, and maybe it was not so clear then how useful i= t
> would be.
>
> If you agree in principle with the proposal, other point to discuss is=
> if this subject is compatible with v6ops. Maybe it should be addressed=
> in 6man, or other place.
>
> Thanks.
> Moreiras.
>
> [1]
> http://www.= iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-= assignments.xhtml
>
>
> _______________________________________________
> 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



--
=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--089e0158b92a210b5704e3c527a1-- From carlosm3011@gmail.com Mon Aug 12 12:58:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DBD21F9D7E for ; Mon, 12 Aug 2013 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 LtPpsL8uSEn0 for ; Mon, 12 Aug 2013 12:58:13 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B90AD21F9D5A for ; Mon, 12 Aug 2013 12:58:12 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eo20so5021355lab.6 for ; Mon, 12 Aug 2013 12:58:11 -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:date:message-id :subject:from:to:cc:content-type; bh=ea6wIOL2JQ4CV/QqaF2Mepc/LKpW/gTdOEid3li8InA=; b=Q1zexgaXEUeHZUjZvEZ/Wrd8+R22b+w2dfyca4W5p2r9/HeWdOxUKz7ZKF/JfxjZE4 NFIzD94Jv6KlN1o5af1cSLVSe8jx5qW/F2bOr/KTIaZH9zOfuDkef5cLEy6E86j9GwMN 813PfZgaKFJg6oM20pB4GKRQhr5HMk8FeP5kso6HHqwtGqaDnP0DxmSbRbJrZZp6i2St C4raVLL57M7idlGDVbNEu2iGW+WdmPL34U8UPvJUO84rI2vvGT7BIQSd6H6wHJYRl/7o sdBqUDYSBuIhu4aHAiyUYbc00waYyI6DIYyjroKhSSvGaAixqWsEi3Pp+perUVwJgoT0 f32g== MIME-Version: 1.0 X-Received: by 10.112.35.225 with SMTP id l1mr418304lbj.37.1376337491524; Mon, 12 Aug 2013 12:58:11 -0700 (PDT) Received: by 10.112.168.225 with HTTP; Mon, 12 Aug 2013 12:58:11 -0700 (PDT) In-Reply-To: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> Date: Mon, 12 Aug 2013 16:58:11 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: Alejandro Acosta Content-Type: multipart/alternative; boundary=001a11c369424602b104e3c58be9 Cc: Alejandro Acosta , IPv6 Ops WG Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:58:14 -0000 --001a11c369424602b104e3c58be9 Content-Type: text/plain; charset=ISO-8859-1 First, I want to comment that I support the idea behind the draft. I think there is need for such a larger prefix for training and documentation purposes. Now, thinking about where to get that documentation prefix form, I'm somewhat torn: - taking it from 2000/3 could either generate less or more confusion, depending on who you talk to, and would require all operators (well, all those wise enough to do ingress filtering) to modify acls and perhaps prefix-lists as well. However, looking in detail at 2000::/3 I found some weird things that one should probably be filtering out anyways, like 2001:10::/28. So maybe revisiting ingress filters is not such a bad a idea after all. - taking it from outside 2000/3 might be a bit harder to explain to newbies (although I believe it shouldn't be that hard, it might be a good moment to introduce them to the IANA registry and allocation policies), but would not require extensive filter reconfiguration. However, it would somehow 'pollute' empty reserved blocks, and I'd hate it to regret this at some point in the future. - there might be other choices, like blocks that have been previously used for other purposes and then deprecated or returned, I'm specifically looking at: 0200::/7, which is marked as deprecated since 2004. Maybe we can re-use it again for a purpose with no critical operational consequences ? 3ffee::/16, former 6bone? It's been a while since 6bone was decommissioned. I found a very interesting bogon entry, within 2000/3 and that people might be already filtering out: 2002:e000:: /20 (6to4 mapped IPv4 multicast). I'm not sure about the possible side-effects though. Overall, I'd be leaning to choosing something outside 2000::/3 but I could live with a different choice, too. Thanks Antonio for bringing this up. regards ~Carlos On Mon, Aug 12, 2013 at 12:36 AM, Alejandro Acosta < alejandroacostaalamo@gmail.com> wrote: > My comments below: > > On 8/11/13, cb.list6 wrote: > > On Aug 11, 2013 12:24 PM, "Antonio M. Moreiras" wrote: > >> > >> Hi. > >> > >> I would like to ask you to please review and comment the following > draft: > >> > >> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 > >> > >> It intends to ask IANA to reserve another IPv6 prefix for documentation. > >> Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago. > >> > >> The prefix 2001:db8::/32 showed to be very useful. It is widely used. > >> But we are still facing the same problem that RFC 3849 tried to address: > >> in some kind of documents, tutorials and didactic laboratories, we have > >> been using other prefixes, because a /32 isn't enough to represent the > >> scenario. > >> > >> We consider that a /20 would be enough. > >> > >> If possible, we would like to ask IANA to reserve something easy to > >> remember, and self explaining, such as: > >> > >> 2D0C::/20 > >> > >> but *this suggestion is not stated in the document*. This prefix is from > >> the global unicast space, and 2d00::/8 is currently marked as reserved > >> by IANA [1], so it would be possible. Anyway, we think it would be > >> better to discuss the question in the mailing-list. > >> > >> Reviewing the archives from when draft-huston-ipv6-documentation-prefix > >> (that became RFC 3849) was being discussed, both questions (the > >> necessity of a larger prefix, or multiple prefixes, and the possibility > >> to reserve something easier to remember and self explaining) were > >> raised. I am not sure why none of them led to something concrete. > >> Probably because the draft just intended to document an allocation > >> already made by APNIC, and maybe it was not so clear then how useful it > >> would be. > >> > >> If you agree in principle with the proposal, other point to discuss is > >> if this subject is compatible with v6ops. Maybe it should be addressed > >> in 6man, or other place. > >> > > > > As a network operator i already must block the documentation prefix > today. > > As most of us. > > > > > I see no good reason why i must update all my acls for this new prefix > > We tried to explain the reasons in the drafts. So far the > documentation prefix has been incredible useful at all levels, however > we know that there are _many_ cases where a /32 for documentation is > not enough, we mentioned many situations in the draft and I do not > doubt that there are probably more. > > > > > If your docs require more than /32, use ULA. If you must make another > > official documentation prefix do not take it from 2000/3 > > In that case let's obsolete 3849.., sorry just kidding. > > > > > If you take it from 2000/3 you are creating work for network operators > > In somehow the authors considered the idea of using 4D0C::/20 instead > of using 2D0C::/20 however we really want to hear everyone opinions > here. In this case, using 4D0C nobody need to update the ACLs as you > mention. > > Thanks, > > Alejandro, > > > > > CB > > > >> Thanks. > >> Moreiras. > >> > >> [1] > >> > > > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- > ===== > ^A.......o$ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= --001a11c369424602b104e3c58be9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
First, I want to comment that I support the idea behind th= e draft. I think there is need for such a larger prefix for training and do= cumentation purposes.

Now, thinking about where to get t= hat documentation prefix form, I'm somewhat torn:

- taking it from 2000/3 could either generate less or m= ore confusion, depending on who you talk to, and would require all operator= s (well, all those wise enough to do ingress filtering) to modify acls and = perhaps prefix-lists as well. However, looking in detail at 2000::/3 I foun= d some weird things that one should probably be filtering out anyways, like= 2001:10::/28. So maybe revisiting ingress filters is not such a bad a idea= after all.

- taking it from outside 2000/3 might be a bit harder t= o explain to newbies (although I believe it shouldn't be that hard, it = might be a good moment to introduce them to the IANA registry and allocatio= n policies), but would not require extensive filter reconfiguration. Howeve= r, it would somehow 'pollute' empty reserved blocks, and I'd ha= te it to regret this at some point in the future.

- there might be other choices, like blocks that have b= een previously used for other purposes and then deprecated or returned, I&#= 39;m specifically looking at:

0200::/7, which is m= arked as deprecated since 2004. Maybe we can re-use it again for a purpose = with no critical operational consequences ?=A0
3ffee::/16, former 6bone? It's been a while since 6bone was decomm= issioned.=A0

I found a very interesting bogon entr= y, within 2000/3 and that people might be already filtering out:=A02002:e000:: /20 (6to4 mapped IPv4 multicast). I'm not sure about the= possible side-effects though.

Overall, I'd be leanin= g to choosing something outside 2000::/3 but I could live with a different = choice, too.

Thanks Antonio for bringin= g this up.

regards
<= span style=3D"color:rgb(51,51,51);font-family:Arial;font-size:12px;line-hei= ght:18px">
~Carlos






On Mon, Aug 12, 2013 at 12:36 AM, Aleja= ndro Acosta <alejandroacostaalamo@gmail.com> wr= ote:
My comments below:

On 8/11/13, cb.list6 <cb.list6@gma= il.com> wrote:
> On Aug 11, 2013 12:24 PM, "Antonio M. Moreiras" <moreiras@nic.br> wrote:
>>
>> Hi.
>>
>> I would like to ask you to please review and comment the following= draft:
>>
>> http://tools.ietf.org/html/draft-moreiras-v6ops-r= fc3849bis-00
>>
>> It intends to ask IANA to reserve another IPv6 prefix for document= ation.
>> Something larger than the 2001:db8::/32, reserved by APNIC 10 year= s ago.
>>
>> The prefix 2001:db8::/32 showed to be very useful. It is widely us= ed.
>> But we are still facing the same problem that RFC 3849 tried to ad= dress:
>> in some kind of documents, tutorials and didactic laboratories, we= have
>> been using other prefixes, because a /32 isn't enough to repre= sent the
>> scenario.
>>
>> We consider that a /20 would be enough.
>>
>> If possible, we would like to ask IANA to reserve something easy t= o
>> remember, and self explaining, such as:
>>
>> 2D0C::/20
>>
>> but *this suggestion is not stated in the document*. This prefix i= s from
>> the global unicast space, and 2d00::/8 is currently marked as rese= rved
>> by IANA [1], so it would be possible. Anyway, we think it would be=
>> better to discuss the question in the mailing-list.
>>
>> Reviewing the archives from when draft-huston-ipv6-documentation-p= refix
>> (that became RFC 3849) was being discussed, both questions (the >> necessity of a larger prefix, or multiple prefixes, and the possib= ility
>> to reserve something easier to remember and self explaining) were<= br> >> raised. I am not sure why none of them led to something concrete.<= br> >> Probably because the draft just intended to document an allocation=
>> already made by APNIC, and maybe it was not so clear then how usef= ul it
>> would be.
>>
>> If you agree in principle with the proposal, other point to discus= s is
>> if this subject is compatible with v6ops. Maybe it should be addre= ssed
>> in 6man, or other place.
>>
>
> As a network operator i already must block the documentation prefix to= day.

As most of us.

>
> I see no good reason why i must update all my acls for this new prefix=

We tried to explain the reasons in the drafts. So far the
documentation prefix has been incredible useful at all levels, however
we know that there are _many_ cases where a /32 for documentation is
not enough, we mentioned many situations in the draft and I do not
doubt that there are probably more.

>
> If your docs require more than /32, use ULA. If you must make another<= br> > official documentation prefix do not take it from 2000/3

In that case let's obsolete 3849.., sorry just kidding.

>
> If you take it from 2000/3 you are creating work for network operators=

In somehow the authors considered the idea of using 4D0C::/20 instead=
of using 2D0C::/20 however we really want to hear everyone opinions
here. In this case, using 4D0C nobody need to update the ACLs as you
mention.

Thanks,

Alejandro,

>
> CB
>
>> Thanks.
>> Moreiras.
>>
>> [1]
>>
> http://www.= iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-= assignments.xhtml
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>


--
=3D=3D=3D=3D=3D
^A.......o$
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



--
=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--001a11c369424602b104e3c58be9-- From wesley.george@twcable.com Mon Aug 12 13:05:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0421F9EC4 for ; Mon, 12 Aug 2013 13:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.88 X-Spam-Level: X-Spam-Status: No, score=0.88 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 3amUB6t6J4nt for ; Mon, 12 Aug 2013 13:05:10 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7340621F9ED2 for ; Mon, 12 Aug 2013 13:05:09 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,864,1367985600"; d="scan'208,217";a="37971941" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Aug 2013 16:04:46 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 12 Aug 2013 16:05:07 -0400 From: "George, Wes" To: "carlos@lacnic.net" Date: Mon, 12 Aug 2013 16:05:06 -0400 Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: Ac6XkmU4JfIgf2edTuewHxs9YfDyMwAA9sCg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4PRVPEXVS15cor_" MIME-Version: 1.0 Cc: Alejandro Acosta , "" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:05:15 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of C= arlos Martinez-Cagnazzo As far as I understand, Antonio does some training involving 6RD deployment= s, where each 'team' needs its own /32. There might be other cases though, = like for example doing some work involving BGP routing between different te= ams and for which you expect each one of them to carve a /32. [WEG] and that environment can't use ULA because....? Not saying that there aren't legitimate cases when having more than /32 of = documentation space might be useful, just saying that I don't believe the n= eeds of a lab environment (even in the context of training) is necessarily = one of them. Wes George Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Carlos Martinez-Cagnazzo

 

As far as I understand, Antonio does some training i= nvolving 6RD deployments, where each 'team' needs its own /32. There might = be other cases though, like for example doing some work involving BGP routi= ng between different teams and for which you expect each one of them to carve a /32.

[WEG] and that environment can’t = use ULA because….?

 <= /p>

Not saying that there are= n’t legitimate cases when having more than /32 of documentation space= might be useful, just saying that I don’t believe the needs of a lab environment (even in the context of training) is necessarily one of = them.

 <= /p>

Wes George

Anything below this line = has been added by my company’s mail server, I have no control over it= .

-----------------<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4PRVPEXVS15cor_-- From owen@delong.com Mon Aug 12 13:21: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 2A86521F9E68 for ; Mon, 12 Aug 2013 13:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 N9qjwCDGbiz9 for ; Mon, 12 Aug 2013 13:21: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 4680A21F9EFE for ; Mon, 12 Aug 2013 13:21:00 -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 r7CKJioE017171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 13:19:44 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CKJioE017171 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376338784; bh=h45VmwDqtFPSyrurepWrzOFI+p4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Od0Is0WCpmwSwawsnaoLMeDTxwP2J7eSDEZ1fr0K9vYwURM87DRKdPMJpckcYjt6+ cG+jsXWa7Xtj8eBJSbPR+ZbRgr7mFehqVSS5jKhMxJzTyayfI7oGjfMEddB1apMVgK PG5svZ5d2+yij/+i/GLYFFuuL4sicLCj7cxUq48E= 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: Mon, 12 Aug 2013 13:19:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18CD1C88-5F15-46BA-A76C-87F9A033E209@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> To: carlos@lacnic.net X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 13:19:44 -0700 (PDT) Cc: Alejandro Acosta , IPv6 Ops WG Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:21:01 -0000 I think creating ambiguity with 3ffe would be a very very bad idea for = this. Too much history and too wide spread. It does not matter much to me whether it comes from within 2000::/3 or = outside. I consider either one an acceptable alternative. Owen From owen@delong.com Mon Aug 12 13:21: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 8575921F9F97 for ; Mon, 12 Aug 2013 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxxZvsHTTeBO for ; Mon, 12 Aug 2013 13:21:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 50EA721F9EFE for ; Mon, 12 Aug 2013 13:21:10 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7CKJioF017171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 13:20:22 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CKJioF017171 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376338822; bh=/b9ftsQoqW5ZZJm8ovHqJQJzPrk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=w8yMZ6TbLyjLPIAZP4Qb3rvr92oMPSfc2xiisXE64UmLEfPVB4YmqoUwm1RUE7oi7 3g31UsfUo6VsaK12RNbhxMrpu9SNCQWfBd02riiULCcrKnM9GKd7PCaYRtxWG9sBAZ CCqGveT+Vp7v+LCL3VQH4zGURph8a/e6WTH/3dV8= Content-Type: multipart/alternative; boundary="Apple-Mail=_35BCB530-86A7-41BB-90DC-3438126F6C6F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> Date: Mon, 12 Aug 2013 13:20:22 -0700 Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 13:20:22 -0700 (PDT) Cc: Alejandro Acosta , "" , "carlos@lacnic.net" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:21:12 -0000 --Apple-Mail=_35BCB530-86A7-41BB-90DC-3438126F6C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Because in some cases, the lab is also teaching about ULA+GUA = configurations. Owen On Aug 12, 2013, at 13:05 , "George, Wes" = wrote: > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Carlos Martinez-Cagnazzo >=20 > =20 > As far as I understand, Antonio does some training involving 6RD = deployments, where each 'team' needs its own /32. There might be other = cases though, like for example doing some work involving BGP routing = between different teams and for which you expect each one of them to = carve a /32. > [WEG] and that environment can=92t use ULA because=85.? > =20 > Not saying that there aren=92t legitimate cases when having more than = /32 of documentation space might be useful, just saying that I don=92t = believe the needs of a lab environment (even in the context of training) = is necessarily one of them. > =20 > Wes George > Anything below this line has been added by my company=92s mail server, = I have no control over it. > ----------------- >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_35BCB530-86A7-41BB-90DC-3438126F6C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 wesley.george@twcable.com>= ; wrote:

 
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Carlos = Martinez-Cagnazzo

 
As far as I understand, Antonio does some training involving = 6RD deployments, where each 'team' needs its own /32. There might be = other cases though, like for example doing some work involving BGP = routing between different teams and for which you expect each one of = them to carve a /32.
[WEG] and that environment can=92t use ULA = because=85.?
 
Not saying that there aren=92t legitimate = cases when having more than /32 of documentation space might be useful, = just saying that I don=92t believe the needs of a lab environment (even = in the context of training) is necessarily one of = them.
 
Wes George
Anything below this line = has been added by my company=92s mail server, I have no control over = it.
-----------------This E-mail and any of its attachments may = contain Time Warner Cable proprietary information, which is privileged, = confidential, or subject to copyright belonging to Time Warner Cable. = This E-mail is intended solely for the use of the individual or entity = to which it is addressed. If you are not the intended recipient of this = E-mail, you are hereby notified that any dissemination, distribution, = copying, or action taken in relation to the contents of and attachments = to this E-mail is strictly prohibited and may be unlawful. If you have = received this E-mail in error, please notify the sender immediately and = permanently delete the original and any copy of this E-mail and any = printout.
_______________________________________________
v6o= ps mailing list
v6ops@ietf.org
References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:31:05 -0000 On 12/08/2013 17:27, Arie Vayner (avayner) wrote: > Owen, > > While the arguments about moving the firewalls closer to the users are valid they are often are not practical (or at least the customers I worked with would not implement this option). > Imagine an enterprise network with 300 spoke sites, but only 2 or 3 Internet gateway locations (with some private WAN in between). > Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)... This is a major CAPEX and OPEX impact... Clearly DOS and scanning protection has to be done as close to the Internet border routers as possible, and there your logic applies. However, as Steve Bellovin pointed out many years ago, the best number of firewalls for upper layer protection is one per host, which scales nicely and has less CAPEX and OPEX than middlebox firewalls will ever have. Not that I see any of this argument as relevant to the IP version number. Brian > Arie > > From: Owen DeLong [mailto:owen@delong.com] > Sent: Friday, August 9, 2013 12:17 PM > To: Arie Vayner (avayner) > Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC > > > On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) > wrote: > > > Another loosely related point that I think could make sense in such a document would be the ways to accomplish multi-homing and how it is different than today's IPv4 implementations. > > Many enterprises rely on NAT on the Internet edge as their multi-homing/traffic engineering mechanism with IPv4. > > If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highlight the symmetry requirement due to stateful security layers. > Traffic leaving from an Internet gateway site to the Internet has to come back through the same site, or the stateful firewalls would break the flow (well, has to hit the same stateful security layer) > > Or stateful firewalls have to get better about sharing state. There are two things that can help with this... > > 1. Put your firewalls as close to the end systems they protect as possible. Make your security zones relatively small and place the firewalls closer together at those narrower borders. > This will often require more firewall units, but it helps in a number of ways: > A. Firewall policy tends to be much simpler (and as a result less error prone and more reliable) > B. The hardware demands on the firewall tend to be lower so you can buy cheaper units. > C. The simpler rulesets can be more easily tailored to meet business requirements as they evolve. > > > > 2. Improve firewalls. Give the firewalls that all protect the same boundary a way to mesh-peer with each other and exchange information about the state tables such that triangle routing is no longer problematic. > > > Syncing upstream and downstream routing policies is not always an easy task (but could be relevant in some cases). > Linking the Internet gateway layer across sites (before hitting the stateful security layer) could be another solution. > > If we make the changes above to the firewalls, this could be a lot less relevant in most cases. > > > Do you think a short discussion to raise awareness for this potential issue could be relevant in such a document? > > It's certainly worth documenting. I'm not sure whether it belongs in this document or not. > > Owen > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wesley.george@twcable.com Mon Aug 12 13:31: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 EB21221F9E40 for ; Mon, 12 Aug 2013 13:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.27 X-Spam-Level: X-Spam-Status: No, score=0.27 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqEB5iJQZhtN for ; Mon, 12 Aug 2013 13:31:03 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 462E821F9CF7 for ; Mon, 12 Aug 2013 13:31:03 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,864,1367985600"; d="scan'208,217";a="116777817" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Aug 2013 16:29:56 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 12 Aug 2013 16:30:48 -0400 From: "George, Wes" To: Owen DeLong Date: Mon, 12 Aug 2013 16:30:47 -0400 Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: Ac6XmX8opnRmDrqBS3G4kRKDcBoV2AAAJ5tg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABF00CPRVPEXVS15cor_" MIME-Version: 1.0 Cc: Alejandro Acosta , "" , "carlos@lacnic.net" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:31:08 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABF00CPRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Owen DeLong [mailto:owen@delong.com] Because in some cases, the lab is also teaching about ULA+GUA configuration= s. [WEG] I don't follow your logic. 2001:db8::/32 is not GUA, nor would any su= ch documentation prefix be -quite the contrary, in fact. It just happens to= come from 2000::/3 so it *looks* more like GUA, but the network behavior i= s no different. Wes On Aug 12, 2013, at 13:05 , "George, Wes" > wrote: From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Carlos Martinez-Cagn= azzo As far as I understand, Antonio does some training involving 6RD deployment= s, where each 'team' needs its own /32. There might be other cases though, = like for example doing some work involving BGP routing between different te= ams and for which you expect each one of them to carve a /32. [WEG] and that environment can't use ULA because....? Not saying that there aren't legitimate cases when having more than /32 of = documentation space might be useful, just saying that I don't believe the n= eeds of a lab environment (even in the context of training) is necessarily = one of them. Wes George Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABF00CPRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

From: Owen DeLon= g [mailto:owen@delong.com]

Because in some cases, the lab is also teaching about ULA+GU= A configurations.

 

= [WEG] I don’t follow your logic. 2001:db8::/32 = is not GUA, nor would any such documentation prefix be –quite the con= trary, in fact. It just happens to come from 2000::/3 so it *looks* = more like GUA, but the network behavior is no different. =

 

Wes

=  



 

= From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Carlos Martinez-Cagnazzo<= br>

 

As far as I und= erstand, Antonio does some training involving 6RD deployments, where each '= team' needs its own /32. There might be other cases though, like for exampl= e doing some work involving BGP routing between different teams and for whi= ch you expect each one of them to carve a /32.

[WEG]&nb= sp;and that environment can’t use ULA be= cause….?

=  

Not sayi= ng that there aren’t legitimate cases when having more than /32 of do= cumentation space might be useful, just saying that I don’t believe t= he needs of a lab environment (even in the context of training) is necessar= ily one of them.

 

Wes = George

Anything= below this line has been added by my company’s mail server, I have n= o control over it.

-----------------

 

<= p class=3DMsoNormal>This E-mail and any of its attachments may contain Tim= e Warner Cable proprietary information, which is privileged, confidential, = or subject to copyright belonging to Time Warner Cable. This E-mail is inte= nded solely for the use of the individual or entity to which it is addresse= d. If you are not the intended recipient of this E-mail, you are hereby not= ified that any dissemination, distribution, copying, or action taken in rel= ation to the contents of and attachments to this E-mail is strictly prohibi= ted and may be unlawful. If you have received this E-mail in error, please = notify the sender immediately and permanently delete the original and any c= opy of this E-mail and any printout.
_________________________________= ______________
v6ops mailing list
<= span style=3D'color:purple'>v6ops@ietf.org
https://= www.ietf.org/mailman/listinfo/v6ops

<= /div>

 

= --_000_2671C6CDFBB59E47B64C10B3E0BD59230439ABF00CPRVPEXVS15cor_-- From owen@delong.com Mon Aug 12 14:11:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8810121F9EEE for ; Mon, 12 Aug 2013 14:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGqNoO0Qbovk for ; Mon, 12 Aug 2013 14:11:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 16C1421F9EA7 for ; Mon, 12 Aug 2013 14:11:11 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7CL71Lc018414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 14:07:01 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CL71Lc018414 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376341622; bh=fIFlpc+khCpxr1ov+pt7/CWOM40=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=UtgmjEYC6O+QWsP/RpUjOgi+mrqHl0qlISf9j1+XOwjyXt2tM9Hb4AJ0vOTXvMqok 3fzWFcpjdbBwYzU9z56nxWTZ+me1sxCy8z2UNKRjR8DobEkvZssvcSyg9rfmHmPbij Phg/IoJ6EYvvMfL04U077j1bWGdtNPQL9GyKEsoc= Content-Type: multipart/alternative; boundary="Apple-Mail=_42C2E920-03F6-433A-A789-553E6648E0C0" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> Date: Mon, 12 Aug 2013 14:07:12 -0700 Message-Id: <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> To: "George, Wes" 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]); Mon, 12 Aug 2013 14:07:02 -0700 (PDT) Cc: Alejandro Acosta , "" , "carlos@lacnic.net" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:11:18 -0000 --Apple-Mail=_42C2E920-03F6-433A-A789-553E6648E0C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 But having obviously different prefixes for the class to use to indicate = what is ULA and what is "simulated GUA" is still very useful from a = teaching perspective. Owen On Aug 12, 2013, at 1:30 PM, "George, Wes" = wrote: > =20 > From: Owen DeLong [mailto:owen@delong.com]=20 >=20 > Because in some cases, the lab is also teaching about ULA+GUA = configurations. > =20 > [WEG] I don=92t follow your logic. 2001:db8::/32 is not GUA, nor would = any such documentation prefix be =96quite the contrary, in fact. It just = happens to come from 2000::/3 so it *looks* more like GUA, but the = network behavior is no different. > =20 > Wes > =20 > On Aug 12, 2013, at 13:05 , "George, Wes" = wrote: >=20 >=20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Carlos Martinez-Cagnazzo >=20 >=20 > =20 > As far as I understand, Antonio does some training involving 6RD = deployments, where each 'team' needs its own /32. There might be other = cases though, like for example doing some work involving BGP routing = between different teams and for which you expect each one of them to = carve a /32. > [WEG] and that environment can=92t use ULA because=85.? > =20 > Not saying that there aren=92t legitimate cases when having more than = /32 of documentation space might be useful, just saying that I don=92t = believe the needs of a lab environment (even in the context of training) = is necessarily one of them. > =20 > Wes George > Anything below this line has been added by my company=92s mail server, = I have no control over it. > ----------------- > =20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_42C2E920-03F6-433A-A789-553E6648E0C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 But having obviously different = prefixes for the class to use to indicate what is ULA and what is = "simulated GUA" is still very useful from a teaching = perspective.

Owen

On Aug 12, = 2013, at 1:30 PM, "George, Wes" <wesley.george@twcable.com>= ; wrote:

 
From: Owen DeLong [mailto:owen@delong.com] 

Because in some cases, the lab = is also teaching about ULA+GUA configurations.
[WEG] I don=92t follow your = logic. 2001:db8::/32 is not GUA, nor would any such documentation prefix = be =96quite the contrary, in fact. It just happens to come from 2000::/3 = so it *looks* more like GUA, but the network behavior is no = different.
 
Wes
 
On Aug 12, 2013, at 13:05 , "George, Wes" <wesley.george@twcable.com> = wrote:
 
This E-mail and any of its attachments = may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time = Warner Cable. This E-mail is intended solely for the use of the = individual or entity to which it is addressed. If you are not the = intended recipient of this E-mail, you are hereby notified that any = dissemination, distribution, copying, or action taken in relation to the = contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please = notify the sender immediately and permanently delete the original and = any copy of this E-mail and any printout.
 Date: Tue, 13 Aug 2013 07:14:53 +1000 Message-Id: <20130812211453.89A833845161@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:15:14 -0000 In message <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com>, Owen DeLong writes: > > On Aug 11, 2013, at 16:38 , Mark Andrews wrote: > > > > > In message , Owen > DeLong write > > s: > >> I support the idea. It might be worth also asking for a ULA Doc slice > at the > >> same time. I think a /48 is probably sufficient for most ULA examples. > >> > >> But I think it would be good to be able to write up ULA examples and > training > >> that use actual ULA prefixes intended for documentation. > > > > Why? > > > > The purpose of reserving a prefix for documentation is to ensure > > that documentation prefixes doesn't clash with ones assigned by a > > registries. For locally assigned ULA don't need a reserved prefix > > because there is no registry assignments to clash with. For centrally > > assigned ULA there is no registry yet so no practical examples can > > exist. When such a registry is assigned we can document a prefix in the > > meantime just generate a new prefix when you write your documentation. > > > > dd if=/dev/random bs=5 count=1 | od -tx1 | > > awk '/000000/ { print "fd" $2 ":" $3 $4 ":" $5 $6 ; exit} > > > > Because, as history has shown, if there isn't a prefix documented as "you > should use this for documentation and training only", people tend to copy > examples verbatim instead. And it causes NO damage unless they decide to exchange routes at which time the sites that decide to not generate their own prefix have to renumber. Note that doesn't stop them communicating. They can use GUA. They can add another ULA in parallel and exchange that prefix then remove the other prefix. This is no different than changing PA addresses. > Admittedly, I still run into the occasional internal network numbered out > of doc-prefix space in IPv4 because they copied the examples, but I run > into a lot more cases where they improperly copied examples that used > other prefixes than the documentation prefix. > > The point of a documentation prefix is not only to avoid clashing with > registry space. It is also so that if you blindly copy examples, this fact > is instantly obvious to any network engineer who knows what they are > doing and can be more easily identified and corrected (hopefully before > it becomes entrenched beyond repair). There is no such thing as "entrenched beyound repair" with ULA as there is *always* a probability that you will need to renumber when merging whether at the company level or just at the routing / address space levels. That is something that you accept when you use ULA addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alejandroacostaalamo@gmail.com Mon Aug 12 14:25: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 37FD621F992B for ; Mon, 12 Aug 2013 14:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVqTwp5k0L6d for ; Mon, 12 Aug 2013 14:25:36 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6E64021F90A7 for ; Mon, 12 Aug 2013 14:25:35 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b15so3827876eek.12 for ; Mon, 12 Aug 2013 14:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:subject:to:cc:reply-to:mime-version :content-type:content-transfer-encoding; bh=PY3DQezypCyKWeZqAYnoRKdmLcdKNKXBnNFoQMPNhdc=; b=i6y+LKgldjewwV6eo3ib0AEZxonRV9KKZGRvdDyq2NUyf+QBhJ8XnKKOFXcjiXaDL4 fE3Zz51+5Efxe0vqeT9BVoKTlft0eQVvilZSgKOeKhK1no2s7AmPRij2tJR6ldf9QzH2 CmbN/hy4lDS01fxPaKYJaS8MIMtVVkUAp+vVwDmvCDZZTey0VkfTqxoqx4NbaNQ+KkGr BvwhdnMPV06HtIrFX0wLyo+bWwcFvGr2kctikvT09Nqvr3mqM/VxLEX4/Cgd/rmnfJfW O8zzTC1WMn5d5VGviZOz+5uY1zbOKXuSo2U3o0gzTkCkQeXcnPe7cCz9O6GbjTk9aBKF ordg== X-Received: by 10.14.214.136 with SMTP id c8mr1219741eep.6.1376342734513; Mon, 12 Aug 2013 14:25:34 -0700 (PDT) Received: from lhrnms-0059-fe.pr.nmsg.s.nokia.com (em1x-25.lhr.messaging.nokia.com. [131.228.18.25]) by mx.google.com with ESMTPSA id k3sm60789252een.16.2013.08.12.14.25.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 12 Aug 2013 14:25:33 -0700 (PDT) Message-ID: <520952cd.83c10e0a.2f50.6638@mx.google.com> Date: Mon, 12 Aug 2013 21:25:25 +0000 From: "Alejandro Acosta" To: "Fred Baker (fred)" , "Owen DeLong" MIME-Version: 1.0 X-Priority: 3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: Alejandro Acosta , "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: alejandroacostaalamo@gmail.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:25:44 -0000 Hi Owen, thanks a lot for your example. I'm going to mention one more case: Recently I had to write a document explaining an IPv6 address plan, one= part of the document consisted in an example of multi regional ISP. In= those cases the ISP generally receives blocks larger than /32 from the= RIR. I could not use the current 2001:db8::/32 and unfortunately I ha= d to write the examples using other prefixes. Thanks a lot, -----Mensaje original----- De: Owen DeLong Enviados: 08/12/2013 2:01:18 PM Para: Fred Baker (fred) Cc: Alejandro Acosta; Asunto: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 If you are trying to demonstrate or teach peerings across multiple ASNs= and show examples of how multiple ISPs might carve up their /32s (or l= arger) differently, it's very hard to do all of that within a single /3= 2. Antonio and I do very similar types of training from the sounds of it a= nd we have encountered the same issues. A larger doc prefix would be useful. I don't see it as critical, but I = don't see any significant reason not to do so. I understand the objecti= on raised by Cameron, but, really, anything the IETF does likely create= s some amount of work for operators. Thus is the nature of operating a = network built on an evolving technology. You knew the job was dangerous= when you took it. Owen On Aug 12, 2013, at 10:17 , "Fred Baker (fred)" wrote: > Speaking as a chair, I don't have a problem with it being discussed i= n v6ops, but I think the issue belongs in 6man by charter. >=20 > Speaking as a document author (think of RFCs 6052, 6144, 6145, 6146, = and 6147, which I helped edit or write), I'm not sure I have ever had a= case in which a /32 was not enough. I might, for example, need to use = layers of prefixes like > 2001:db8::/32 > 2001:db8:100::/40 > 2001:db8:202::/48 > 2001:db8:300:300::/56 > 2001:db8:400:440::/60 > 2001:db8:400:444::/64 > but I seem to have plenty of layers at my disposal. I'd be interested= to understand the cases in which you find yourself cramped? >=20 > On Aug 11, 2013, at 12:16 PM, Antonio M. Moreiras w= rote: >=20 >> Hi. >>=20 >> I would like to ask you to please review and comment the following d= raft: >>=20 >> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00 >>=20 >> It intends to ask IANA to reserve another IPv6 prefix for documentat= ion. >> Something larger than the 2001:db8::/32, reserved by APNIC 10 years = ago. >>=20 >> The prefix 2001:db8::/32 showed to be very useful. It is widely used= . >> But we are still facing the same problem that RFC 3849 tried to addr= ess: >> in some kind of documents, tutorials and didactic laboratories, we h= ave >> been using other prefixes, because a /32 isn't enough to represent t= he >> scenario. >>=20 >> We consider that a /20 would be enough. >>=20 >> If possible, we would like to ask IANA to reserve something easy to >> remember, and self explaining, such as: >>=20 >> 2D0C::/20 >>=20 >> but *this suggestion is not stated in the document*. This prefix is = from >> the global unicast space, and 2d00::/8 is currently marked as reserv= ed >> by IANA [1], so it would be possible. Anyway, we think it would be >> better to discuss the question in the mailing-list. >>=20 >> Reviewing the archives from when draft-huston-ipv6-documentation-pre= fix >> (that became RFC 3849) was being discussed, both questions (the >> necessity of a larger prefix, or multiple prefixes, and the possibil= ity >> to reserve something easier to remember and self explaining) were >> raised. I am not sure why none of them led to something concrete. >> Probably because the draft just intended to document an allocation >> already made by APNIC, and maybe it was not so clear then how useful= it >> would be. >>=20 >> If you agree in principle with the proposal, other point to discuss = is >> if this subject is compatible with v6ops. Maybe it should be address= ed >> in 6man, or other place. >>=20 >> Thanks. >> Moreiras. >>=20 >> [1] >> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv= 6-unicast-address-assignments.xhtml >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Mon Aug 12 15:05: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 2763F21F9EB6 for ; Mon, 12 Aug 2013 15:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdqdRCXvLX-l for ; Mon, 12 Aug 2013 15:04:57 -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 40BA021F9F5E for ; Mon, 12 Aug 2013 15:04:57 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 84A7CC9425; Mon, 12 Aug 2013 22:04:42 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376345096; bh=hlsR1plxlPs91y1r3NuC7oxzogmFoDccXWu8iXfye98=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=g2X8YinkPlwY6yQBASblrU7zt6BjxNy5jnHR+9HFX64HYPX72pQgRgrOFwRss2RxJ AGVsx6Hacv+EdEWkg8DqyGDOhqRhSnFClTVe1GhUXFLrjEDDXJdS5e/yhk3/K/SR2q 4zPx0alTEtEQjARO4Vb1eel3cPcv1LmpU7H9BL2I= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 12 Aug 2013 22:04:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DF11216042F; Mon, 12 Aug 2013 22:09:21 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3M7OH6JHTolf; Mon, 12 Aug 2013 22:09:21 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2BEEF160434; Mon, 12 Aug 2013 22:09:21 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id C406B160431; Mon, 12 Aug 2013 22:09:20 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1295538453A1; Tue, 13 Aug 2013 08:04:39 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> In-reply-to: Your message of "Mon, 12 Aug 2013 10:00:33 -0700." <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> Date: Tue, 13 Aug 2013 08:04:39 +1000 Message-Id: <20130812220439.1295538453A1@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:05:02 -0000 In message <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com>, Owen DeLong writes: > > On Aug 11, 2013, at 17:27 , Mark Andrews wrote: > > > > > In message <52082128.5090503@nic.br>, "Antonio M. Moreiras" writes: > >> On 11/08/13 19:29, Owen DeLong wrote: > >>> I support the idea. It might be worth also asking for a ULA Doc slice > at th > >> e same time. > >>> I think a /48 is probably sufficient for most ULA examples. > >>> > >>> But I think it would be good to be able to write up ULA examples and > traini > >> ng that use > >>> actual ULA prefixes intended for documentation. > >> > >> I agree. An organization could generate an ULA prefix specifically to > >> use in a course, or document. But it could be copied and used in > >> production environments. This would break the "global uniqueness", and > >> could lead to other problems. > > > > FUD. > > > > Is FUD actually FUD when there is proof that it has happened before? > > > You either do the correct thing and generate your own prefix or you > > don't and copy one and hope that no one else has copied it that you > > are connecting to. Having a reserved prefix will not help you here. > > I disagree. See my previous message. It has helped in IPv4 and I see > no reason it would not help in IPv6. Sorry Owen, you need to apply IPv6 think, in particular ULA think to the problem space which is different to both IPv4 think and general IPv6 think. > It may not do much to prevent mistakes, but it makes them much easier > to identify and resolve. Copying a documentation prefix is NOT a error. > > ULA are not "globally unique", they are locally unique with a > > extrememly low probability of collision when *locally* connecting. > > If you use them in a global context (i.e. publish to the world in > > AAAA records) without some global differentiator you will cause > > problems. > > Q.E.D.: > route-views>sh ip bgp 10.0.0.0/8 longer-prefixes > BGP table version is 297146110, local router ID is 128.223.51.103 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > *> 10.30.10.0/24 217.75.96.60 0 0 16150 31027 > 35376 i > route-views>sh ip bgp 172.12.0.0/12 long > route-views>sh ip bgp 172.12.0.0/12 longer-prefixes > BGP table version is 297170440, local router ID is 128.223.51.103 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > * 172.0.0.0/12 154.11.11.113 0 0 852 2914 > 7018 i > * 208.74.64.40 0 19214 174 > 7018 i > * 4.69.184.193 0 0 3356 7018 i > * 194.85.102.33 0 3277 3267 > 3356 7018 i > * 154.11.98.225 0 0 852 2914 > 7018 i > * 207.172.6.20 0 0 6079 3356 > 7018 i > * 193.0.0.56 0 3333 3356 > 7018 i > * 69.31.111.244 3 0 4436 2914 > 7018 i > * 66.59.190.221 0 6539 577 > 7018 i > * 194.85.40.15 0 3267 3356 > 7018 i > * 209.124.176.223 0 101 101 7018 > i > * 128.223.253.10 0 3582 3701 > 3356 7018 i > * 207.172.6.1 0 0 6079 3356 > 7018 i > * 134.222.87.1 0 286 7018 i > * 157.130.10.233 0 701 7018 i > * 66.185.128.48 7 0 1668 7018 i > * 202.249.2.86 0 7500 2497 > 7018 i > * 216.218.252.164 0 6939 1299 > 7018 i > * 114.31.199.1 0 0 4826 6939 > 1299 7018 i > * 144.228.241.130 0 1239 7018 i > * 208.51.134.254 0 0 3549 7018 i > * 207.46.32.34 0 8075 7018 i > * 129.250.0.11 7 0 2914 7018 i > * 217.75.96.60 0 0 16150 1299 > 7018 i > * 202.232.0.2 0 2497 7018 i > * 89.149.178.10 10 0 3257 7018 i > * 66.110.0.86 0 6453 7018 i > * 203.62.252.186 0 1221 4637 > 3561 7018 i > * 203.181.248.168 0 7660 2516 > 3356 7018 i > * 164.128.32.11 0 3303 3320 > 7018 i > * 206.24.210.102 0 3561 7018 i > *> 12.0.1.63 0 7018 i > route-views>sh ip bgp 192.168.0.0/16 lon > route-views>sh ip bgp 192.168.0.0/16 longer-prefixes > > route-views> And I'm sure you will see routes leaked for fc00::/7 as well. Those leaks do not in general cause problem for anyone but the leakers themselves. The fact that people leak has nothing to do with documentation prefixes. > > All a documentation prefix will do is have one potentially toxic > > prefix compared to a handful of potentially toxic prefixes. There > > are 1099511627776 prefixes in fd00::/8. Even if there were thousands > > of documentation prefixes the odds of you hitting one when generating > > your own prefix are astronomically small. Additionally the more > > prefixes that are used in documentation the less toxic a particular > > prefix will be. > > No, it will also help to constrain such errors to an easily identifiable > single > prefix which will make the errors easier to identify and correct. This > is, IMHO, > a worth while goal in the real world where operators actually run networks > and have to deal with less than ideally trained predecessors and > colleagues. So a site has already choosen a ULA prefix that happens to match the soon to be documention prefix. They have done NOTHING wrong. It is causing NO operational problem. By creating a documentation prefix and telling them it is a poision prefix you have just forced them to renumber the moment they attempt to connect to anyone. You are trying to solve a non existent problem. All you are doing is saving the occasional site that was too stupid to pick a prefix for themselves and copied one from some documentation from renumbering when they connected to another site that was equally stupid and copied from the same documention examples when ULA doesn't say you won't have to renumber when you connect and exchange ULA routes. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owen@delong.com Mon Aug 12 15:06: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 3C86821E8054 for ; Mon, 12 Aug 2013 15:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxueg0Wyqehm for ; Mon, 12 Aug 2013 15:06:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5496121E8050 for ; Mon, 12 Aug 2013 15:06:10 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7CM4ZVZ019500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 15:04:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CM4ZVZ019500 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376345077; bh=rw+3mAj3oOK4wI07XudOC8rghhA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=I8gJxWfGadqi0lO1KoPlcLOqMiJoIFMiDo3Ns4BJsvpfKXSrwN//b7ArI4dDxbjjw 5JBn8qNiLdTCEtfklbdyEGqhhvT2sMIfuwu3Yb+V6lX2KsoucQrgUSa3YwdqAfN4Be 25sHwSFDuuoJm4+DDCsQsrs35Kg+X7CZl6nsOe60= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <20130812211453.89A833845161@drugs.dv.isc.org> Date: Mon, 12 Aug 2013 15:04:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> To: Mark Andrews 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]); Mon, 12 Aug 2013 15:04:37 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:06:12 -0000 >> Because, as history has shown, if there isn't a prefix documented as = "you >> should use this for documentation and training only", people tend to = copy >> examples verbatim instead. >=20 > And it causes NO damage unless they decide to exchange routes at > which time the sites that decide to not generate their own prefix > have to renumber. Note that doesn't stop them communicating. They > can use GUA. They can add another ULA in parallel and exchange > that prefix then remove the other prefix. This is no different > than changing PA addresses. I suppose that depends on your definition of no damage. In my experience, when someone does something like this and it is easily identified (thus more likely to be identified early), that is a win. It's much easier to correct a network addressing error that affects 10s = of systems in one building than one that has become pervasive across thousands of = systems world wide. If you make the error harder to detect by not having a documentation = prefix and thus having every document choose numbers at random, you greatly reduce = the probability of the problem being detected early. What harm is there in allocating the additional documentation prefix? = Your only argument seems to be that you don't feel it is necessary in your little = corner of the world. >> Admittedly, I still run into the occasional internal network numbered = out >> of doc-prefix space in IPv4 because they copied the examples, but I = run >> into a lot more cases where they improperly copied examples that used >> other prefixes than the documentation prefix. >>=20 >> The point of a documentation prefix is not only to avoid clashing = with >> registry space. It is also so that if you blindly copy examples, this = fact >> is instantly obvious to any network engineer who knows what they are >> doing and can be more easily identified and corrected (hopefully = before >> it becomes entrenched beyond repair). >=20 > There is no such thing as "entrenched beyound repair" with ULA as = there > is *always* a probability that you will need to renumber when merging > whether at the company level or just at the routing / address space = levels. > That is something that you accept when you use ULA addresses. Given the wide prevalence of RFC-1918 islands that were merged with double NATs instead of repaired in the IPv4 world (which I believe = likely outnumber the number of environments where one or the other entity was actually renumbered into non-conflicting space), I think we have strong evidence that this is not true. I would consider using double NAT not a repair, but a workaround which has significant adverse consequences. Owen From marka@isc.org Mon Aug 12 15:07: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 4469221E805A for ; Mon, 12 Aug 2013 15:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.148, 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 o4lBEBcGGsbD for ; Mon, 12 Aug 2013 15:07:53 -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 0F77A21E8050 for ; Mon, 12 Aug 2013 15:07:53 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8B11AC944E; Mon, 12 Aug 2013 22: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=1376345271; bh=ETrMyKdiGYGAFebOsRAS7XtHbyv5OmQc6zGm1t8AHI8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=plLjam4lVAIWIMl9coJz970xBGmUE6uL5SelDIsE9CYR7ciacQqRvIqff5OCE/EQU ayHCZgb9qC045oMa5Jy4BzaANQJh9IRUamFhguE2RWUfFHFriiaoNqj+F5NqDTiQ2F 34TZOxQdGhSW7vTyVPupSrEXGtnG7SioJnqcAiKg= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 12 Aug 2013 22:07:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E996C160435; Mon, 12 Aug 2013 22:12:17 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id AI4S0mpJ691f; Mon, 12 Aug 2013 22:12:16 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4AEC3160434; Mon, 12 Aug 2013 22:12:16 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 3A235160431; Mon, 12 Aug 2013 22:12:15 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id C5E993845404; Tue, 13 Aug 2013 08:07:33 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> In-reply-to: Your message of "Mon, 12 Aug 2013 09:55:36 -0700." Date: Tue, 13 Aug 2013 08:07:33 +1000 Message-Id: <20130812220733.C5E993845404@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:07:57 -0000 In message , Owen DeLong writes: > > On Aug 11, 2013, at 16:41 , Antonio M. Moreiras wrote: > > > On 11/08/13 19:29, Owen DeLong wrote: > >> I support the idea. It might be worth also asking for a ULA Doc slice at the same time. > >> I think a /48 is probably sufficient for most ULA examples. > >> > >> But I think it would be good to be able to write up ULA examples and training that use > >> actual ULA prefixes intended for documentation. > > > > I agree. An organization could generate an ULA prefix specifically to > > use in a course, or document. But it could be copied and used in > > production environments. This would break the "global uniqueness", and > > could lead to other problems. It would be nice to have a specific ULA > > documentation prefix. > > > > I would suggest a prefix with the L bit cleared, easy to remember, and > > maybe slightly shorter than /48. For example FC00:0:D0C0::/44. > > > > []s > > Moreiras. > > That would certainly be an acceptable solution as far as I am concerned. So you would use a Centrally Assigned ULA to document Locally Assigned ULAs? What are you smoking today? The is a BIG NOOOOOOOOOOOOOOOOOOOO!!!!!!!!!! > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From moreiras@nic.br Mon Aug 12 15:12: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 92D3021E804C for ; Mon, 12 Aug 2013 15:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OujjQR8ucs8A for ; Mon, 12 Aug 2013 15:12:02 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 161CB11E80E1 for ; Mon, 12 Aug 2013 15:12:02 -0700 (PDT) Received: from moreiras.in.nic.br (unknown [IPv6:2001:12ff:0:5::96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 9598620801BF for ; Mon, 12 Aug 2013 19:11:59 -0300 (BRT) Message-ID: <52095DAF.2050505@nic.br> Date: Mon, 12 Aug 2013 19:11:59 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> In-Reply-To: <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:12:04 -0000 On 12/08/13 18:07, Owen DeLong wrote: > But having obviously different prefixes for the class to use to indicate > what is ULA and what is "simulated GUA" is still very useful from a > teaching perspective. > > Owen (repeating myself) Generally our IPv6 trainings are the first contact with IPv6 for some network guys. Their biggest difficulties generally lies in understanding the IPv6 addresses. The types of addresses, where to use each of them, the new format, etc. From a didactic point of view, it would be a bad idea to use ULAs and tell them: please don't forget to pretend that this ULA block is our Global Unicast block, and this other ULA prefix will be the "real" ULA in our lab. Something looking more like GUAs would be better. The prefix 2001:db8::/32 do represent GUAs in documentation. It is difficult to convince people that private addresses and NATs are not to be used in all situations. Using ULAs in the labs, instead of Globals, would not help. I fear that using ULAs would result in people used to see them in the wrong places, and could lead us to a situation where some networks would finish having just ULA addresses (and NAT66) in scenarios where it would not be the better choice. I would prefer to choose an arbitrary prefix, inside or outside 2000::/3, but that "looks like" a GUA, than use ULAs in the classes. Moreiras. > > On Aug 12, 2013, at 1:30 PM, "George, Wes" > wrote: > >> >> *From:* Owen DeLong [mailto:owen@delong.com ] >> >> Because in some cases, the lab is also teaching about ULA+GUA >> configurations. >> >> */[WEG]/* I don’t follow your logic. 2001:db8::/32 is not GUA, nor >> would any such documentation prefix be –quite the contrary, in fact. >> It just happens to come from 2000::/3 so it **looks** more like GUA, >> but the network behavior is no different. >> >> Wes >> >> On Aug 12, 2013, at 13:05 , "George, Wes" > > wrote: >> >> >> >> *From:* v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org >> ] *On Behalf Of *Carlos Martinez-Cagnazzo >> >> >> >> As far as I understand, Antonio does some training involving 6RD >> deployments, where each 'team' needs its own /32. There might be other >> cases though, like for example doing some work involving BGP routing >> between different teams and for which you expect each one of them to >> carve a /32. >> */[WEG] /*and that environment can’t use ULA because….? >> >> Not saying that there aren’t legitimate cases when having more than >> /32 of documentation space might be useful, just saying that I don’t >> believe the needs of a lab environment (even in the context of >> training) is necessarily one of them. >> >> Wes George >> Anything below this line has been added by my company’s mail server, I >> have no control over it. >> ----------------- >> >> ------------------------------------------------------------------------ >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject >> to copyright belonging to Time Warner Cable. This E-mail is intended >> solely for the use of the individual or entity to which it is >> addressed. If you are not the intended recipient of this E-mail, you >> are hereby notified that any dissemination, distribution, copying, or >> action taken in relation to the contents of and attachments to this >> E-mail is strictly prohibited and may be unlawful. If you have >> received this E-mail in error, please notify the sender immediately >> and permanently delete the original and any copy of this E-mail and >> any printout. From marka@isc.org Mon Aug 12 15:31:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A5021F9AED for ; Mon, 12 Aug 2013 15:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, MANGLED_SMALL=2.3, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id livxtaCjU5aq for ; Mon, 12 Aug 2013 15:30:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C05FD21F99CF for ; Mon, 12 Aug 2013 15:30:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6548DC9494; Mon, 12 Aug 2013 22:30:39 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376346653; bh=dGpSh3kX2e0sSB666HRrMWNqdlYnojQ4WRCt/tPrH8E=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=FgfmQCT4P7fN9JOk1n2eNowBdPC+W8NoQos9mpG/rteA4b5F03xvig9vaC1WrssuV RvcXFTU0CmLJXEHwFVeEnQ6yjtWhTDjexmWxPb7jWfY0cApG49LMrv6Vu5PUy/q0sY /bjRnbRFzkWjBSwQM59kcc5IFRuP8C0mNnnMJSoY= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 12 Aug 2013 22:30:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D407316042F; Mon, 12 Aug 2013 22:35:18 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id j2gsim-mNO3E; Mon, 12 Aug 2013 22:35:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0621C160431; Mon, 12 Aug 2013 22:35:18 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 9518016042F; Mon, 12 Aug 2013 22:35:17 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id B5F793845539; Tue, 13 Aug 2013 08:30:35 +1000 (EST) To: Bill Jouris From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> <1376330247.41781.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-reply-to: Your message of "Mon, 12 Aug 2013 10:57:27 -0700." <1376330247.41781.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Tue, 13 Aug 2013 08:30:35 +1000 Message-Id: <20130812223035.B5F793845539@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:31:04 -0000 In message <1376330247.41781.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>, Bill Jouris writes: > --===============0047193473602130639== > Content-Type: multipart/alternative; boundary="1510626085-1351415829-1376330247=:41781" > > --1510626085-1351415829-1376330247=:41781 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable Bill replace your MUA with one that DOES printed-quotable CORRECTLY. This garbage is not correct. > > From: Owen DeLong =0A> To: Mark Andrews = > =0A> Cc: Alejandro Acosta ; v6ops@ietf.org =0A> Sen= > t: Monday, August 12, 2013 10:00 AM=0A> Subject: Re: [v6ops] draft-moreiras= > -v6ops-rfc3849bis-00=0A =0A>=0A>> =0A>> All a documentation prefix will do = > is have one potentially toxic=0A>> prefix compared to a handful of potentia= > lly toxic prefixes.=A0 There=0A>> are 1099511627776 prefixes in fd00::/8.= > =A0 Even if there were thousands=0A>> of documentation prefixes the odds of= > you hitting one when generating=0A>> your own prefix are astronomically sm= > all.=A0 Additionally the more=0A>> prefixes that are used in documentation = > the less toxic a particular=0A>> prefix will be.=0A=0A> No, it will also he= > lp to constrain such errors to an easily identifiable single=0A> prefix whi= > ch will make the errors easier to identify and correct. This is, IMHO,=0A> = > a worth while goal in the real world where operators actually run networks= > =0A> and have to deal with less than ideally trained predecessors and colle= > agues.=0A>=0A> Owen=0A=0AOne other thing: if you have a single documentatio= > n prefix, you can actually build that knowledge into your firewalls and rou= > ters -- meaning that anyone who does a copy without change will immediately= > find that his addresses simply don't work.=A0 Making that particular error= > essentially self-correcting,=0A=0ABill Jouris=0AInside Products, Inc.=0Aww= > w.insidethestack.com=0A831-659-8360=0A925-855-9512 (direct)=0A > > From: Owen DeLong > > To: Mark Andrews > > Cc: Alejandro Acosta ; v6ops@ietf.org > > Sent: Monday, August 12, 2013 10:00 AM > > Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 > > > > >> > >> All a documentation prefix will do is have one potentially toxic > >> prefix compared to a handful of potentially toxic prefixes. There > >> are 1099511627776 prefixes in fd00::/8. Even if there were thousands > >> of documentation prefixes the odds of you hitting one when generating > >> your own prefix are astronomically small. Additionally the more > >> prefixes that are used in documentation the less toxic a particular > >> prefix will be. > > > No, it will also help to constrain such errors to an easily > identifiable single > > prefix which will make the errors easier to identify and correct. This > is, IMHO, > > a worth while goal in the real world where operators actually run > networks > > and have to deal with less than ideally trained predecessors and > colleagues. > > > > Owen > > One other thing: if you have a single documentation prefix, you can > actually build that knowledge into your firewalls and routers -- meaning > that anyone who does a copy without change will immediately find that his > addresses simply don't work. Making that particular error essentially > self-correcting, For Locally Assigned ULA you default to filtering *all* prefixes. ULA is not the same as GUA. You can't just plug sites together without *first* checking for collisions in ULA space like you can with GUA. It is a recipe for disaster if you don't check. A-B-C-A will work if you just want to talk to your direct neighbors. If it is a federation you need to get one or both of the A's to renumber and you also need someone/thing to ensure uniqueness within the federation. > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From moreiras@nic.br Mon Aug 12 15:32: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 E112221F9FA4 for ; Mon, 12 Aug 2013 15:32:46 -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, 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 YQzen6BeWvdi for ; Mon, 12 Aug 2013 15:32:46 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id C9CBF21F99CF for ; Mon, 12 Aug 2013 15:32:45 -0700 (PDT) Received: from moreiras.in.nic.br (unknown [IPv6:2001:12ff:0:5::96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id B265C2080129; Mon, 12 Aug 2013 19:32:44 -0300 (BRT) Message-ID: <5209628C.90104@nic.br> Date: Mon, 12 Aug 2013 19:32:44 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812220733.C5E993845404@drugs.dv.isc.org> In-Reply-To: <20130812220733.C5E993845404@drugs.dv.isc.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:32:47 -0000 On 12/08/13 19:07, Mark Andrews wrote: > In message , Owen DeLong writes: >> >> On Aug 11, 2013, at 16:41 , Antonio M. Moreiras wrote: >> >>> On 11/08/13 19:29, Owen DeLong wrote: >>>> I support the idea. It might be worth also asking for a ULA Doc slice at the same time. >>>> I think a /48 is probably sufficient for most ULA examples. >>>> >>>> But I think it would be good to be able to write up ULA examples and training that use >>>> actual ULA prefixes intended for documentation. >>> >>> I agree. An organization could generate an ULA prefix specifically to >>> use in a course, or document. But it could be copied and used in >>> production environments. This would break the "global uniqueness", and >>> could lead to other problems. It would be nice to have a specific ULA >>> documentation prefix. >>> >>> I would suggest a prefix with the L bit cleared, easy to remember, and >>> maybe slightly shorter than /48. For example FC00:0:D0C0::/44. >>> >>> []s >>> Moreiras. >> >> That would certainly be an acceptable solution as far as I am concerned. > > So you would use a Centrally Assigned ULA to document Locally Assigned ULAs? > What are you smoking today? The is a BIG NOOOOOOOOOOOOOOOOOOOO!!!!!!!!!! Why not? The use cases for Locally Assigned ULAs, and Centrally Assigned ULA are the same. Asking IANA to assign an ULA prefix to a specific use (documentation) would not be, by definition, a central assignment? >> Owen From owen@delong.com Mon Aug 12 16:00: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 C64B711E80ED for ; Mon, 12 Aug 2013 16:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IZ-kA2tawwM for ; Mon, 12 Aug 2013 16:00:39 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD911E80E0 for ; Mon, 12 Aug 2013 16:00:39 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7CMxPL0020609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 15:59:25 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CMxPL0020609 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376348366; bh=VJYxIOZdrExGvfTROr2mWQH+308=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cZ1Rb1BT+ypz2H9B7r6rcblf8T7uuVfb0HwJnhZ6WjdG8HL4VDRWLXTCKP1PBNeXw oa9iCTho0UlOpYNLJCpbc4zzRs3GDTEuVhOQjRfHY3ixZ0P9OZdTIB0O86yNummOBG 4BARclrtzB73eIVrBh0LV5a6qecSAmL+t/a3xWIA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <20130812220439.1295538453A1@drugs.dv.isc.org> Date: Mon, 12 Aug 2013 15:59:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> <20130812220439.1295538453A1@drugs.dv.isc.org> To: Mark Andrews 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]); Mon, 12 Aug 2013 15:59:26 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 23:00:40 -0000 >> I disagree. See my previous message. It has helped in IPv4 and I see >> no reason it would not help in IPv6. > > Sorry Owen, you need to apply IPv6 think, in particular ULA think > to the problem space which is different to both IPv4 think and > general IPv6 think. Stating that without specifics is useless. >> It may not do much to prevent mistakes, but it makes them much easier >> to identify and resolve. > > Copying a documentation prefix is NOT a error. If you use it in a real world network, yes, it is. > And I'm sure you will see routes leaked for fc00::/7 as well. Those > leaks do not in general cause problem for anyone but the leakers > themselves. The fact that people leak has nothing to do with > documentation prefixes. It is proof that people do harmful things where the harm is easier to identify and mitigate if they are constrained to obviously visible and different from normal numbers. >>> All a documentation prefix will do is have one potentially toxic >>> prefix compared to a handful of potentially toxic prefixes. There >>> are 1099511627776 prefixes in fd00::/8. Even if there were thousands >>> of documentation prefixes the odds of you hitting one when generating >>> your own prefix are astronomically small. Additionally the more >>> prefixes that are used in documentation the less toxic a particular >>> prefix will be. >> >> No, it will also help to constrain such errors to an easily identifiable >> single >> prefix which will make the errors easier to identify and correct. This >> is, IMHO, >> a worth while goal in the real world where operators actually run networks >> and have to deal with less than ideally trained predecessors and >> colleagues. > > So a site has already choosen a ULA prefix that happens to match > the soon to be documention prefix. They have done NOTHING wrong. > It is causing NO operational problem. By creating a documentation > prefix and telling them it is a poision prefix you have just forced > them to renumber the moment they attempt to connect to anyone. If we choose the doc prefix from fc00::/8 and not from fd00::/8, then, that is not true. Since there is currently no accepted valid use for fc00::/8, and that space is intended to be globally coordinated if it is ever released, using it to create the doc prefix seems an entirely logical choice to me. > You are trying to solve a non existent problem. All you are doing > is saving the occasional site that was too stupid to pick a prefix > for themselves and copied one from some documentation from renumbering > when they connected to another site that was equally stupid and > copied from the same documention examples when ULA doesn't say you > won't have to renumber when you connect and exchange ULA routes. The problem exists, whether you accept that or not. Constraining the problem is useful to some and harmful to none. Unless you can show harm caused by allocating a prefix from fc00::/8 for documentation purposes, then I don't see the point of your continued argument. Owen From marka@isc.org Mon Aug 12 18:12: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 C645421F9F62 for ; Mon, 12 Aug 2013 18:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-E8TkPp3beZ for ; Mon, 12 Aug 2013 18:12:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id DA5CD21F9BDB for ; Mon, 12 Aug 2013 18:12:17 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 70073C94B2; Tue, 13 Aug 2013 01:12:04 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376356337; bh=/jBF8B3k5WWV3tpdzTk5crXSX42N6jPUqofKcpTRg1Y=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=RQoeGt+TRbDt8v6bMGcAX4fFgj2mvVGmNbHAHpgOYIwqqYBlwj5VzBlKwixnZoW7Y 0XQVTJbuz6FFOhbhLqdc6blc6EMrFbvkfF/eS94LvUDM+CT+YYwKb0HIpNt02N+ZRj 8DPgoRS5POfUvpaJucKZrnG0MGguRspj8Nx/A6ZM= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 01:12:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 60A4E160436; Tue, 13 Aug 2013 01:16:44 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5KyZ9uJUkGZY; Tue, 13 Aug 2013 01:16:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B373C160435; Tue, 13 Aug 2013 01:16:42 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8236F16042F; Tue, 13 Aug 2013 01:16:42 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 901293846308; Tue, 13 Aug 2013 11:12:00 +1000 (EST) To: "Antonio M. Moreiras" From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <52082128.5090503@nic.br> <20130812220733.C5E993845404@drugs.dv.isc.org> <5209628C.90104@nic.br> In-reply-to: Your message of "Mon, 12 Aug 2013 19:32:44 -0300." <5209628C.90104@nic.br> Date: Tue, 13 Aug 2013 11:12:00 +1000 Message-Id: <20130813011200.901293846308@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 01:12:23 -0000 In message <5209628C.90104@nic.br>, "Antonio M. Moreiras" writes: > On 12/08/13 19:07, Mark Andrews wrote: > > In message , Owen DeLong writes: > >> > >> On Aug 11, 2013, at 16:41 , Antonio M. Moreiras wrote: > >> > >>> On 11/08/13 19:29, Owen DeLong wrote: > >>>> I support the idea. It might be worth also asking for a ULA Doc slice at the same time. > >>>> I think a /48 is probably sufficient for most ULA examples. > >>>> > >>>> But I think it would be good to be able to write up ULA examples and training that use > >>>> actual ULA prefixes intended for documentation. > >>> > >>> I agree. An organization could generate an ULA prefix specifically to > >>> use in a course, or document. But it could be copied and used in > >>> production environments. This would break the "global uniqueness", and > >>> could lead to other problems. It would be nice to have a specific ULA > >>> documentation prefix. > >>> > >>> I would suggest a prefix with the L bit cleared, easy to remember, and > >>> maybe slightly shorter than /48. For example FC00:0:D0C0::/44. > >>> > >>> []s > >>> Moreiras. > >> > >> That would certainly be an acceptable solution as far as I am concerned. > > > > So you would use a Centrally Assigned ULA to document Locally Assigned ULAs? > > What are you smoking today? The is a BIG NOOOOOOOOOOOOOOOOOOOO!!!!!!!!!! > > Why not? The use cases for Locally Assigned ULAs, and Centrally Assigned > ULA are the same. Asking IANA to assign an ULA prefix to a specific use > (documentation) would not be, by definition, a central assignment? Actually the use cases are different. One you have a risk of collision when combining nets, the other you don't if assignments are done correctly. One you can't publish safely in the global DNS using AAAA, the other you can. etc. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Aug 12 20:30:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6111E8118 for ; Mon, 12 Aug 2013 20:30:51 -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 lbQAS+zQaE2e for ; Mon, 12 Aug 2013 20:30:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 8C48A11E811B for ; Mon, 12 Aug 2013 20:30:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8BCB2C9425; Tue, 13 Aug 2013 03:30:32 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376364644; bh=nAkBJF/MRfiqsMmrb+qxxLNFxzHD5ePUP5mE2j9TahY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=j8Np34meHmxF5EcIrCeh7mbrb/cFlWlwytuV6JwYLH2670UiG5/LlKJ32G4TGZrf7 OvdaCjoqfS6LK5IcKEwUHO5DH5QCOHEnVqo9G3jAH7jwlgjO0ax8EGr5Q21XGwb36e ZpoJm8jceuNvX3K71FJB6n3CJQ+RaTk87dagG0h0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 03:30:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DEB81160436; Tue, 13 Aug 2013 03:35:12 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id aQmZ1J1lniOe; Tue, 13 Aug 2013 03:35:12 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 98410160435; Tue, 13 Aug 2013 03:35:12 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 6914D16032F; Tue, 13 Aug 2013 03:35:12 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 918353846F7A; Tue, 13 Aug 2013 12:53:36 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> In-reply-to: Your message of "Mon, 12 Aug 2013 15:04:47 -0700." <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> Date: Tue, 13 Aug 2013 12:53:36 +1000 Message-Id: <20130813025336.918353846F7A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 03:30:51 -0000 In message <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com>, Owen DeLong writes: > Given the wide prevalence of RFC-1918 islands that were merged with > double NATs instead of repaired in the IPv4 world (which I believe = > likely > outnumber the number of environments where one or the other entity > was actually renumbered into non-conflicting space), I think we have > strong evidence that this is not true. And how many RFC-1918 islands had alternate address space to renumber into? How many RFC-1918 islands started out knowing they would have to renumber if there was a collision when they connected to someone else? How many RFC-1918 islands were designed to run with multiple addresses per interface from day one? How many RFC-1918 islands run dual IPv4 addressed? Now ask the same questions of ULA islands. You have different solutions available with ULA than you do with RFC-1918. NAT is not required to fix ULA collisions. ULA sites with collisions don't even need to renumber out of the colliding prefixes if they don't want to. Mark > I would consider using double NAT not a repair, but a workaround which > has significant adverse consequences. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Aug 12 20:50: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 A3E8111E8122 for ; Mon, 12 Aug 2013 20:50:55 -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 dSDxU8yfn3ll for ; Mon, 12 Aug 2013 20:50:50 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 19FEE11E8118 for ; Mon, 12 Aug 2013 20:50:45 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D3BA9C941E; Tue, 13 Aug 2013 03:50:31 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376365845; bh=pE4EeBFtZHkOhWwy3JdCZ/MjqmdCnEgtZqBpXU/9k60=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=hpZJxCs6PY4hxK4JeTHUHsXZQHwNmMay7otZoY0MWMMkggcilNyaBunqCHfkJRMdq LoQeadSq6rCB+tDqClTbSaQTb8B6KzU9Ma+lWv8FCHqtx9RXr92I2nWDjb6VyDbP1h Q5fx9MwpNUon/OE2UgFveYbuIGgfeTHACl9LqVlo= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 03:50:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 459D0160436; Tue, 13 Aug 2013 03:55:12 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BTywuVkLLaW2; Tue, 13 Aug 2013 03:55:12 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EAF65160435; Tue, 13 Aug 2013 03:55:11 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id BC83216032F; Tue, 13 Aug 2013 03:55:11 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 284513846C3D; Tue, 13 Aug 2013 12:34:17 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> <520945FF.4000700@gmail.com> In-reply-to: Your message of "Tue, 13 Aug 2013 08:30:55 +1200." <520945FF.4000700@gmail.com> Date: Tue, 13 Aug 2013 12:34:17 +1000 Message-Id: <20130813023417.284513846C3D@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 03:50:55 -0000 In message <520945FF.4000700@gmail.com>, Brian E Carpenter writes: > On 12/08/2013 17:27, Arie Vayner (avayner) wrote: > > Owen, > > > > While the arguments about moving the firewalls closer to the users are valid they are often are not practical (or at least the cus > tomers I worked with would not implement this option). > > Imagine an enterprise network with 300 spoke sites, but only 2 or 3 Internet gateway locations (with some private WAN in between). > > Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale > for a second)... This is a major CAPEX and OPEX impact... > > Clearly DOS and scanning protection has to be done as close to the Internet > border routers as possible, and there your logic applies. > > However, as Steve Bellovin pointed out many years ago, the best number of > firewalls for upper layer protection is one per host, which scales nicely > and has less CAPEX and OPEX than middlebox firewalls will ever have. > > Not that I see any of this argument as relevant to the IP version number. > > Brian IP version number brings with it a different set of minimums that nodes / hosts have or should have if the manufacturers were paying attention as we learnt how not to do thing in IPv4. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Mon Aug 12 21: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 DF27221E80A7 for ; Mon, 12 Aug 2013 21:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[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 DblpUnmQItT1 for ; Mon, 12 Aug 2013 21:07:35 -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 1CFFC21E809E for ; Mon, 12 Aug 2013 21:07:34 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id aq17so9261333iec.25 for ; Mon, 12 Aug 2013 21:07: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=7m3nqI/Hmxh9nATC+EjP/ssD8wxS3swxbfMU1mOrdkA=; b=ipR5zYfdtucICDkFDRsIVLwfeSLycHlZYiVhm9CO315FTWUO2QXEk/PTTJ/JWkNBkz nbrpQKVJjS3dSCpRPx7tD0keekuJ1qoFWeHWlnTPviea/YlBGFIbvnFLzQz2XsZ144kx C4zCz50b2CxEHt5wGjbSXqVYCiz3AeAR6kxRTtH2Th3p64f/kas8kwZHaXCigAH2Vu9T KrREGx14B5wsoi9a8WKzBh7K3/ZxVuiIWCPWv2eJ3BQ4uS547m+sr/oUGXp8/er1DDeR UW2uFDYf0+ngkF+dIMhJdVwqn7RBOiBqStgJUwBBESLMLcmDgBgL4JtUK33sCP/Ao8hh l+jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7m3nqI/Hmxh9nATC+EjP/ssD8wxS3swxbfMU1mOrdkA=; b=YvnYZybdMoNDl5gfCCgUM5vwZQHCdTHgzQjxyU9KLgOJU4CF6JoM7gNSqUGhYeJVp4 WV1cAg8VQFb9JAVCndInTZK4brXSOqiLqvnW0Yi6qTqH9qUpIdaZWKdLGRzijE5ybqN9 5H7exEDxXHTT8ratXoT/rCeeke0y44YUX2oZqNidrqCr9r9ugShyjg/K96dadFmlo4O1 2NvL88jSmFG8EYDCNEFTV+gpAtnhzrVfSJlULXZgE8udtFKMi1X2t55SN/Qv9r11mJ1s /6rWrpbt+3NFrcwiUcls3f200Tqzdztdq2x4ivhVKcGJag9FoTNvF9PPS+M0Yp2IF2Rk Nhcg== X-Gm-Message-State: ALoCoQmgY6jvpBSwluVC4lFbrUWnpspmVNdqyot/CijB3ejkIr0WzB47OII17lH4tNdOeu4wPfU2fNBDdsnw3JDqLOHakcBGOTEDDQzLCo4EdA3bT7Cxe8F7Pu6Nb6us3eETNRApUcWMM19aiex7Xk+LR6z9RyLYwyUUtdhMdB9SDoSfX1o9r5ib6vpg3L5xOH9BCNAWfapU X-Received: by 10.50.1.20 with SMTP id 20mr1308107igi.56.1376366854621; Mon, 12 Aug 2013 21:07:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.181.72 with HTTP; Mon, 12 Aug 2013 21:07:14 -0700 (PDT) In-Reply-To: References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> From: Lorenzo Colitti Date: Tue, 13 Aug 2013 13:07:14 +0900 Message-ID: To: "Arie Vayner (avayner)" Content-Type: multipart/alternative; boundary=e89a8f64303473715504e3cc619a Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 04:07:36 -0000 --e89a8f64303473715504e3cc619a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2013 at 2:34 AM, Arie Vayner (avayner) w= rote: > Actually, you can use NPTv6 to protect against it=85 **** > > If I have an external pool per site, traffic egressing that site would ge= t > a source routed back only to that site=85 Am I missing something? > As I said, NPTv6 by itself doesn't protect against this problem. It only protect against this problem if each egress point is only reachable using one prefix, and all the prefixes are different. To people used to deploying NAT44 networks, this will likely be the only deployment model that comes to mind, and thus it will appear to them that NPTv6 does solve this problem. But in fact, NPTv6 was supposed to be deployed statelessly. The very first words of RFC6296 are "This document describes a stateless [...] function [...] preserving end-to-end reachability at the network layer.". In the introduction, it then goes on to say it "this specification provides a mechanism that has fewer architectural problems than merely implementing a traditional stateful NAT". If you were to deploy it statelessly, you would have this problem. The interesting point here, really, is that when the IETF says "NPTv6" people hear "NAT66", when in fact they are supposed to be different. Out of curiosity: Fred, as the co-author of RFC 6296, were you anticipating that people would do this? Or was the belief actually that people would understand the difference? --e89a8f64303473715504e3cc619a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 13, 2013 at 2:34 AM, Arie Vayner (avayner) <a= vayner@cisco.com> wrote:

Actually, you can use NPTv6 to protect against it=85

If I have an external pool per site, traffic egressin= g that site would get a source routed back only to that site=85 Am I missin= g something?

As I said, NPTv6 by itself doesn't protec= t against this problem.

It only protect against th= is problem if each egress point is only reachable using one prefix, and all= the prefixes are different. To people used to deploying NAT44 networks, th= is will likely be the only deployment model that comes to mind, and thus it= will appear to them that NPTv6 does solve this problem.

But in fact, NPTv6 was supposed to be deployed stateles= sly. The very first words of RFC6296 are "This document describes a st= ateless [...] function [...] preserving end-to-end reachability at the netw= ork layer.". In the introduction, it then goes on to say it "this= specification provides a mechanism that has fewer architectural problems t= han merely implementing a traditional stateful NAT". If you were to de= ploy it statelessly, you would have this problem.

The interesting point here, really, is that when the IETF says &qu= ot;NPTv6" people hear "NAT66", when in fact they are suppose= d to be different. Out of curiosity: Fred, as the co-author of RFC 6296, we= re you anticipating that people would do this? Or was the belief actually t= hat people would understand the difference?
--e89a8f64303473715504e3cc619a-- From markzzzsmith@yahoo.com.au Mon Aug 12 21: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 7DC3921F9EC4 for ; Mon, 12 Aug 2013 21:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTslqm-HDgiD for ; Mon, 12 Aug 2013 21:54:34 -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 F1E6821F9E33 for ; Mon, 12 Aug 2013 21:54:33 -0700 (PDT) Received: from [98.139.215.140] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 04:54:25 -0000 Received: from [98.139.212.248] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 04:54:25 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 04:54:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 29385.2094.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 74506 invoked by uid 60001); 13 Aug 2013 04:54:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1376369664; bh=FNX5vDsG72zH8E2Vf3wXhziEXLrf37GpRSjni5ySBRU=; 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=AyVGsUqLTFyhA9Mpu+GfLM/oYOGGRLFs1gbtQRuFC/gGPWPBNuYyh7iYBJXPs7/NyRkISpcih3tJUwSM2aht/8YQv4ckZISO4z4k+mCIs/oNzW645fGUtEBfOtClIrOfNVUAjRtj691weZb9FCICB/E9enN43hY3RcvQG3TYCQA= 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=uB5pHZZ18kDUWOkUNPl+M51WpCdmikWoHBU3FLalfzESc2vmA36eVaH8bMK1YmSKO3d0CWEc4JkkwfqNs2tdPe5kdrrgzhqMIREcfdL/5C0h4hvPoab6fIirjyoEway47X99tNnqwqmofNeqwAiZgF1YGYqBFKSX/TDMAlzutf8=; X-YMail-OSG: rf.ZYtwVM1k.ybyz_aSDWPyTqjx_.VKG0hXmqtes0VKkdro 6vrngQDJvpwJpPaCimUhtsRi2RpjGSX1I7mFZyCwT5W5_QxVj7XE4C9pTvV4 QSgm_OrYtmzniYKOzuqET7Wz.tmITUnwe5.acLBdwa53A_dVZMLFFFViadB_ rLw5HPyI4zIQV0bBNKHAMJm67n7SA.jhLQwktmo1EFJo2ZZu7XiZp9Ay73V. 0IkehdV5eQ540pkkARsPsE9t8OolPS4fdrYFfkHZOswTgVTXncuZ8ictX8cy gqpcaI0VQVrg0NTmZPQMK9BngYrHiFCx8jVImI4_4qWCWLOMWXc_WwWCJtaq gOaKONbCJdUgqZifet30jAdN7096TdE7bZzFQEm2YtqoWKRm1Ivk3YPhTUCF gVo5CUPri0eMLXCN4g8qMfNUaBnqU1uw.PRY_.wpKeBgnyY.pvC7Z9eAN3u9 DTiCor_GUhzMnKPer2tS7JEaIeuclnSerfRv3nLqtuudA_Hw_1zGJwXBqad6 vjo3SEX1kfNnOJMjNFdQBvSWRhLvn7OnnHvfV9_2kBS.U.gdNiFrRrZRALPG yi38dEj6ls0h.mScQ7IOdL_Mzt4qXwueet_crGElnFIM- Received: from [118.208.74.180] by web142504.mail.bf1.yahoo.com via HTTP; Mon, 12 Aug 2013 21:54:24 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBBcmllIFZheW5lciAoYXZheW5lcikgPGF2YXluZXJAY2lzY28uY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBUdWVzZGF5LCAxMyBBdWd1c3QgMjAxMyA2OjMwIEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1lbnRlcnByaXNlLWluY3JlbWVudGFsLWlwdjYgV0dMQwoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> <520945FF.4000700@gmail.com> Message-ID: <1376369664.37168.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Mon, 12 Aug 2013 21:54:24 -0700 (PDT) From: Mark ZZZ Smith To: Brian E Carpenter , "Arie Vayner \(avayner\)" In-Reply-To: <520945FF.4000700@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 04:54:39 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Arie Vayner (avayner) = =0A> Cc: "v6ops@ietf.org" =0A> Sent: Tuesday, 13 August 201= 3 6:30 AM=0A> Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-= ipv6 WGLC=0A> =0A> On 12/08/2013 17:27, Arie Vayner (avayner) wrote:=0A>> = Owen,=0A>> =0A>> While the arguments about moving the firewalls closer to = the users are =0A> valid they are often are not practical (or at least the = customers I worked with =0A> would not implement this option).=0A>> Imagin= e an enterprise network with 300 spoke sites, but only 2 or 3 =0A> Internet= gateway locations (with some private WAN in between).=0A>> Moving the fir= ewalls to the spoke sites would increase the number of =0A> firewalls from = ~3 to ~300 (I am ignoring redundancy and scale for a second)... =0A> This i= s a major CAPEX and OPEX impact...=0A> =0A> Clearly DOS and scanning protec= tion has to be done as close to the Internet=0A> border routers as possible= , and there your logic applies.=0A> =0A> However, as Steve Bellovin pointed= out many years ago, the best number of=0A> firewalls for upper layer prote= ction is one per host, which scales nicely=0A> and has less CAPEX and OPEX = than middlebox firewalls will ever have.=0A>=A0=0A=0AHost based firewalling= by default has also pretty much been reality for most devices for the last= 5+ years, if not much longer (Windows XP Service Pack 2 provided and enabl= ed by default a host firewall in around 2004).=A0I think the reality today = is that vendors assume that if a device could be plugged directly into the = Internet it probably will be, and therefore they provide and enable host ba= sed firewalls by default.=0A=0AIt seems common for the people who make the = above argument to be the same people who are facilitating direct attachment= of hosts to untrusted and uncontrolled networks by providing laptops inste= ad of desktops, organising 3G/4G dongles for those laptops, and allowing ra= ther than prohibiting people from taking those laptops home, to conferences= , cafes and hotels. Fortunately their OS vendors have taken care of enablin= g host protection on their behalf.=0A=0A> Not that I see any of this argume= nt as relevant to the IP version number.=0A>=A0=0A=0AAgree.=0A=0A> =A0 Bri= an=0A> =0A>> Arie=0A>> =0A>> From: Owen DeLong [mailto:owen@delong.com]= =0A>> Sent: Friday, August 9, 2013 12:17 PM=0A>> To: Arie Vayner (avayner= )=0A>> Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); =0A>= v6ops@ietf.org=0A>> Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incr= emental-ipv6 WGLC=0A>> =0A>> =0A>> On Aug 8, 2013, at 22:21 , Arie Vayner = (avayner) =0A> > wrote:=0A>> = =0A>> =0A>> Another loosely related point that I think could make sense in= such a =0A> document would be the ways to accomplish multi-homing and how = it is different =0A> than today's IPv4 implementations.=0A>> =0A>> Many en= terprises rely on NAT on the Internet edge as their =0A> multi-homing/traff= ic engineering mechanism with IPv4.=0A>> =0A>> If we recommend against ULA= +NPTv6 (or just NPTv6 for traffic engineering), =0A> then we need to highli= ght the symmetry requirement due to stateful security =0A> layers.=0A>> Tr= affic leaving from an Internet gateway site to the Internet has to come =0A= > back through the same site, or the stateful firewalls would break the flo= w =0A> (well, has to hit the same stateful security layer)=0A>> =0A>> Or s= tateful firewalls have to get better about sharing state. There are two =0A= > things that can help with this...=0A>> =0A>> 1.=A0 =A0 =A0 =A0 Put your= firewalls as close to the end systems they protect as =0A> possible. Make = your security zones relatively small and place the firewalls =0A> closer to= gether at those narrower borders.=0A>> =A0 =A0 =A0 =A0 =A0 =A0 This will o= ften require more firewall units, but it helps in a =0A> number of ways:=0A= >> =A0 =A0 =A0 =A0 =A0 =A0 A.=A0 =A0 =A0 =A0 Firewall policy tends to be m= uch simpler (and as a =0A> result less error prone and more reliable)=0A>> = =A0 =A0 =A0 =A0 =A0 =A0 B.=A0 =A0 =A0 =A0 The hardware demands on the fire= wall tend to be lower =0A> so you can buy cheaper units.=0A>> =A0 =A0 =A0 = =A0 =A0 =A0 C.=A0 =A0 =A0 =A0 The simpler rulesets can be more easily tail= ored to =0A> meet business requirements as they evolve.=0A>> =0A>> =0A>> = =0A>> 2.=A0 =A0 =A0 =A0 Improve firewalls. Give the firewalls that all pr= otect the same =0A> boundary a way to mesh-peer with each other and exchang= e information about the =0A> state tables such that triangle routing is no = longer problematic.=0A>> =0A>> =0A>> Syncing upstream and downstream routi= ng policies is not always an easy task =0A> (but could be relevant in some = cases).=0A>> Linking the Internet gateway layer across sites (before hitti= ng the =0A> stateful security layer) could be another solution.=0A>> =0A>> = If we make the changes above to the firewalls, this could be=A0 a lot less= =0A> relevant in most cases.=0A>> =0A>> =0A>> Do you think a short discus= sion to raise awareness for this potential issue =0A> could be relevant in = such a document?=0A>> =0A>> It's certainly worth documenting. I'm not sure= whether it belongs =0A> in this document or not.=0A>> =0A>> Owen=0A>> =0A= >> =0A>> =0A>> =0A>> =0A>> -----------------------------------------------= -------------------------=0A>> =0A>> _____________________________________= __________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.= ietf.org/mailman/listinfo/v6ops=0A> _______________________________________= ________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org= /mailman/listinfo/v6ops=0A> From owen@delong.com Mon Aug 12 21:56: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 8F82821E80BB for ; Mon, 12 Aug 2013 21:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQhbgbweMp6Z for ; Mon, 12 Aug 2013 21:56:19 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF121E80AC for ; Mon, 12 Aug 2013 21:56:16 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7D4qWw9032357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 21:52:32 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7D4qWw9032357 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376369557; bh=Y/ptHHLcnbL7XU4/xgqRxQKXzl4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3SkD7K3T05QieopWXWnk5nRV05uTzrvsoNhfy2atK5fqSYqkARW7j+Trj0b5l12jY EL6MD7KcPEHbBsoSLgv997tGf3KZ5OKfvIbiwJ3moapwGO5PRoGAnOzHRCq9wVZpUM JbTzP/jE41jvBAxMdvBpthwTxzR4I4MG5hGVMCas= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <20130813025336.918353846F7A@drugs.dv.isc.org> Date: Mon, 12 Aug 2013 21:52:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> <20130813025336.918353846F7A@drugs.dv.isc.org> To: Mark Andrews 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]); Mon, 12 Aug 2013 21:52:37 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 04:56:24 -0000 On Aug 12, 2013, at 7:53 PM, Mark Andrews wrote: >=20 > In message <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com>, Owen = DeLong writes: >> Given the wide prevalence of RFC-1918 islands that were merged with >> double NATs instead of repaired in the IPv4 world (which I believe =3D >> likely >> outnumber the number of environments where one or the other entity >> was actually renumbered into non-conflicting space), I think we have >> strong evidence that this is not true. >=20 > And how many RFC-1918 islands had alternate address space to renumber > into? The vast majority of the ones I am aware of. Very few companies are = using all of the RFC-1918 space entirely. > How many RFC-1918 islands started out knowing they would have to > renumber if there was a collision when they connected to someone > else? Virtually all of them. > How many RFC-1918 islands were designed to run with multiple addresses > per interface from day one? A few, but not many. > How many RFC-1918 islands run dual IPv4 addressed? A few, but not many. > Now ask the same questions of ULA islands. You have different > solutions available with ULA than you do with RFC-1918. NAT is not > required to fix ULA collisions. ULA sites with collisions don't > even need to renumber out of the colliding prefixes if they don't > want to. 1. Same answer. 2. Same answer. 3. Admittedly, this is reversed, but I don't think that will make a = significant difference. 4. Admittedly, this is reversed, but I consider it pretty much identical = to question 3. NAT is not required to fix RFC-1918 collisions IN MOST CASES. It's = simply a lot more convenient (for the people making the decision) at the cost of = great woes for the people using the networks. So far, you've offered NOTHING to suggest that this would be different = with ULA. Owen From marka@isc.org Tue Aug 13 00:02: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 D014A11E8142 for ; Tue, 13 Aug 2013 00:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL+mdoda1w57 for ; Tue, 13 Aug 2013 00:02:16 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EF02811E8118 for ; Tue, 13 Aug 2013 00:02:15 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 92BB8C9425; Tue, 13 Aug 2013 07:02:01 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376377333; bh=Gn+pDHeDlOb/RPdDmbAdlvcg0Tdsxi1ZKyQsTXNIuu8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=SbMcdhX0L47ft1AQYGo4kHgvnwEw046iNScdvF6YMpyFNd56p/Kyczoj06o+vMyCc 9daaRYrb3pwtNUM3HLIwLRMgi+IMAvZ3nmeF5lPWViqOVIkN/gJypU6f7Zmdz2xkaW 4kdsej08fQN/JgXZk9vGI3lF6dKIO07cUSySRaxg= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 13 Aug 2013 07:02:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 934AB160438; Tue, 13 Aug 2013 07:06:42 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zWM5MjfeGxHu; Tue, 13 Aug 2013 07:06:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ECC961601E7; Tue, 13 Aug 2013 07:06:41 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B9EFA1601C2; Tue, 13 Aug 2013 07:06:41 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6D9D5384B2C5; Tue, 13 Aug 2013 17:01:57 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> <20130813025336.918353846F7A@drugs.dv.isc.org> <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com> In-reply-to: Your message of "Mon, 12 Aug 2013 21:52:32 -0700." <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com> Date: Tue, 13 Aug 2013 17:01:57 +1000 Message-Id: <20130813070157.6D9D5384B2C5@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 07:02:21 -0000 In message <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com>, Owen DeLong writes: > > On Aug 12, 2013, at 7:53 PM, Mark Andrews wrote: > > > > > In message <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com>, Owen > DeLong writes: > >> Given the wide prevalence of RFC-1918 islands that were merged with > >> double NATs instead of repaired in the IPv4 world (which I believe = > >> likely > >> outnumber the number of environments where one or the other entity > >> was actually renumbered into non-conflicting space), I think we have > >> strong evidence that this is not true. > > > > And how many RFC-1918 islands had alternate address space to renumber > > into? > > The vast majority of the ones I am aware of. Very few companies are using > all of the RFC-1918 space entirely. > > > How many RFC-1918 islands started out knowing they would have to > > renumber if there was a collision when they connected to someone > > else? > > Virtually all of them. > > > How many RFC-1918 islands were designed to run with multiple addresses > > per interface from day one? > > A few, but not many. > > > How many RFC-1918 islands run dual IPv4 addressed? > > A few, but not many. > > > Now ask the same questions of ULA islands. You have different > > solutions available with ULA than you do with RFC-1918. NAT is not > > required to fix ULA collisions. ULA sites with collisions don't > > even need to renumber out of the colliding prefixes if they don't > > want to. > > 1. Same answer. > 2. Same answer. > 3. Admittedly, this is reversed, but I don't think that will make a > significant difference. > 4. Admittedly, this is reversed, but I consider it pretty much identical > to question 3. > > NAT is not required to fix RFC-1918 collisions IN MOST CASES. It's simply > a lot > more convenient (for the people making the decision) at the cost of great > woes > for the people using the networks. > > So far, you've offered NOTHING to suggest that this would be different > with ULA. > > Owen With ULA you end up with: site1: P1, P2 announce P2 to site2 site2: P1, P3 announce P3 to site1 When you have two sites colliding on P1. (P1, P2 and P3 are different ULA prefixes). You have IP stacks that are designed to deal with multiple prefixes and to choose particular source addresses for particular destination addresses. You have applications that are designed to deal with multiple addresses. IPv4 only stacks don't have all of these features which forces one to use NAT. With IPv6 they are there so you can depend on them and take advantage of them. If P2 and P3 differ only in the 48th bit longest match will select the right source address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fred@cisco.com Tue Aug 13 05:45: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 5FC4F21E8125 for ; Tue, 13 Aug 2013 05:45:08 -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 oJVpePaiTJ8z for ; Tue, 13 Aug 2013 05:45:03 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A041121E80BA for ; Tue, 13 Aug 2013 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=148; q=dns/txt; s=iport; t=1376397903; x=1377607503; h=date:from:message-id:to:subject:cc; bh=rC8o26EcEy+8REy+Wav0AEulGLPBTyA3RweQHZHii4M=; b=mnWaD8xyZBxZNLIvegFz0fJvNztbzdj2dcnvq0j4kuxrG72WOIEAR9yy 1vdcTGGQNSn0Tcygw4COFSUZMx4DFPTpd0L/ngEBub5M1sqh+i1qk4FLw 1UDtBPPzfa4iJx3BXxJm36drkR2EbbMy4ejHRxXRQTjaUnS5wd/+Ssi5y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEHAPsoClKrRDoG/2dsb2JhbABbgwY1gyGqFAGRdYEiFnSDJDwtB4hwDbdokDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="86471698" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 13 Aug 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj0cd000773; Tue, 13 Aug 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0U27813; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0U27813@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-elkins-v6ops-ipv6-packet-sequence-needed@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-packet-sequence-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, 13 Aug 2013 12:45:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05:45: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 6906121E80BA for ; Tue, 13 Aug 2013 05:45:08 -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 HcsaXkZ10zHs for ; Tue, 13 Aug 2013 05:45:03 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B177921E812D for ; Tue, 13 Aug 2013 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1376397903; x=1377607503; h=date:from:message-id:to:subject:cc; bh=6yHygD4QgvVcEZAbQnJVUzBUf+YMwGkXg/hCZh2PRAw=; b=lYnywsA69ATxRXefSOycM3fIwQBbivJu9aodwO7v57sHyzvlSkCgeF8D 6pTXf3o1dziOGwZnmvIchA08+/Ye0q6YjL0VKjiyInYCTuLf8tQl0eGqD SaglwNUSGe7s5kMLgtvMPXDmKcplKz19rMsVu3JfBl6NSQM0+/pFvr4Eo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkOAPsoClKrRDoI/2dsb2JhbABbgwY1gyGqFAGRbQQDAYEiFnSDJDwtB4hwDbdokDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="86471700" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 13 Aug 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj1Us004567; Tue, 13 Aug 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0g27839; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0g27839@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-moreiras-v6ops-rfc3849bis@tools.ietf.org Subject: [v6ops] new draft: draft-moreiras-v6ops-rfc3849bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2013 12:45:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05:45: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 4D55111E816E for ; Tue, 13 Aug 2013 05:45:13 -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 ARClXIAjMwdG for ; Tue, 13 Aug 2013 05:45:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4421E812E for ; Tue, 13 Aug 2013 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139; q=dns/txt; s=iport; t=1376397903; x=1377607503; h=date:from:message-id:to:subject:cc; bh=s5Fa6LmdQ4J2FNx7RD6/1X4KdT0SgIjw9Wxzn20Y6a4=; b=dZG9fYyJnqcfdWxS1OySM8Cy+iD38PVlvK7sf4ieraB/GXnlLTRYszN5 6IKLM0MjExIOXZglROZirPDZWL8tpup8l3q18oXr6zGifshebAeILecPK Z4vugrRpEBWAIJf5x/6WaxG+fFdchk2lZNhqGZCxWbrjDWQkSDkjnR/Ty k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkOAPsoClKrRDoG/2dsb2JhbABbgwY1gyGqFAGRbQQDAYEiFnSDJDwtB4hwDbdokDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="86471701" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 13 Aug 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj1xi000778; Tue, 13 Aug 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0T27845; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0T27845@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-osamu-v6ops-ipv4-literal-in-url@tools.ietf.org Subject: [v6ops] new draft: draft-osamu-v6ops-ipv4-literal-in-url X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2013 12:45:13 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05:45: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 7D35311E8172 for ; Tue, 13 Aug 2013 05:45:13 -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 ZFzrxiGCOBRl for ; Tue, 13 Aug 2013 05:45:08 -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 D23D121E812F for ; Tue, 13 Aug 2013 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1376397904; x=1377607504; h=date:from:message-id:to:subject:cc; bh=OjjhQvyG5qR0ggDIrxt5TPcqdprWfvAN0mNPqaVvXrA=; b=K69l+961aXzK5o8cpJF9T2KRPshO6MIVwlEIq5QpsXDZtxoO57dnwZ0H MAwII8pdFXnSSDza9HMRUPzm9EBKg+z6YVLx58vOegfb1CQDfpAYoo+9h DPOUY/HzVJ2vElxSDfFVSaVdez5oSAChN+fgbqL65oVID//OIv5z1NkL3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkOAG0pClKrRDoI/2dsb2JhbABbgwY1gyGqFAGRbQQDAYEiFnSDJDwtB4hwDbdnkDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="88981215" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 13 Aug 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj1at004558; Tue, 13 Aug 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0k27831; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0k27831@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ma-v6ops-ipv6-address-assignment@tools.ietf.org Subject: [v6ops] new draft: draft-ma-v6ops-ipv6-address-assignment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:45:13 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ma-v6ops-ipv6-address-assignment. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05:45: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 0E23F21E813D for ; Tue, 13 Aug 2013 05:45:18 -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 hT8W85XNtqNf for ; Tue, 13 Aug 2013 05:45:13 -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 DC1CF21E8130 for ; Tue, 13 Aug 2013 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=143; q=dns/txt; s=iport; t=1376397904; x=1377607504; h=date:from:message-id:to:subject:cc; bh=fhmGd4h7xMwY4bsnTTiNa7inxmfjRUFW3hOX2IViOHs=; b=eic4R//Fo9jZJox6f7uVgSEaD6t7K6WPQAieFWxRDfsVvvrjSpNVG5DD uw0WbOd71RJ9XFkqAPXsDLA/bBg8bsyFXegx5U/cOYqH42WMs7dRKGkjf 9nXkRoS9zfv/wZo0t4q/9QDhwZJVwgFPAvLvrhuqbgbW4yYsNowqNqBmz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkOAG0pClKrRDoH/2dsb2JhbABbgwY1gyGqFAGRbQQDAYEiFnSDJDwtB4hwDbdnkDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="88981214" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 13 Aug 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj1wv032632; Tue, 13 Aug 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0727825; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0727825@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-liu-v6ops-running-multiple-prefixes@tools.ietf.org Subject: [v6ops] new draft: draft-liu-v6ops-running-multiple-prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2013 12:45:18 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05:45: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 5312821E813D for ; Tue, 13 Aug 2013 05:45:18 -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 BuH-XiLt5ucY for ; Tue, 13 Aug 2013 05:45:13 -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 1A16B21E80BA for ; Tue, 13 Aug 2013 05:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147; q=dns/txt; s=iport; t=1376397909; x=1377607509; h=date:from:message-id:to:subject:cc; bh=CFyW9IrWgyYurmP5qUK4MA42DmYZ7yekwU1u3/9+OYs=; b=Sm1URR8RPvaePMstETMXSmwmJp+0+uyyR8KV65fA3OudEnc8o3KY46Po l31GsjglapBnupRexvZbBFhp3Nzpyc3oV/6vvLlxI1mmJeSXgH1wVMlso fb2tp50bdwc2KpssEfeza0alLz5UMsklRWnE7L8qKUrSmcn9ubDRryW4m 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEHABoqClKrRDoI/2dsb2JhbABbgwY1gyGqFAGRdYEiFnSDJDwtB4hwDbdtkDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="85967560" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 13 Aug 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj0Pr004554; Tue, 13 Aug 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0u27819; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0u27819@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-elkins-v6ops-ipv6-pdm-recommended-usage@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-pdm-recommended-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2013 12:45:18 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-pdm-recommended-usage. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05:45: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 C125221E813F for ; Tue, 13 Aug 2013 05:45:22 -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 bdtUlk2nZl+v for ; Tue, 13 Aug 2013 05:45:18 -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 20B0621E8125 for ; Tue, 13 Aug 2013 05:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=142; q=dns/txt; s=iport; t=1376397909; x=1377607509; h=date:from:message-id:to:subject:cc; bh=2IRNuGUTUoYSetySJSRyIjE3YLM8ujlcmNXba/l7B0g=; b=OOkBaDPDm5R5M1KRaqTGEmXbI3+OXR8z/twaQaaYP1JYor7+GhqBsolH oP+jLd4JQFkS4FIh9xClNtL59TX1yo2paHoe0MdB92gdvWchn6BKyx845 S+lN23m5WjScxy7sUU2ppqyV5TBo+24kR+X3Vv+xcXMgOvvirOvzwqezy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkOABoqClKrRDoH/2dsb2JhbABbgwY1gyGqFAGRbQQDAYEiFnSDJDwtB4hwDbdtkDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="85967563" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 13 Aug 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj1C4032636; Tue, 13 Aug 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0k27851; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0k27851@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org Subject: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2013 12:45:22 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05:45: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 08A3D21E8125 for ; Tue, 13 Aug 2013 05:45:23 -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 JxAusil4taDJ for ; Tue, 13 Aug 2013 05:45:18 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 49F2B11E816D for ; Tue, 13 Aug 2013 05:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1376397913; x=1377607513; h=date:from:message-id:to:subject:cc; bh=MEOQzjmE1qNylBbHFR/arkEQqCl+SgGn74r7hnTIEuo=; b=iRjHYMUeMPH4x1bI8HSyQvvVZ+sGhml5qyeCtoOcvJ7SbSZVWXXYeBhn SHfmkEgpTXCNLQGI2ZKH6wFiojeSpl077LAJ7GTQkj6Xli/GyEz/zPz+9 pZ56n+aZaF+sM3sbOWnEkp1FDuXGh6TA4nQ8fYGCo/83IXNvwy2/yr47U 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkOABoqClKrRDoG/2dsb2JhbABbgwY1gyGqFAGRbQQDAYEiFnSDJDwtB4hwDbdtkDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="89044090" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Aug 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj0RE000761; Tue, 13 Aug 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0e27801; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0e27801@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:45:23 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis. Please take a look at it and comment. From fred@cisco.com Tue Aug 13 05: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 7741E21E8151 for ; Tue, 13 Aug 2013 05:45:27 -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 QKy1QgZ--A-m for ; Tue, 13 Aug 2013 05:45:22 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5682511E816F for ; Tue, 13 Aug 2013 05:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=146; q=dns/txt; s=iport; t=1376397913; x=1377607513; h=date:from:message-id:to:subject:cc; bh=Lh12eQGSOC8bsJXakkISHcNph3OXtiZ04KFi8s6qKp4=; b=OChJy3CntWiNzxLS942whdAs27xJ0s7AXZ2L5/rWO0YMgxAwgJ6NVod5 sZUwr0TWk5Md0FlxrXNMa/RjPleQLfux5qZSLJWvuRKmrEHtoseJhZhuW OhlGgFu9mRCxxKvPdhfco5gaCZgVeh/4SRkew8i4UgDl9lG7gtqkhStZX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkOABoqClKrRDoG/2dsb2JhbABbgwY1gyGqFAGRbQQDAYEiFnSDJDwtB4hwDbdtkDwdg3sDiS2PZJAkgzs X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="89044092" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Aug 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7DCj0B7000771; Tue, 13 Aug 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7DCj0p27807; Tue, 13 Aug 2013 05:45:00 -0700 (PDT) Date: Tue, 13 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308131245.r7DCj0p27807@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org Subject: [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, 13 Aug 2013 12:45:27 -0000 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. From evyncke@cisco.com Tue Aug 13 07:37: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 6E3A021E8119 for ; Tue, 13 Aug 2013 07:37:10 -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 ZNz1Cd8Kh6wW for ; Tue, 13 Aug 2013 07:37:05 -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 7789E11E816D for ; Tue, 13 Aug 2013 07:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6839; q=dns/txt; s=iport; t=1376404625; x=1377614225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IeiLOoLW8oRQKW3tUSG7owqAVZJNowWdwbpdk/EtAvo=; b=lM7jtI3fcnUpWjOHKicchF1GZhmdB05tzDpH1/2s2iSAEb0fFPPlZRPw 6wRC/b6eX8LNcvvGu2WOy/P6ZCKVRNYY0PXI/+6TzOYBfQUrUXCMU5B24 cfL9K6iEq7XbMl8NyLwEpIhmAXhf/zmDG0E+bieBOrXUh/uyHxJL1MEy1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOFDClKtJV2b/2dsb2JhbABbgwY1UL5bgSAWdIIkAQEBBAEBAWUGCwwEAgEIEQQBAQEKHQchBgsUAwEFCAIEAQ0FCBOHYwMPDK8SDYhaBI1FgkYsBQcGgxV2A4h1jQaOE4UngxuCKg X-IronPort-AV: E=Sophos;i="4.89,869,1367971200"; d="scan'208";a="246742569" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2013 14:37:04 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7DEb4N8016101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 14:37:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 09:37:04 -0500 From: "Eric Vyncke (evyncke)" To: Mark ZZZ Smith , Brian E Carpenter , "Arie Vayner (avayner)" Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOl5rYDMSxdUYJukeaGavK35KXPJmS5vgAgABOd3A= Date: Tue, 13 Aug 2013 14:37:03 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E113130861@xmb-aln-x02.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> <520945FF.4000700@gmail.com> <1376369664.37168.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: <1376369664.37168.YahooMailNeo@web142504.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 14:37:10 -0000 While I agree with you about laptops & desktops, I am less sure about IoT a= nd all IP webcam, Rasp PI and all other thermostats... but this is indeed t= he direction and this should be the underlying idea OTOH, large enterprises do not want only to secure their employees' desktop= , they also want to enforce a security policy... (data leakage, ...) where = the end point cannot be also be trusted ;-) > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Mark ZZZ Smith > Sent: mardi 13 ao=FBt 2013 06:54 > To: Brian E Carpenter; Arie Vayner (avayner) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- > > From: Brian E Carpenter > > To: Arie Vayner (avayner) > > Cc: "v6ops@ietf.org" > > Sent: Tuesday, 13 August 2013 6:30 AM > > Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC > > > > On 12/08/2013 17:27, Arie Vayner (avayner) wrote: > >> Owen, > >> > >> While the arguments about moving the firewalls closer to the users > >> are > > valid they are often are not practical (or at least the customers I > > worked with would not implement this option). > >> Imagine an enterprise network with 300 spoke sites, but only 2 or 3 > > Internet gateway locations (with some private WAN in between). > >> Moving the firewalls to the spoke sites would increase the number of > > firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a > second)... > > This is a major CAPEX and OPEX impact... > > > > Clearly DOS and scanning protection has to be done as close to the > > Internet border routers as possible, and there your logic applies. > > > > However, as Steve Bellovin pointed out many years ago, the best number > > of firewalls for upper layer protection is one per host, which scales > > nicely and has less CAPEX and OPEX than middlebox firewalls will ever > have. > > >=20 > Host based firewalling by default has also pretty much been reality for > most devices for the last 5+ years, if not much longer (Windows XP Servic= e > Pack 2 provided and enabled by default a host firewall in around 2004).= =A0I > think the reality today is that vendors assume that if a device could be > plugged directly into the Internet it probably will be, and therefore the= y > provide and enable host based firewalls by default. >=20 > It seems common for the people who make the above argument to be the same > people who are facilitating direct attachment of hosts to untrusted and > uncontrolled networks by providing laptops instead of desktops, organisin= g > 3G/4G dongles for those laptops, and allowing rather than prohibiting > people from taking those laptops home, to conferences, cafes and hotels. > Fortunately their OS vendors have taken care of enabling host protection > on their behalf. >=20 > > Not that I see any of this argument as relevant to the IP version > number. > > >=20 > Agree. >=20 > > =A0 Brian > > > >> Arie > >> > >> From: Owen DeLong [mailto:owen@delong.com] > >> Sent: Friday, August 9, 2013 12:17 PM > >> To: Arie Vayner (avayner) > >> Cc: Eric Vyncke (evyncke); Lorenzo Colitti; Fred Baker (fred); > > v6ops@ietf.org > >> Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 > >> WGLC > >> > >> > >> On Aug 8, 2013, at 22:21 , Arie Vayner (avayner) > > > wrote: > >> > >> > >> Another loosely related point that I think could make sense in such > >> a > > document would be the ways to accomplish multi-homing and how it is > > different than today's IPv4 implementations. > >> > >> Many enterprises rely on NAT on the Internet edge as their > > multi-homing/traffic engineering mechanism with IPv4. > >> > >> If we recommend against ULA+NPTv6 (or just NPTv6 for traffic > >> engineering), > > then we need to highlight the symmetry requirement due to stateful > > security layers. > >> Traffic leaving from an Internet gateway site to the Internet has to > >> come > > back through the same site, or the stateful firewalls would break the > > flow (well, has to hit the same stateful security layer) > >> > >> Or stateful firewalls have to get better about sharing state. There > >> are two > > things that can help with this... > >> > >> 1.=A0 =A0 =A0 =A0 Put your firewalls as close to the end systems the= y > >> protect as > > possible. Make your security zones relatively small and place the > > firewalls closer together at those narrower borders. > >> =A0 =A0 =A0 =A0 =A0 =A0 This will often require more firewall units, = but it > >> helps in a > > number of ways: > >> =A0 =A0 =A0 =A0 =A0 =A0 A.=A0 =A0 =A0 =A0 Firewall policy tends to be= much simpler (and > >> as a > > result less error prone and more reliable) > >> =A0 =A0 =A0 =A0 =A0 =A0 B.=A0 =A0 =A0 =A0 The hardware demands on the= firewall tend to > >> be lower > > so you can buy cheaper units. > >> =A0 =A0 =A0 =A0 =A0 =A0 C.=A0 =A0 =A0 =A0 The simpler rulesets can be= more easily > >> tailored to > > meet business requirements as they evolve. > >> > >> > >> > >> 2.=A0 =A0 =A0 =A0 Improve firewalls. Give the firewalls that all pro= tect > >> the same > > boundary a way to mesh-peer with each other and exchange information > > about the state tables such that triangle routing is no longer > problematic. > >> > >> > >> Syncing upstream and downstream routing policies is not always an > >> easy task > > (but could be relevant in some cases). > >> Linking the Internet gateway layer across sites (before hitting the > > stateful security layer) could be another solution. > >> > >> If we make the changes above to the firewalls, this could be=A0 a lot > >> less > > relevant in most cases. > >> > >> > >> Do you think a short discussion to raise awareness for this > >> potential issue > > could be relevant in such a document? > >> > >> It's certainly worth documenting. I'm not sure whether it belongs > > in this document or not. > >> > >> Owen > >> > >> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> --- > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From evyncke@cisco.com Tue Aug 13 08:20: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 9217411E80A2 for ; Tue, 13 Aug 2013 08:20:46 -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 BH65JjNgVDtH for ; Tue, 13 Aug 2013 08:20:42 -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 CA51B21E808C for ; Tue, 13 Aug 2013 08:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8383; q=dns/txt; s=iport; t=1376407241; x=1377616841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NeCXqYMsA/QKi33TFNFU2W+9xVD5jAfZ6LIlaG2LN7I=; b=aSpklaY057EXw02Mio6vaybaqUGYlMZUgLK7/TTa4ha98T7gVBRayg89 UwXQTsaH+CaH2uL3u7xEZPy/LcdoGjbBjJ0sf6suBaIw+7T96wQpj8bGc O1kdPZoWonruZYOMfF64sRyAPU5pcSgqUXpeLUcuxF42E0aLtin3rNPBi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIJNClKtJV2Z/2dsb2JhbABbgwY1UL5cgSIWdIIkAQEBBAEBASRHAwgMBAIBCA4DBAEBAQodByEGCxQJCAIEAQ0FCBGHZQMPDK8ZDYhejUWCRjEHBoMVdgOIdY0GjhOFJ4FhgTqCKg X-IronPort-AV: E=Sophos;i="4.89,870,1367971200"; d="scan'208";a="246773343" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 13 Aug 2013 15:20:41 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7DFKfNZ024748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 15:20:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 10:20:40 -0500 From: "Eric Vyncke (evyncke)" To: Ray Hunter , Gert Doering Thread-Topic: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] Thread-Index: AQHOlDUr32tAPm6ECUujdCwLB2VfdpmLpDYAgAAwrYCAAAmAgIAABlqAgAdjsZA= Date: Tue, 13 Aug 2013 15:20:39 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E113130A07@xmb-aln-x02.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <52031D69.3070604@gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> In-Reply-To: <5203D531.1080207@globis.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:20:46 -0000 Ray, Reading you late (Summer time...) I know several enterprises running out of RFC 1918 (WiFi, BYOD, VoIP, bad a= ddressing plan, mergers & acquisitions) Else, I agree with you: IPv4 will probably die on the Internet core first t= han in all enterprises. But, a lot of very big and very small enterprises w= ill be IPv6-only first IMHO (reading my cheap crystal ball) > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Ray Hunter > Sent: jeudi 8 ao=FBt 2013 19:28 > To: Gert Doering > Cc: v6ops@ietf.org > Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise- > incremental-ipv6 WGLC] >=20 > > Gert Doering > > 8 August 2013 19:05 > > Hi, > > > > To get rid of dual-stack operations, while still being able to benefit > > from the large address space of IPv6 inside the enterprise? > Who has an IPv4 address shortage *inside* the enterprise? > And what are these benefits *inside* the enterprise? > LAN switches are written off over at least 10 years in the book keeping. >=20 > AFAICS the only thing most large enterprises are worried about right now > is the border, and Internet and outward facing systems (and rightly so). > They'll be able to run *private* IPv4 networks over MPLS or GRE or > something else for many many years to come, with all of their important > partners, and there'll be plenty of vendors wiling to support them on old > kit at cut prices. >=20 > If SNA or DECnet IV is any transition model to go by, it took about 20 > years for them to die inside most enterprises, whilst they generally died > much quicker at the border. It went something like: native SNA or native > routed DECnet IV on original vendor equipment -> multi-protocol routers -= > > tunnelled SNA or DECnet IV -> islands with gateways -> islands -> switch > off. >=20 > The final straw was making end users pay pro-rata for the support costs o= f > the shrinking infra. IMVHO Whilst there's still economies of scale, > there's simply no business case *inside* the enterprise except for > opportunistic switch on at standard scheduled lifecycle renewal. I've bee= n > through this loop myself. But then again, why should the IETF care what > happens in that case if the border interface is clean and IPv6 only? > > > > Dual-stack is a major cost factor. > > > > Gert Doering > > -- NetMaster > > Ray Hunter > > 8 August 2013 18:31 > > Erik Nygren wrote: > >> It's also likely the case that at least some enterprises control > >> portions of their environments well enough that mostly-IPv6 could > >> potentially be much more viable than a residential environment. For > >> example, a retail store chain using HTTP-based POS terminals and > >> kiosks may have enough control over their environment that they could > >> ideally deploy an IPv6-only environment and just use > >> NAT64/DNS64 > >> to get to some of their supplier websites that still require IPv4. > >> It might also be attractive to some US Government agencies who > >> control the devices and clients within their network to use this > >> approach as part of meeting the OMB September 2014 mandate for IPv6 > client support. > >> That could be simpler for those agencies than rolling out a > >> dual-stack environment. > >> (I'm very curious if either of these cases exists in production in > >> the field today...) > >> > >> Erik > >> > > > > Why would anyone in their right mind chose to deploy NAT64/DNS64 in a > > commercial environment given the prices I've seen for that > functionality? > > > > I can't imagine them wanting something like that in operations either. > > > > It's likely to be much cheaper to let legacy applications die off > > naturally, run dual stack or even dual servers for some systems, and > > deploy a combination of simple forward and reverse web proxies for the > > rest (assuming web based apps). > > > > AFAIK There's still stuff happily running Bisync (BSC) out there (over > > IP tunnels) and support for that was deprecated in the 1970's in > > favour of SNA. So I wouldn't hold your breathe waiting for 100% > > migration to IPv6. It's going to be pretty easy to maintain a private > > IPv4 - IPv4 network over a GRE tunnel over an IPv6 Internet for a very > long time yet. > > > >> On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 >> > wrote: > >> > >> > >> On Aug 7, 2013 9:24 PM, "Brian E Carpenter" > >> > > >> wrote: > >> > > >> > On 08/08/2013 16:08, cb.list6 wrote: > >> > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter" > >> > > >> > > wrote: > >> > >> On a different topic, section 5 covers IPv6-only issues. > >> > >> I'm a bit concerned that this might need a health warning: > >> > >> deploying NAT64/DNS64 might cause pain and suffering. > >> > >> Perhaps after this text: > >> > >> > >> > >>> Together, RFCs > >> > >>> 6146 and RFC 6147 provide a viable method for an > >> IPv6-only client to > >> > >>> initiate communications to an IPv4-only server. > >> > >> we should add something like: > >> > >> > >> > >> At enterprise level, operating NAT64 and DNS64 services fo= r > >> > >> heavy usage may have significant practical implications. > >> > >> > >> > > > >> > > Can you be more specific? Pratical data? > >> > > >> > Not really, because I've never operated one in real life. It > doesn't > >> > strike me as the sort of service that most enterprise network > >> > managers will be familiar with, and a v6-only site needing a > normal > >> > level of access to v4-land would end up sending most of its > external > >> > traffic via NAT64 and most of its external DNS queries via DNS64= . > >> > Therefore, these would become an important single point of > failure > >> > and a potential bottleneck. The text doesn't seem to point this > out. > >> > > >> > >> Agree with Joel, nat64 will be parity with common nat44 and > >> firewalls in terms of availability > >> > >> Regarding majority of traffic, i believe the scales have tipped to > >> show v6 is the majority for campus networks, which is the best > >> proxy in the available data > >> > >> http://www.worldipv6launch.org/measurements/ > >> > >> These numbers also skew low since Apple has a non-deterministic > >> happy eyeballs > >> > >> Given that enterprises and all users of IP are out of ipv4, so > >> they need to not use ipv4 yet have access to it, guidance against > >> nat64 will frustrate the issue. > >> > >> Guidance should be given to make as many flow v6 e2e. Full stop. > >> > >> CB > >> > >> > >> > Brian > >> > > >> > > CB > >> > > > >> > >> Also, the last paragraph of section 5: > >> > >> > >> > >>> It is worth noting that for IPv6-only access networks > >> that use > >> > >>> technologies such as NAT64, the more content providers > (and > >> > >>> enterprises) that make their content available over IPv6, > >> the less > >> > >>> the requirement to apply NAT64 to traffic leaving the > >> access network. > >> > >> A reference to RFC 6883 would fit nicely there. > >> > >> > >> > >> Regards > >> > >> Brian > >> > >> _______________________________________________ > >> > >> v6ops mailing list > >> > >> v6ops@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > > > > > > ---------------------------------------------------------------------- > > -- >=20 >=20 > -- > Regards, > RayH >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From evyncke@cisco.com Tue Aug 13 08:29: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 2F1AF21F8411 for ; Tue, 13 Aug 2013 08:29:14 -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=[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 dpUJYZ29m8dN for ; Tue, 13 Aug 2013 08:29:05 -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 624AD11E810B for ; Tue, 13 Aug 2013 08:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8742; q=dns/txt; s=iport; t=1376407744; x=1377617344; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9WLsSrOgXn9JCPQzbiQdh3vGSxAacObCM475RoyCLgU=; b=TIrr39356jSWtopkVFnc1kqZyl/jElg866ieYciLn8EyzrY8Ejq6QAWV HdwFMCGpYYVmNAgO9PvbD1+98lkx2cFjIZ2nb9WmcuMD9iN+v6afuGRm3 aEHb/oq3wiTWh4OkjqSp5h34tnFvRraJ2HbolFmIVJ5hu5l/O6IeQbFYZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAJdQClKtJV2b/2dsb2JhbABbgkJEgQW+XIEiFnSCJAEBAQQtTBACAQgRBAEBCx0HMhQJCAIEAQ0FCIgIuA2QCzEGAYMbdgOIdaBAgxuCKg X-IronPort-AV: E=Sophos;i="4.89,870,1367971200"; d="scan'208,217";a="246798484" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 13 Aug 2013 15:28:39 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7DFSdIk016395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 15:28:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 10:28:39 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti , "Arie Vayner (avayner)" Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOkTyDDMSxdUYJukeaGavK35KXPJmGm1kAgACKQoCAAF43gIAAFCCAgAArgQCAAkwdAIACTLxQgAUQVYCAAeQZ0A== Date: Tue, 13 Aug 2013 15:28:38 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E113130B0A@xmb-aln-x02.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E113130B0Axmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:29:14 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E113130B0Axmbalnx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lorenzo I agree that source+destination routing solves it in an elegant way... but = how many implementations are there beside the demo at the IETF? This enterprise guidance should be practical. But, you are right we should = mention at least that more work is currently being done at the IETF on this= front. -=E9ric From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: lundi 12 ao=FBt 2013 07:35 To: Arie Vayner (avayner) Cc: Eric Vyncke (evyncke); Fred Baker (fred); v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner) > wrote: Many enterprises rely on NAT on the Internet edge as their multi-homing/tra= ffic engineering mechanism with IPv4. If we recommend against ULA+NPTv6 (or just NPTv6 for traffic engineering), = then we need to highlight the symmetry requirement due to stateful security= layers. Traffic leaving from an Internet gateway site to the Internet has to come b= ack through the same site, or the stateful firewalls would break the flow (= well, has to hit the same stateful security layer) By itself, NPTv6 doesn't protect against this problem because it's not stat= eful. It only protects against this problem if each egress point is only re= achable using one prefix (which is not a requirement for doing NPTv6 - you = could just as well do it by configuring all multiple exit points to use the= same prefix, or to use all prefixes from all exit points). What does protect you against this is using source+destination routing, whi= ch is what this draft should recommend instead of recommending NPTv6. --_000_97EB7536A2B2C549846804BBF3FD47E113130B0Axmbalnx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lorenzo

 

I agree that= source+destination routing solves it in an elegant way... but how many= implementations are there beside the demo at the IETF?

 <= /o:p>

This enterpr= ise guidance should be practical. But, you are right we should mention at l= east that more work is currently being done at the IETF on this front.

 <= /o:p>

-=E9ric=

 <= /o:p>

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: lundi 12 ao=FBt 2013 07:35
To: Arie Vayner (avayner)
Cc: Eric Vyncke (evyncke); Fred Baker (fred); v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WG= LC

 

On Fri, Aug 9, 2013 at 2:21 PM, Arie Vayner (avayner= ) <avayner@cisco.= com> wrote:

Many enterprises rely on= NAT on the Internet edge as their multi-homing/traffic engineering mechanism with IPv4.

 

If we recommend against = ULA+NPTv6 (or just NPTv6 for traffic engineering), then we need to highlight the symmetry requirement due to stateful security layers.

Traffic leaving from an = Internet gateway site to the Internet has to come back through the same site, or the stateful firewalls would break the flow (well, has t= o hit the same stateful security layer)

 

By itself, NPTv6 doesn't protect against this proble= m because it's not stateful. It only protects against this problem if each = egress point is only reachable using one prefix (which is not a requirement= for doing NPTv6 - you could just as well do it by configuring all multiple exit points to use the same pref= ix, or to use all prefixes from all exit points).

 

What does protect you against this is using source&#= 43;destination routing, which is what this draft should recommend instead o= f recommending NPTv6.

--_000_97EB7536A2B2C549846804BBF3FD47E113130B0Axmbalnx02ciscoc_-- From fred@cisco.com Tue Aug 13 08:49: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 2D88711E8184 for ; Tue, 13 Aug 2013 08:49:43 -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 veZ8Kul-MjbZ for ; Tue, 13 Aug 2013 08:49:38 -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 54E8B11E818B for ; Tue, 13 Aug 2013 08:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1666; q=dns/txt; s=iport; t=1376408978; x=1377618578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UF0bp0hHvriftXmMhkHzBoA/MK+hnYfRl/Bfm7v0AgU=; b=N9XVeEngq/CyaLNg5DKa5QfzB/pOjpkhWZ91ObY366AgM+WbYHY9g7Bz jp6nBgB9Oi+H1MIe2nqmNps6HKp+reyUMM8+2wyuHOH18VM+YIMAn5g7r qc2142XGytwMO29zMnvj0tSFHxbQiW7EobarhX+fSrWNmXTZcophcsJr5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIhUClKtJXG8/2dsb2JhbABbgwY1RAy+XIEiFnSCJAEBAQMBeQULAgEIIiQyJQIEDgUIiAIGDLgIkAkCMQeDG3YDiHWQHJAkgxuCKg X-IronPort-AV: E=Sophos;i="4.89,870,1367971200"; d="scan'208";a="246595371" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 13 Aug 2013 15:49:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7DFnbkf016515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 15:49:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 10:49:37 -0500 From: "Fred Baker (fred)" To: "Eric Vyncke (evyncke)" Thread-Topic: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC Thread-Index: AQHOmDy2jSiE4GZhHkqUmIkyMNbXNg== Date: Tue, 13 Aug 2013 15:49:37 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B983422@xmb-rcd-x09.cisco.com> References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113130B0A@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E113130B0A@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8F0A79E35AA2C14DBA3D847A6B0F9BC3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:49:43 -0000 On Aug 13, 2013, at 8:28 AM, "Eric Vyncke (evyncke)" wrote: > how many implementations are there beside the demo at the IETF? Well, we know of four: Ole and Lorenzo's SADR, Juliusz Chroboczek's Babel, = Shu Yang's MTR OSPF-based implementation, and his implementation of my OSPF= /IS-IS concepts. They are all prototypes as far as I know, but yes, they ex= ist. http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred Baker, 2013-07-15 http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 2013-02-17 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-05-02 http://tools.ietf.org/html/draft-chroboczek-babel-extension-mechanism "Extension Mechanism for the Babel Routing Protocol", Juliusz Chroboczek, 2013-06-30 http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication "Babel HMAC Cryptographic Authentication", Denis Ovsienko, 2013-04-18 http://tools.ietf.org/html/draft-troan-homenet-sadr "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole Troan, Lorenzo Colitti, 2013-02-18 http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu Yang, Jianping Wu, Dan Wang, 2013-02-18 http://tools.ietf.org/html/draft-xu-homenet-traffic-class "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang, Jianping Wu, Fred Baker, 2013-07-15= From wesley.george@twcable.com Tue Aug 13 09:38: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 8901C11E819C for ; Tue, 13 Aug 2013 09:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 JJuGa98l9QTy for ; Tue, 13 Aug 2013 09:38:27 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 478DD11E8188 for ; Tue, 13 Aug 2013 09:38:26 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,871,1367985600"; d="scan'208";a="121176514" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 13 Aug 2013 12:37:36 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 13 Aug 2013 12:38:25 -0400 From: "George, Wes" To: "Antonio M. Moreiras" , "v6ops@ietf.org" Date: Tue, 13 Aug 2013 12:38:24 -0400 Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: Ac6XqQz1gVvh3mJPTuqdNECNvm8DQQAgeNkA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> In-Reply-To: <52095DAF.2050505@nic.br> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:38:32 -0000 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Antonio M. Moreiras > Sent: Monday, August 12, 2013 6:12 PM > > (repeating myself) Generally our IPv6 trainings are the first contact > with IPv6 for some network guys. Their biggest difficulties generally > lies in understanding the IPv6 addresses. The types of addresses, where > to use each of them, the new format, etc. [WEG] What I think you're saying above is that new folks are intimidated by= IPv6 (the hex, the colons, etc). The best way to get past that is probably= to keep reiterating the aphorism "96 more bits, no magic" in order to buil= d on their familiarity with IPv4, rather than being overly concerned about = the type of addresses used in different parts of training labs. A basic fam= iliarity with IPv6 is going to be more important than being able to recogni= ze different types of IPv6 addresses on sight. That said, I do understand the value in being consistent on the types of ad= dresses used in documentation based on their purpose within the documentati= on in order to lessen confusion. >From a didactic point of view, > it would be a bad idea to use ULAs and tell them: please don't forget to > pretend that this ULA block is our Global Unicast block, and this other > ULA prefix will be the "real" ULA in our lab. Something looking more > like GUAs would be better. The prefix 2001:db8::/32 do represent GUAs in > documentation. [WEG] Here's the problem I have with this argument: Every training class I'= ve ever attended was either using RFC1918 space, or taking advantage of the= fact that they essentially had the entirety of IPv4 space at their disposa= l because this wasn't connected to the internet (e.g. pod 1 was 10.x/8, pod= 2 was 20.x/8, pod 3 was 30.x/8 etc.) and same with ASNs (using AS100, 200,= 300 instead of RFC5398 ASNs). Somehow most of us survived this and were ab= le to apply what we learned to real networks. > > It is difficult to convince people that private addresses and NATs are > not to be used in all situations. Using ULAs in the labs, instead of > Globals, would not help. [WEG] That is a matter of educating them on *why* you've chosen to use ULA = in the lab - i.e. because it's not connected to the global internet, etc. I= t gives you an opportunity to reiterate exactly why they *shouldn't* do tha= t for an internet-connected deployment. I fear that using ULAs would result in people > used to see them in the wrong places, and could lead us to a situation > where some networks would finish having just ULA addresses (and NAT66) > in scenarios where it would not be the better choice. [WEG] I don't think that the choice of IP block during a training is going = to have a material impact on this. People are either going to make an educa= ted design decision based on their needs, guidance, and best common practic= e, or they're going to do what they're going to do in spite of guidance to = the contrary. Hanging the justification for a larger/additional block of do= cumentation prefixes on concerns over enabling people to do stupid things w= ith NAT on IPv6 based on what they saw in a lab conflates two issues in a w= ay that's not helpful. Let's stick to discussing the merits of the need for= a larger block of IPv6 addresses for documentation. Right now, your draft = isn't nearly specific enough about the scenarios where something larger tha= n a /32 is required, nor how you arrived at a /20 as the recommended size. > > I would prefer to choose an arbitrary prefix, inside or outside > 2000::/3, but that "looks like" a GUA, than use ULAs in the classes. [WEG] Might I suggest repurposing all or part of 0200::/7? (RFC4048). Even = if we don't officially allocate it as additional documentation space, that = seems a safe squat point for things like training, likely to already be fil= tered by SPs as bogon space, etc. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Tue Aug 13 10:07: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 1FDE721E804E for ; Tue, 13 Aug 2013 10:07:52 -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 ynBeYNz2pJ3B for ; Tue, 13 Aug 2013 10:07:43 -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 ED3C921F9FF6 for ; Tue, 13 Aug 2013 10:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48; q=dns/txt; s=iport; t=1376413663; x=1377623263; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=GBVEkubaLPcvyaWurMaslPx0EmYobPDFfxdWqh76wqA=; b=F1EApGRUnVQVYs7VOHchHqhiQejsL6xwewbhOZsbfpgAXzWL8YCbnv7c SlYx8AhpJyQUTgEfMtz4HLMh69G3DBwZOm7fhkMy7lIvslJqDM3aBJ0ig 4VMgdwneHG8Gz305/GszD1y+mCR8X82t6mIb7HPjFDKr4li3el4FTaB0e E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAJBmClKtJXG+/2dsb2JhbABbgwaBBb5egSIWdIImAQQ6UQEqFEInBBuICJdjoDKQC4NTdgOpNYMbgio X-IronPort-AV: E=Sophos;i="4.89,871,1367971200"; d="scan'208";a="246822739" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 13 Aug 2013 17:07:42 +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 r7DH7fib010486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 13 Aug 2013 17:07:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 12:07:41 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Apologies for my bot this morning Thread-Index: AQHOmEeelulQzhCL806EGSXa3uPykA== Date: Tue, 13 Aug 2013 17:07:40 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B983693@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.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Apologies for my bot this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Aug 2013 17:07:52 -0000 It looks like it woke up in a bad mood. Wow... From owen@delong.com Tue Aug 13 11:05: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 4EE5511E81A0 for ; Tue, 13 Aug 2013 11:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_23=1, J_BACKHAIR_32=1, 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 EgbappS6PJ2Q for ; Tue, 13 Aug 2013 11:05:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0311821F91B7 for ; Tue, 13 Aug 2013 11:05:49 -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 r7DI5L9N016757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Aug 2013 11:05:21 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7DI5L9N016757 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376417122; bh=vTCu22TlWKxMOnOUmjggdie3LFM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3g4BzDpyeIcHGhOZg9WifvRyU8OM6uS2/rPUlzs1IW6jaJzlFzr+cHLHa4dpK21OC DvY2jPBobPqD0p1266NWAR+mPu3dWlX8PIHX6tfDYYV/Crwb0JUahKkhem329rY4ML qTlrLSLCCCvQ2TWsEOTOGZbRNNHFMat+x7Bwqgds= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <20130813070157.6D9D5384B2C5@drugs.dv.isc.org> Date: Tue, 13 Aug 2013 11:05:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> <20130813025336.918353846F7A@drugs.dv.isc.org> <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com> <20130813070157.6D9D5384B2C5@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 13 Aug 2013 11:05:22 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:05:51 -0000 > > With ULA you end up with: > > site1: P1, P2 announce P2 to site2 > site2: P1, P3 announce P3 to site1 > > When you have two sites colliding on P1. (P1, P2 and P3 are different > ULA prefixes). No, with ULA, the average IT group is going to start with: site 1: P1 site 2: P1 They're going to not want to roll out a whole new addressing plan to both sites, so, instead, they will do what they did in IPv4. P1<->NAT<->P2<->NAT<->P1 You need to come down out of whatever ivory tower you live in and look at how things happen in the real world. > > You have IP stacks that are designed to deal with multiple prefixes > and to choose particular source addresses for particular destination > addresses. > > You have applications that are designed to deal with multiple > addresses. > > IPv4 only stacks don't have all of these features which forces one > to use NAT. None of that overcomes the realities if modern corporate IT staffing. > > With IPv6 they are there so you can depend on them and take advantage > of them. If P2 and P3 differ only in the 48th bit longest match > will select the right source address. If you know about them. If you're willing to put in the effort to use them. If you completely understand them. IF and only IF all of your applications are actually that savvy. etc. For most enterprises, the answer to at least one of those IFs will fail. Owen From owen@delong.com Tue Aug 13 11:30: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 3827221F9FF6 for ; Tue, 13 Aug 2013 11:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=1.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 boZ7+hMoUq+g for ; Tue, 13 Aug 2013 11:30:46 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 902FE21F9FA4 for ; Tue, 13 Aug 2013 11:30:44 -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 r7DITe18017280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Aug 2013 11:29:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7DITe18017280 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376418581; bh=QRuL4xja0uLjUuNpnAFFPDV63BU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xuhLgKvuwzZe2spZrq5NFfwBmqvLNWUio+MYAGKsCz4uIUKXRzQWReKMhJ0IQibQe ykqmpH1+lxwBROo1wj3ubQBv7d8fjYEkkvv6HCalZbN2MDbKhlnA7F7dGqt6GIw3/Z dnheuQNm7D6Pa+EKqzPcSWpisLJcXpQTNOhSc3k0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> Date: Tue, 13 Aug 2013 11:29:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 13 Aug 2013 11:29:41 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:30:47 -0000 On Aug 13, 2013, at 09:38 , "George, Wes" = wrote: >=20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Antonio M. Moreiras >> Sent: Monday, August 12, 2013 6:12 PM >>=20 >> (repeating myself) Generally our IPv6 trainings are the first contact >> with IPv6 for some network guys. Their biggest difficulties generally >> lies in understanding the IPv6 addresses. The types of addresses, = where >> to use each of them, the new format, etc. > [WEG] What I think you're saying above is that new folks are = intimidated by IPv6 (the hex, the colons, etc). The best way to get past = that is probably to keep reiterating the aphorism "96 more bits, no = magic" in order to build on their familiarity with IPv4, rather than = being overly concerned about the type of addresses used in different = parts of training labs. A basic familiarity with IPv6 is going to be = more important than being able to recognize different types of IPv6 = addresses on sight. > That said, I do understand the value in being consistent on the types = of addresses used in documentation based on their purpose within the = documentation in order to lessen confusion. Wes, I don't know how much ab initio IPv6 training you do. What you are describing is part of it, but not the whole issue. Antonio and I have taught quite a few classes by now. We repeatedly see = students struggling with the idea of how the different types of IPv6 = addresses are determined, what exactly they mean and how the pieces fit = together. It's hard enough for them to understand the difference between ULA, GUA, = multicast, Link Local, etc. Having them pretend one ULA prefix is GUA while the other one is = representing ULA makes it much more confusing for them. While the issue you describe (96 more bits, no magic) is a prevalent = one, it really isn't the only one and isn't the one this proposal seeks = to address. >=20 >> =46rom a didactic point of view, >> it would be a bad idea to use ULAs and tell them: please don't forget = to >> pretend that this ULA block is our Global Unicast block, and this = other >> ULA prefix will be the "real" ULA in our lab. Something looking more >> like GUAs would be better. The prefix 2001:db8::/32 do represent GUAs = in >> documentation. > [WEG] Here's the problem I have with this argument: Every training = class I've ever attended was either using RFC1918 space, or taking = advantage of the fact that they essentially had the entirety of IPv4 = space at their disposal because this wasn't connected to the internet = (e.g. pod 1 was 10.x/8, pod 2 was 20.x/8, pod 3 was 30.x/8 etc.) and = same with ASNs (using AS100, 200, 300 instead of RFC5398 ASNs). Somehow = most of us survived this and were able to apply what we learned to real = networks. My training classes (I don't know the details of Antonio's) are actually = connected to the internet. Yes, we use RFC-1918 IPv4 space and they are = NATed for IPv4. However, the IPv6 GUA that I use for the actual student = routers is part of a GUA prefix (we use a /48 for the class and divide = it up into smaller prefixes for the lab). However, the training = materials are written using the doc prefix (or a variant of it). The lab gets a real BGP feed and is really on the IPv6 internet. When = the students reach the later exercises in the lab, they're working with = real IPv6 applications over a routed infrastructure that they built = using OSPF3 and BGP/IPv6. My training lab consists of 16 routers = comprising 4 autonomous systems with 4 routers each and a synthetic = internet exchange point. Each ASN is linked IXP->R4->R3->R1->R2->(R2a) = where (R2a) represents a private peering with the adjacent AS R2. = (AS65501<->AS65502 and AS65503<->AS65504). There's a 17th router which acts as a classroom gateway and provides = wifi so that the students can ssh in with their laptops. It does the = IPv6 tunnel termination and the BGP session with the upstream routers. = It's connected to the IXP and it provides transit to all of the student = ASNs. The entire lab is portable in a laser cut acrylic case that fits (with = my clothes) in a roll-aboard carry-on bag. For example, when I talk about how to deal with a larger environment, I = show an example of carving up a /28 and we pretend that 2001:db80::/28 = is the doc prefix for that purpose. It would be much better to have an = actual shorter doc prefix to use instead of having to pervert the = existing one. After all, at some point, 2001:db80::/28 (or longer) may belong to = someone. >> It is difficult to convince people that private addresses and NATs = are >> not to be used in all situations. Using ULAs in the labs, instead of >> Globals, would not help. > [WEG] That is a matter of educating them on *why* you've chosen to use = ULA in the lab - i.e. because it's not connected to the global internet, = etc. It gives you an opportunity to reiterate exactly why they = *shouldn't* do that for an internet-connected deployment. I don't disagre, but as long as we have ULA, the only hope of avoiding = having it misused with things like NPT is good education. Having a ULA = doc prefix for that purpose can and will be helpful. Having a shorter = GUA prefix can and will be very helpful. >=20 > I fear that using ULAs would result in people >> used to see them in the wrong places, and could lead us to a = situation >> where some networks would finish having just ULA addresses (and = NAT66) >> in scenarios where it would not be the better choice. > [WEG] I don't think that the choice of IP block during a training is = going to have a material impact on this. People are either going to make = an educated design decision based on their needs, guidance, and best = common practice, or they're going to do what they're going to do in = spite of guidance to the contrary. Hanging the justification for a = larger/additional block of documentation prefixes on concerns over = enabling people to do stupid things with NAT on IPv6 based on what they = saw in a lab conflates two issues in a way that's not helpful. Let's = stick to discussing the merits of the need for a larger block of IPv6 = addresses for documentation. Right now, your draft isn't nearly specific = enough about the scenarios where something larger than a /32 is = required, nor how you arrived at a /20 as the recommended size. I think (and this is likely my fault) that we're conflating two requests = here. The original proposal for a larger doc prefix is all about being able to = write books and training scenarios that use a doc prefix and talk about = carving up larger chunks of address space. For ab initio training, = trying to teach students that these ULA examples are not really = applicable to ULA, but should be used with GUA is very confusing and it = really does break their brains. Allocating a larger doc prefix would = help with this scenario a lot. Secondarily, I mentioned that while we were considering an additional = doc prefix, it might make sense to also look at allocating a third doc = prefix for creating ULA examples. I think this should come from the = fc00::/8 space which is currently unusable anyway, and which would = allow examples describing the use of (and reasons not to use) ULA with a = prefix that would be easily identified if the examples were erroneously = copied into the real world. >> I would prefer to choose an arbitrary prefix, inside or outside >> 2000::/3, but that "looks like" a GUA, than use ULAs in the classes. > [WEG] Might I suggest repurposing all or part of 0200::/7? (RFC4048). = Even if we don't officially allocate it as additional documentation = space, that seems a safe squat point for things like training, likely to = already be filtered by SPs as bogon space, etc. Works for me. I would suggest 0200:2000::/20 to fit with the other requestors' desire = for a /20. For my needs, even 0200:2200::/24 would be adequate. Owen From carlosm3011@gmail.com Tue Aug 13 12:03: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 AB45D21E8194 for ; Tue, 13 Aug 2013 12:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOvkw2NcpyDb for ; Tue, 13 Aug 2013 12:03:06 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 345C411E81A6 for ; Tue, 13 Aug 2013 12:02:58 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id jz10so6996921veb.12 for ; Tue, 13 Aug 2013 12:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YNUaXDdvC1bL56/bOaQWLBuJlWnPdefA5SYkM2QqRgc=; b=RmUJNEdxycCQX0m2mCyt+tjvgNyYKcOSDwtiOYQZa6o8hyWWib4AnZQmq2GLNcPsYh P+dYO6ifXxnQ2GOODv2MQzQej1TlQcMF2HOvQ+NT3bZQrla8G0DrWjUNBeNzIPrDXgxw gRAbD8J+wWVJmy8v5bSET6SArggkq7TowdcqiBmg+rdCYgb3NzZ1dsAqybqNLxXOGTaz uLaAZ0bmbGD+6BUf4M1lB7fBPhHa0S1PQgBHKKI3vKjgLIN/6vxGIankd1b/4fpKDmHR cOqx4zrxgXNIyZpOsEwmuNh8gweR2mvk9d6xy6jns2qAMS+raFQxLJIBJ+dNMfgjelg+ pogQ== X-Received: by 10.58.127.202 with SMTP id ni10mr5577216veb.27.1376420577554; Tue, 13 Aug 2013 12:02:57 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:d442:d05f:a136:4b0a]) by mx.google.com with ESMTPSA id b6sm25967339vdh.12.2013.08.13.12.02.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 12:02:56 -0700 (PDT) Message-ID: <520A82D9.2030602@gmail.com> Date: Tue, 13 Aug 2013 16:02:49 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Owen DeLong References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <18CD1C88-5F15-46BA-A76C-87F9A033E209@delong.com> In-Reply-To: <18CD1C88-5F15-46BA-A76C-87F9A033E209@delong.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alejandro Acosta , IPv6 Ops WG , carlos@lacnic.net Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 19:03:06 -0000 Hello Owen, On 8/12/13 5:19 PM, Owen DeLong wrote: > I think creating ambiguity with 3ffe would be a very very bad idea for this. I believe we the instructors should know better and have no problem dealing with this. For newbies, they probably have never heard about 6bone. Unless there is equipment / software with hardcoded addresses in this range, I don't see much of a problem. ~Carlos From wesley.george@twcable.com Tue Aug 13 12:58: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 9374811E81A7 for ; Tue, 13 Aug 2013 12:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BipOxGiR7AG1 for ; Tue, 13 Aug 2013 12:58:44 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6789211E81BA for ; Tue, 13 Aug 2013 12:58:43 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,872,1367985600"; d="scan'208";a="117287925" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Aug 2013 15:57:44 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 13 Aug 2013 15:58:42 -0400 From: "George, Wes" To: Owen DeLong Date: Tue, 13 Aug 2013 15:58:41 -0400 Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: Ac6YU1tPieRTQglBSzqqyIM6PYUM1AABtTTw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> In-Reply-To: <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.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" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 19:58:49 -0000 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Tuesday, August 13, 2013 2:29 PM > To: George, Wes > Cc: Antonio M. Moreiras; v6ops@ietf.org > Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 > > > > The original proposal for a larger doc prefix is all about being able to > write books and training scenarios that use a doc prefix and talk about > carving up larger chunks of address space. [WEG] The thing I don't understand about that is how carving x subnet block= s out of a /32 is different from carving x blocks out of a /48 or x blocks = out of a /20 or whatever you start with as it concerns documentation. Other= than the prefix lengths being somewhat longer, the examples of how to subn= et, how to configure routing, etc still hold, don't they? AFAICT, as long a= s you don't end up subnetting below /64, there's really no issue. Yes, real= routing policy likely won't pass a bunch of /64s, but for a lab such as wh= at you detailed, and the subtending documentation that should work just fin= e, no? Especially given that the goal is to teach someone how to do somethi= ng, instead of simply giving them something to copy with no understanding o= f what it's doing. For ab initio training, > trying to teach students that these ULA examples are not really > applicable to ULA, but should be used with GUA is very confusing and it > really does break their brains. Allocating a larger doc prefix would > help with this scenario a lot. [WEG] A point I'll concede, and one that should make it into the draft. :-) > > Secondarily, I mentioned that while we were considering an additional > doc prefix, it might make sense to also look at allocating a third doc > prefix for creating ULA examples. I think this should come from the > fc00::/8 space which is currently unusable anyway, and which would > allow examples describing the use of (and reasons not to use) ULA with a > prefix that would be easily identified if the examples were erroneously > copied into the real world. > > >> I would prefer to choose an arbitrary prefix, inside or outside > >> 2000::/3, but that "looks like" a GUA, than use ULAs in the classes. > > [WEG] Might I suggest repurposing all or part of 0200::/7? (RFC4048). > Even if we don't officially allocate it as additional documentation > space, that seems a safe squat point for things like training, likely to > already be filtered by SPs as bogon space, etc. > > Works for me. > > I would suggest 0200:2000::/20 to fit with the other requestors' desire > for a /20. For my needs, even 0200:2200::/24 would be adequate. > [WEG] at the risk of debating bikeshed colors, I would suggest perhaps usin= g :db8:: for both the proposed GUA and ULA doc prefixes so that it serves a= s a visual cue. Thanks Wes George Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From owen@delong.com Tue Aug 13 13:51: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 C3BBB21E810A for ; Tue, 13 Aug 2013 13:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.500, 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 k8auyM2zRhBw for ; Tue, 13 Aug 2013 13:51:22 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 893E721E80EE for ; Tue, 13 Aug 2013 13:51:22 -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 r7DKmUcX020965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Aug 2013 13:48:30 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7DKmUcX020965 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376426910; bh=f+XZBawdIMjuZ2FZgS64MDiKHiI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=r4MPWFboEckgYkEkBJhSiCLEckdRAvV1+wK2KY+CtuT9xaB+qKyagVQQKPvW0VUqp OE1uc8l4CkguNf+EpfYIsUBNQRjTwrEBw2UKkIijQqewpl0PRwRaar9DKoY9utKlI3 vMGYlauow7XexW2kzHedvsfkwsiiOrsq+11xg5Bk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> Date: Tue, 13 Aug 2013 13:48:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 13 Aug 2013 13:48:30 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:51:24 -0000 On Aug 13, 2013, at 12:58 , "George, Wes" = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Owen DeLong [mailto:owen@delong.com] >> Sent: Tuesday, August 13, 2013 2:29 PM >> To: George, Wes >> Cc: Antonio M. Moreiras; v6ops@ietf.org >> Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 >>=20 >>=20 >>=20 >> The original proposal for a larger doc prefix is all about being able = to >> write books and training scenarios that use a doc prefix and talk = about >> carving up larger chunks of address space. > [WEG] The thing I don't understand about that is how carving x subnet = blocks out of a /32 is different from carving x blocks out of a /48 or x = blocks out of a /20 or whatever you start with as it concerns = documentation. Other than the prefix lengths being somewhat longer, the = examples of how to subnet, how to configure routing, etc still hold, = don't they? AFAICT, as long as you don't end up subnetting below /64, = there's really no issue. Yes, real routing policy likely won't pass a = bunch of /64s, but for a lab such as what you detailed, and the = subtending documentation that should work just fine, no? Especially = given that the goal is to teach someone how to do something, instead of = simply giving them something to copy with no understanding of what it's = doing. You and I know that it isn't. For the ab initio student, it's one more = difference in the overwhelming pile of things being poured into their = brain. Trust me, while it isn't different for someone with experience, in my = experience, it drives students crazy and they get wrapped around the = axle on the differences in the examples and lose sight of what is being = taught. > For ab initio training, >> trying to teach students that these ULA examples are not really >> applicable to ULA, but should be used with GUA is very confusing and = it >> really does break their brains. Allocating a larger doc prefix would >> help with this scenario a lot. > [WEG] A point I'll concede, and one that should make it into the = draft. :-) >=20 >>=20 >> Secondarily, I mentioned that while we were considering an additional >> doc prefix, it might make sense to also look at allocating a third = doc >> prefix for creating ULA examples. I think this should come from the >> fc00::/8 space which is currently unusable anyway, and which would >> allow examples describing the use of (and reasons not to use) ULA = with a >> prefix that would be easily identified if the examples were = erroneously >> copied into the real world. >>=20 >>>> I would prefer to choose an arbitrary prefix, inside or outside >>>> 2000::/3, but that "looks like" a GUA, than use ULAs in the = classes. >>> [WEG] Might I suggest repurposing all or part of 0200::/7? = (RFC4048). >> Even if we don't officially allocate it as additional documentation >> space, that seems a safe squat point for things like training, likely = to >> already be filtered by SPs as bogon space, etc. >>=20 >> Works for me. >>=20 >> I would suggest 0200:2000::/20 to fit with the other requestors' = desire >> for a /20. For my needs, even 0200:2200::/24 would be adequate. >>=20 >=20 > [WEG] at the risk of debating bikeshed colors, I would suggest perhaps = using :db8:: for both the proposed GUA and ULA doc prefixes so that it = serves as a visual cue. I have no problem with that. How about 02db:8000::/20 and fc00:0db8::/32? Owen P.S. love the disclaimer disclaimer. From afaza@unam.mx Tue Aug 13 15:20:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF221F9BD5 for ; Tue, 13 Aug 2013 15:20:58 -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 Bpo3daW5PLJy for ; Tue, 13 Aug 2013 15:20:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5121F9BCA for ; Tue, 13 Aug 2013 15:20:50 -0700 (PDT) Received: from mail226-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 22:20:49 +0000 Received: from mail226-tx2 (localhost [127.0.0.1]) by mail226-tx2-R.bigfish.com (Postfix) with ESMTP id 2B43B540076; Tue, 13 Aug 2013 22:20:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.53; KIP:(null); UIP:(null); IPV:NLI; H:BN1PRD0612HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I1432I2fd2K14ffI9a6kzz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz8dhz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz32i2a8h668h839h944hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h16a6h1758h1806h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail226-tx2 (localhost.localdomain [127.0.0.1]) by mail226-tx2 (MessageSwitch) id 1376432446310308_7809; Tue, 13 Aug 2013 22:20:46 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.235]) by mail226-tx2.bigfish.com (Postfix) with ESMTP id 47010800041; Tue, 13 Aug 2013 22:20:46 +0000 (UTC) Received: from BN1PRD0612HT004.namprd06.prod.outlook.com (132.245.2.53) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 22:20:46 +0000 Received: from pine (132.248.10.10) by pod51011.outlook.com (10.255.195.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 13 Aug 2013 22:20:45 +0000 Date: Tue, 13 Aug 2013 22:20:59 +0000 From: Azael Fernandez Alcantara X-X-Sender: afaza@localhost.localdomain To: "Carlos M. Martinez" In-Reply-To: <520A82D9.2030602@gmail.com> Message-ID: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <18CD1C88-5F15-46BA-A76C-87F9A033E209@delong.com> <520A82D9.2030602@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [132.248.10.10] X-OriginatorOrg: unam.mx X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Tue, 13 Aug 2013 15:26:38 -0700 Cc: Alejandro Acosta , carlos@lacnic.net, IPv6 Ops WG Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:24:45 -0000 Hi all, I support the proposed Draft. However, after having read with some detail what has been commented, because some people have expressed concerns for a new preffix for documentation would require an update in filters, and the use of ULAs could create also confusion. I also agree with the fact that re-using the 3FFE::/16 prefix, for documentation purposes, would not harm newbies and veterans, because it is already filtered and an update of the RFCs refering to it would have to be done (RFC 3701). BEST, SALUDOS, ____________________________________ Azael UNAM Mexico On Tue, 13 Aug 2013, Carlos M. Martinez wrote: > Date: Tue, 13 Aug 2013 19:02:49 +0000 > From: Carlos M. Martinez > Reply-To: carlos@lacnic.net > To: Owen DeLong > Cc: Alejandro Acosta , IPv6 Ops WG , > carlos@lacnic.net > Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 > > Hello Owen, > > On 8/12/13 5:19 PM, Owen DeLong wrote: >> I think creating ambiguity with 3ffe would be a very very bad idea for this. > > I believe we the instructors should know better and have no problem > dealing with this. For newbies, they probably have never heard about 6bone. > > Unless there is equipment / software with hardcoded addresses in this > range, I don't see much of a problem. > > ~Carlos > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From markzzzsmith@yahoo.com.au Tue Aug 13 16:04:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB711E8171 for ; Tue, 13 Aug 2013 16:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=1.045, 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 FiY1O3Lr7MKV for ; Tue, 13 Aug 2013 16:04:48 -0700 (PDT) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7D11E80DE for ; Tue, 13 Aug 2013 16:04:48 -0700 (PDT) Received: from [66.196.81.170] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 23:04:47 -0000 Received: from [98.139.212.201] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 23:04:46 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 13 Aug 2013 23:04:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 974159.94014.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 63935 invoked by uid 60001); 13 Aug 2013 23:04:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1376435086; bh=4ACGA5xwlE0XkwLYAbFNaAqng1Wiqunih9gp0YeoJuE=; 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=eRFLftxhJ2YpxuXmgSpmzZjWAk7xvY7zX3yDPgOGOh8stp85cYUGglN41OOaSNi2wmlO+fT7D1tkhdMbIIgLGFHXRoxwOu7BMf7Y38VXEARTeHEMQemVB7ujBbYk0TFX/zadVHh2nCgJKKpqTXMrqDykT3rBjltcLor9XfyTsTA= 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=hXX/FL+Cn1zQEfdeyBWz/UPn83e+D+JKW+5vDK5rfPYaNKtX5hy3SbFzDKZuUdzqzCU1ToJAlE6midzO3G9cPUiUJiXUIYe8JkQSG+OuC7yofmJJVDrqn0qsssDQJwsrPtDmPbquMeHFlZmx9K9np1vRCjyNES6+FWVWyokSq1c=; X-YMail-OSG: 12MttsoVM1kH5hkYZfmHsiu6EsPJK4q.C70bE1PWJHhgpfX xBZmaxB1e6d9QByoXm7rCxWRy5TKdusFayeWLJY7_ijJwe9JSooKhettMWU1 ktv2z8KKYZxT8zeXyRhB73fP5Yj1LH_6mv7cR2WyKKO09Bm4J5BUG8zLdsbJ y17Y55tIsOrnBSg5t2oUwbtLJA3nFYl8SRekFumWe__K4qV8sAwhYWHEqYaY y87bLma6iz6HWzvvlS2_ICu11Xt50QhsVrCBMkbAHNzHAB6YzNzmhftfvUz8 hFYVQBXCkSAkmUQuptnJQfPwOHFlDGf3TEcAfqpQi3BSRmQ3.V.kL4f88cLJ _I0IzGjfRDlR6.A3IguFvjqcuxZslIN09BBiYq9eIbICxNJlvci9rHe3GrFT wzDlgD1OaC1JgCOUi7s6gK9AGXVjLhCGSGI56AZncbgI4IZn6vNjrwpxvC3C tPP5l28hY87FydOggoWPoc8Uym1KKI4VTGEZJEnGj9h2Y3HVmrW6kn5HL29g sEjB38rFpopLOKCS1HkAvF6C7Ryc_JlrwmHLdDTknHb5BzeB4KRSWw7wEezl _jvCjPcM5H5VsE69zI7MT1JoD2RfppMe10A-- Received: from [118.208.74.180] by web142506.mail.bf1.yahoo.com via HTTP; Tue, 13 Aug 2013 16:04:46 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiAiR2VvcmdlLCBXZXMiIDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBXZWRuZXNkYXksIDE0IEF1Z3VzdCAyMDEzIDY6NDggQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1tb3JlaXJhcy12Nm9wcy1yZmMzODQ5YmlzLTAwCj4gCj4gCj4gT24gQXVnIDEzLCAyMDEzLCBhdCAxMjoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> Message-ID: <1376435086.63006.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Tue, 13 Aug 2013 16:04:46 -0700 (PDT) From: Mark ZZZ Smith To: Owen DeLong , "George, Wes" In-Reply-To: <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:04:54 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: "George, Wes" =0A> Cc: "v6ops@ietf= .org" =0A> Sent: Wednesday, 14 August 2013 6:48 AM=0A> Subj= ect: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00=0A> =0A> =0A> On Aug 13= , 2013, at 12:58 , "George, Wes" =0A> wrote:=0A= > =0A>> =0A>> =0A>>=A0=0A=A0 =0A=0A=0A>>> =0A>> =0A>> [WEG] at the r= isk of debating bikeshed colors, I would suggest perhaps =0A> using :db8:: = for both the proposed GUA and ULA doc prefixes so that it serves as =0A> a = visual cue.=0A> =0A> I have no problem with that.=0A> =0A> How about 02db:8= 000::/20 and fc00:0db8::/32?=0A>=A0=0A=0AAs=A0fc00:0db8::/32 is from within= the existing but albeit unused portion of ULA prefix, any future use of fc= 00::/8 will need to specifically exclude it. I think exceptions to the norm= al case are better to avoid because they're another thing to remember, prog= ram as an exception case and therefore a prone to errors etc.=0A=0AI think = it would be better to specify a documentation ULA prefix that has the nearl= y the properties as conventional ULAs, but doesn't fall within fc00::/7 (pe= rhaps fe::/7 or something within it?). The only differences would be statem= ents about no forwarding, no accepting routes etc.=0A=0AUltimately though, = I think it is fundamentally impossible to prevent something silly like usin= g documentation prefixes on a production network, unless you use actually i= nvalid IPv6 prefixes. The only way I can think of to do that would be by do= ing things such as adding invalid hexadecimal 'g-z' numbers into the exampl= e prefixes. I'm not sure I like the idea, although it might cause people wh= o get tripped up on it to go back and think some more about what they're do= ing and put more effort into getting it right.=0A=0ARegards,=0AMark. From moreiras@nic.br Tue Aug 13 18:11:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D81A21E817A for ; Tue, 13 Aug 2013 18:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+oiSfaq5tGV for ; Tue, 13 Aug 2013 18:11:44 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9D21E808D for ; Tue, 13 Aug 2013 18:11:44 -0700 (PDT) Received: from sarierom-2.local (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 761372080145; Tue, 13 Aug 2013 22:11:43 -0300 (BRT) Message-ID: <520AD94F.1050604@nic.br> Date: Tue, 13 Aug 2013 22:11:43 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "George, Wes" References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 01:11:45 -0000 On 13/08/13 16:58, George, Wes wrote: >> The original proposal for a larger doc prefix is all about being able to >> > write books and training scenarios that use a doc prefix and talk about >> > carving up larger chunks of address space. > [WEG] The thing I don't understand about that is how carving x subnet blocks > out of a /32 is different from carving x blocks out of a /48 or x blocks out > of a /20 or whatever you start with as it concerns documentation. Other than > the prefix lengths being somewhat longer, the examples of how to subnet, how > to configure routing, etc still hold, don't they? AFAICT, as long as you > don't end up subnetting below /64, there's really no issue. Yes, real routing > policy likely won't pass a bunch of /64s, but for a lab such as what you > detailed, and the subtending documentation that should work just fine, no? > Especially given that the goal is to teach someone how to do something, > instead of simply giving them something to copy with no understanding of > what it's doing. For one of our trainings at NIC.br, each group of students have a small ISP with two PoPs. We try to follow the recommendations in this BCOP, for address planing: http://www.ipbcop.org/wp-content/uploads/2012/02/BCOP-IPv6_Subnetting.pdf Then, all ISPs in the lab connect to two upstreams for transit, two IXPs, and do private peering among themselves. We have a serie of exercises about traffic engineering, that depend on the address plan. Yes, we could use /48, instead of /32 for each ISP. But doing that, we could not follow strictly the BCOP recommendations. Yes, we could use a /32 from ULA space, instead of from GLA space. But we think it would generate confusion. I think we are not really talking about impossibilities, but about options. We are talking about to write documents easier to read, labs easier to understand. In some situations, for teaching, or writing scripts for labs, howtos, books, brochures, etc, it's better, simpler, easier, more precise, more clear, to use a prefix shorter than /32. In some situations we are doing that, and we have seen other groups doing the same. Moreiras. From marka@isc.org Tue Aug 13 18:15: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 6496A21F9928 for ; Tue, 13 Aug 2013 18:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, J_BACKHAIR_23=1, J_BACKHAIR_32=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 REWH24O1-4xP for ; Tue, 13 Aug 2013 18:14:56 -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 F2AF721E8064 for ; Tue, 13 Aug 2013 18:14:55 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 76EDBC94B0; Wed, 14 Aug 2013 01:14:42 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376442895; bh=op6KmsQHSHt++DwMLeH45r5jx2x5MU9qz9rxXviDmYE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=MAcPOIM0lN4dsCB+gL1yJa+v+A1wGIOq64BZz8wRkig1B3y4dwbBJ/Nj3lIn2Gfaw Ovsus0FiEhyxNJDP638vS7mtcd9Mer1xZ1pyE+d1hKHdZJQrfUhEvFmZyQwaYXTvOa ewBQhe12gwbTniVBwfIisDin5uFaFpC8uh8a2CWk= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 14 Aug 2013 01:14:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C4A4016043F; Wed, 14 Aug 2013 01:19:26 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id tCpoO_qvjSJg; Wed, 14 Aug 2013 01:19:22 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EFD6E16043D; Wed, 14 Aug 2013 01:19:21 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id BB1B916043C; Wed, 14 Aug 2013 01:19:21 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7A75C3851DE2; Wed, 14 Aug 2013 11:14:33 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> <20130813025336.918353846F7A@drugs.dv.isc.org> <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com> <20130813070157.6D9D5384B2C5@drugs.dv.isc.org> <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com> In-reply-to: Your message of "Tue, 13 Aug 2013 11:05:22 -0700." <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com> Date: Wed, 14 Aug 2013 11:14:33 +1000 Message-Id: <20130814011433.7A75C3851DE2@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 01:15:05 -0000 In message <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com>, Owen DeLong write s: > > > > With ULA you end up with: > > > > site1: P1, P2 announce P2 to site2 > > site2: P1, P3 announce P3 to site1 > > > > When you have two sites colliding on P1. (P1, P2 and P3 are different > > ULA prefixes). > > No, with ULA, the average IT group is going to start with: > > site 1: P1 > site 2: P1 > > They're going to not want to roll out a whole new addressing plan to both > sites, so, instead, they will do what they did in IPv4. > > P1<->NAT<->P2<->NAT<->P1 > > You need to come down out of whatever ivory tower you live in and look > at how things happen in the real world. Really how is what I am saying different to moving providers with PA addresses? We expect renumbering event to occur then. We expect ipv6 vendors to support this sort of renumbering. You bring up the new prefix along side the old prefix. You decommission the old prefix. The only difference is delaying decommissioning the old prefix longer if not forever. > > You have IP stacks that are designed to deal with multiple prefixes > > and to choose particular source addresses for particular destination > > addresses. > > > > You have applications that are designed to deal with multiple > > addresses. > > > > IPv4 only stacks don't have all of these features which forces one > > to use NAT. > > None of that overcomes the realities if modern corporate IT staffing. > > > With IPv6 they are there so you can depend on them and take advantage > > of them. If P2 and P3 differ only in the 48th bit longest match > > will select the right source address. > > If you know about them. > If you're willing to put in the effort to use them. > If you completely understand them. > IF and only IF all of your applications are actually that savvy. > etc. If you are using ULA along side GUA then yes the applications and stacks will do the right thing already which is almost certainly what you will be doing if you are using ULA in the first place. > For most enterprises, the answer to at least one of those IFs will fail. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From internet-drafts@ietf.org Tue Aug 13 18:49: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 EF8B211E81E1; Tue, 13 Aug 2013 18:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, 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 td5vEiQsqyKv; Tue, 13 Aug 2013 18:49:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4611E80FF; Tue, 13 Aug 2013 18:49:45 -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.70.p1 Message-ID: <20130814014945.13549.14316.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 18:49:45 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 01:49:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Operational Guidelines for Datacenters Author(s) : Diego R. Lopez Zhonghua Chen Tina Tsou Cathy Zhou Arturo Servin Filename : draft-ietf-v6ops-dc-ipv6-00.txt Pages : 21 Date : 2013-08-13 Abstract: This document is intended to provide operational guidelines for datacenter operators planning to deploy IPv6 in their infrastructures. It aims to offer a reference framework for evaluating different products and architectures, and therefore it is also addressed to manufacturers and solution providers, so they can use it to gauge their solutions. We believe this will translate in a smoother and faster IPv6 transition for datacenters of these infrastuctures. The document focuses on the DC infrastructure itself, its operation, and the aspects related to DC interconnection through IPv6. It does not consider the particular mechanisms for making Internet services provided by applications hosted in the DC available through IPv6 beyond the specific aspects related to how their deployment on the Data Center (DC) infrastructure. Apart from facilitating the transition to IPv6, the mechanisms outlined here are intended to make this transition as transparent as possible (if not completely transparent) to applications and services running on the DC infrastructure, as well as to take advantage of IPv6 features to simplify DC operations, internally and across the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dc-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-dc-ipv6-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From markzzzsmith@yahoo.com.au Tue Aug 13 18:55: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 3B43421F8F9A for ; Tue, 13 Aug 2013 18:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO5owrZCWom3 for ; Tue, 13 Aug 2013 18:55:00 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3758B21F9702 for ; Tue, 13 Aug 2013 18:54:36 -0700 (PDT) Received: from [98.139.212.153] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 14 Aug 2013 01:54:36 -0000 Received: from [98.139.212.195] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 14 Aug 2013 01:54:35 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 14 Aug 2013 01:54:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 977249.56990.bm@omp1004.mail.bf1.yahoo.com Received: (qmail 16548 invoked by uid 60001); 14 Aug 2013 01:54:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1376445275; bh=nZhcZfswnTwVBfjLEgCS12I0k+AIDuuB3XQUT1A7OUQ=; 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=wLtHzQHsXyo3QFvqffxuXFjJJoLfyWOPboLTKPogGQ441R4JxljyfF91mbwcy3IWjN/umEqUCwma8TV/mrQZZj2CmBZF9q3ngpGNezbOj5rXKJEcp2n7q23+ZqRA4eNBuLArIjkHrSYHG4i2+AIxaAzslfgiZ1wXCDdvITNNd8c= 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=qFKX4wiXS1FxKce9FeUDvhb+G7XayewwYWPnIds66Yw7C/YGsOhvIjRdYDD8jV1ySJWHnrRPNxr2o5H0yI4m5j3JjaxBN9FpHV98aSJqp9RuMKg6pFB8mDgNdU+IxMKi/khm+Kp01PZPUILdZ0uUqG3f8VyspZn2BOhQ0plQMS0=; X-YMail-OSG: jW8baZUVM1n7BW9Lhf9SAYgg1JKSLvPauwp99BHnhTCmiUe nEDOAhOlMfO6ktacGEZE_R8qbcLQpo8wrIJnl7kLH_7jfkfwVMFSNlUT7sjq zWlTu6E00a1YGiQfUiHfQZS582E6AJ7JXB6Ow_Gi7mHzkijSOj1vYMUV_PbP as9H7e8AfUnIwVh.9g8OAe.zyq7kVBv4yrLSWcErmW6bTwD3FKP.RFiHKw2T 0vhtGFnHjY0SKRPb1VzqH9nCILIlb9fj8q7qKST63urYRHAPHDGcpPsnE_xZ IjNiGae.HM4TYvHehoNQchE6KdSpmgfKKIBnWg505fxVCVWpWKgTbITmS49n UEDgDG8sFneEsKVwkFj0qW6Zi.aV32dmsxOzhyeS8vRhf9clgOwK3WdvhjHx 0CHFD_X0QgUhUaeStVbCWXK9tEzhyQaZwbey3yDqgGLt38NxTrNoLIuL2pWI _MxTKIUPESXZlWoGJhgboNzSIk8llliodg3FagXRli666_uy3RAsBCM_MS2g xE5w8U._8FpXPqZ4fMjmL2zwsmr6fbHEJfEU1ss84V50BYbaTzC8tGUCMaN. fMWY8kcrM7V2cmDBvYRCwPxbdNCEuCwikTgaF0pxDBU9Mano1XKAWtizwr2R YYI4Y5.Y8sDm2SPIzVtYSn2wnyWkYlGqI5sOkIyQ.fTevJpGKS7YCus33n9t 632U_zbZqoHJwW_7_cIEqbnSLwsJQ6Vrq11uROvv1WYJgL4hrQN9mXryR_E0 OlZaKOCsTjf3SCm2g Received: from [118.208.74.180] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 13 Aug 2013 18:54:35 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbnRvbmlvIE0uIE1vcmVpcmFzIDxtb3JlaXJhc0BuaWMuYnI.Cj4gVG86ICJHZW9yZ2UsIFdlcyIgPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFdlZG5lc2RheSwgMTQgQXVndXN0IDIwMTMgMTE6MTEgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1tb3JlaXJhcy12Nm9wcy1yZmMzODQ5YmlzLTAwCj4gCj4gT24gMTMvMDgvMTMgMTY6NTgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <520AD94F.1050604@nic.br> Message-ID: <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 13 Aug 2013 18:54:35 -0700 (PDT) From: Mark ZZZ Smith To: "Antonio M. Moreiras" , "George, Wes" In-Reply-To: <520AD94F.1050604@nic.br> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 01:55:05 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Antonio M. Moreiras =0A> To: "George, Wes" =0A> Cc: "v6= ops@ietf.org" =0A> Sent: Wednesday, 14 August 2013 11:11 AM= =0A> Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00=0A> =0A> On 13= /08/13 16:58, George, Wes wrote:=0A> =0A>>> The original proposal for a la= rger doc prefix is all about being able =0A> to=0A>>> > write books and tr= aining scenarios that use a doc prefix and talk =0A> about=0A>>> > carving= up larger chunks of address space.=0A> =0A>> [WEG] The thing I don't unde= rstand about that is how carving x subnet =0A> blocks =0A>> out of a /32 i= s different from carving x blocks out of a /48 or x blocks =0A> out=A0 > of= a /20 or whatever you start with as it concerns documentation.=0A> Other t= han=0A>> the prefix lengths being somewhat longer, the examples of how to = subnet, =0A> how =0A>> to configure routing, etc still hold, don't they? A= FAICT, as long as =0A> you =0A>> don't end up subnetting below /64, there'= s really no issue. Yes, =0A> real routing =0A>> policy likely won't pass a= bunch of /64s, but for a lab such as what =0A> you =0A>> detailed, and th= e subtending documentation that should work just fine, no? =0A>> Especiall= y given that the goal is to teach someone how to do something, =0A>> inste= ad of simply giving them something to copy with no understanding of =0A>> = what it's doing.=0A> =0A> For one of our trainings at NIC.br, each group of= students have a small=0A> ISP with two PoPs. We try to follow the recommen= dations in this BCOP,=0A> for address planing:=0A> =0A> http://www.ipbcop.o= rg/wp-content/uploads/2012/02/BCOP-IPv6_Subnetting.pdf=0A> =0A> Then, all I= SPs in the lab connect to two upstreams for transit, two=0A> IXPs, and do p= rivate peering among themselves. We have a serie of=0A> exercises about tra= ffic engineering, that depend on the address plan.=0A> =0A> Yes, we could u= se /48, instead of /32 for each ISP. But doing that, we=0A> could not follo= w strictly the BCOP recommendations.=0A=0AISPs don't just get a /32, they c= an get larger if they need it. Placing too much value on using a /32 in you= r examples can strongly imply that all IPv6 addressing plans must fit withi= n a /32.=0A=0AThe trouble is that if you are too prescriptive, it then crea= tes opportunities for people to be lazy in their learning. They rote learn = rather than understand, and that means they may not be able to cope with th= e situation is even the slightest bit different.=A0=0A=0A=0AI think teachin= g people to subnet using a range of bits should be taught first, so that th= ey can work with a range allocations. Whether it is a /32, a /48 or a /29 t= hen doesn't matter.=A0Then give examples of how to apply those techniques t= o various sized IPv6 prefixes to re-enforce the methods.=0A=0A> Yes, we cou= ld use a=0A> /32 from ULA space, instead of from GLA space. But we think it= would=0A> generate confusion.=0A> =0A> I think we are not really talking a= bout impossibilities, but about=0A> options. We are talking about to write = documents easier to read, labs=0A> easier to understand.=0A>=A0=0A> In some= situations, for teaching, or writing scripts for labs, howtos,=0A=0A> book= s, brochures, etc, it's better, simpler, easier, more precise, more=0A> cle= ar, to use a prefix shorter than /32. In some situations we are doing=0A> t= hat, and we have seen other groups doing the same.=0A>=A0=0A> Moreiras.=0A= =0A> =0A> _______________________________________________=0A> v6ops mailing= list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A= > From moreiras@nic.br Tue Aug 13 21:08: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 9DADD21E8095 for ; Tue, 13 Aug 2013 21:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5SoBCB-VewQ for ; Tue, 13 Aug 2013 21:08:09 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5011E8116 for ; Tue, 13 Aug 2013 21:08:08 -0700 (PDT) Received: from sarierom-2.local (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 82EFA2080196; Wed, 14 Aug 2013 01:07:57 -0300 (BRT) Message-ID: <520B029C.3010308@nic.br> Date: Wed, 14 Aug 2013 01:07:56 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark ZZZ Smith References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <520AD94F.1050604@nic.br> <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 04:08:13 -0000 On 13/08/13 22:54, Mark ZZZ Smith wrote: > ----- Original Message ----- >> For one of our trainings at NIC.br, each group of students have a small >> ISP with two PoPs. We try to follow the recommendations in this BCOP, >> for address planing: >> >> http://www.ipbcop.org/wp-content/uploads/2012/02/BCOP-IPv6_Subnetting.pdf >> >> Then, all ISPs in the lab connect to two upstreams for transit, two >> IXPs, and do private peering among themselves. We have a serie of >> exercises about traffic engineering, that depend on the address plan. >> >> Yes, we could use /48, instead of /32 for each ISP. But doing that, we >> could not follow strictly the BCOP recommendations. > > ISPs don't just get a /32, they can get larger if they need it. Placing too much value on using a /32 in your examples can strongly imply that all IPv6 addressing plans must fit within a /32. We are the NIR in our country, we are aware of that. But the vast majority of our allocations are indeed /32. The BCOP are also aware of that, and if we want a experiment where we can follow strictly its recommendations, then we need a /32 or something shorter. > The trouble is that if you are too prescriptive, it then creates opportunities for people to be lazy in their learning. They rote learn rather than understand, and that means they may not be able to cope with the situation is even the slightest bit different. > > I think teaching people to subnet using a range of bits should be taught first, so that they can work with a range allocations. Whether it is a /32, a /48 or a /29 then doesn't matter. Then give examples of how to apply those techniques to various sized IPv6 prefixes to re-enforce the methods. My team have been working with IPv6 trainings for 4 years. We trained more than 3000 people, from hundreds of ISPs, in a 36h (1 week) hands on course during this time, 32 people in each class. We tried a lot of different approaches in these years. I don't want to appear rude, or smug. I am just trying to demonstrate that we do have some experience in this task, and that we know our specific public. I can't say you are wrong. Your suggestions are good. Things can be done the way you are proposing. But we would prefer, for now and based on our previous experience, to do them the way I described before. I would like also to stress the point that we are not the only group working with IPv6 learning, using prefixes other than 2001:db8::/32 in labs and documents. >> Yes, we could use a >> /32 from ULA space, instead of from GLA space. But we think it would >> generate confusion. >> >> I think we are not really talking about impossibilities, but about >> options. We are talking about to write documents easier to read, labs >> easier to understand. >> >> In some situations, for teaching, or writing scripts for labs, howtos, > >> books, brochures, etc, it's better, simpler, easier, more precise, more >> clear, to use a prefix shorter than /32. In some situations we are doing >> that, and we have seen other groups doing the same. >> >> Moreiras. From moreiras@nic.br Wed Aug 14 02:58: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 2F87E11E8142 for ; Wed, 14 Aug 2013 02:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0IJaNQP0LMl for ; Wed, 14 Aug 2013 02:58:02 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB7A11E811E for ; Wed, 14 Aug 2013 02:58:02 -0700 (PDT) Received: from sarierom-2.local (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id B9690208012C for ; Wed, 14 Aug 2013 06:57:52 -0300 (BRT) Message-ID: <520B54A0.4040708@nic.br> Date: Wed, 14 Aug 2013 06:57:52 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <18CD1C88-5F15-46BA-A76C-87F9A033E209@delong.com> <520A82D9.2030602@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:58:03 -0000 On 13/08/13 19:20, Azael Fernandez Alcantara wrote: > I also agree with the fact that re-using the 3FFE::/16 prefix, for > documentation purposes, would not harm newbies and veterans, because it > is already filtered and an update of the RFCs refering to it would have > to be done (RFC 3701). I can't see any drawbacks. I think it would be a good choice. Moreiras. From cpraveen@juniper.net Wed Aug 14 03:53: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 823B721E80AA for ; Wed, 14 Aug 2013 03:53:07 -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.299, 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 3q+TEsR5gYft for ; Wed, 14 Aug 2013 03:53:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB1B721E80A8 for ; Wed, 14 Aug 2013 03:52:59 -0700 (PDT) Received: from mail34-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Aug 2013 10:52:58 +0000 Received: from mail34-va3 (localhost [127.0.0.1]) by mail34-va3-R.bigfish.com (Postfix) with ESMTP id 82ECA4E017E for ; Wed, 14 Aug 2013 10:52:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: PS2(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz17326ah18c673h1de096h8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail34-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cpraveen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(74316001)(80022001)(65816001)(63696002)(76176001)(81542001)(15202345003)(77982001)(59766001)(66066001)(81342001)(46102001)(81686001)(76796001)(53806001)(81816001)(54356001)(80976001)(79102001)(74876001)(51856001)(50986001)(47736001)(69226001)(49866001)(16406001)(4396001)(47976001)(74706001)(19580385001)(74662001)(83072001)(31966008)(74502001)(47446002)(56816003)(76786001)(77096001)(74366001)(76576001)(83322001)(54316002)(56776001)(76482001)(33646001)(19580395003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB067; H:BL2PR05MB068.namprd05.prod.outlook.com; CLIP:116.197.178.92; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail34-va3 (localhost.localdomain [127.0.0.1]) by mail34-va3 (MessageSwitch) id 1376477535102285_31920; Wed, 14 Aug 2013 10:52:15 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.236]) by mail34-va3.bigfish.com (Postfix) with ESMTP id 0A3A24C0041 for ; Wed, 14 Aug 2013 10:52:15 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 10:52:14 +0000 Received: from BL2PR05MB067.namprd05.prod.outlook.com (10.255.232.22) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 10:52:14 +0000 Received: from BL2PR05MB068.namprd05.prod.outlook.com (10.255.232.23) by BL2PR05MB067.namprd05.prod.outlook.com (10.255.232.22) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 14 Aug 2013 10:52:06 +0000 Received: from BL2PR05MB068.namprd05.prod.outlook.com ([169.254.3.18]) by BL2PR05MB068.namprd05.prod.outlook.com ([169.254.3.18]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 10:52:05 +0000 From: Praveen Chaudhary To: "v6ops@ietf.org" Thread-Topic: [v6ops]RFC 4291, link local address defination Thread-Index: Ac6Y3E6BEi4L5FK7Txiv+6sYKwWmjA== Date: Wed, 14 Aug 2013 10:52:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.92] x-forefront-prvs: 0938781D02 Content-Type: multipart/alternative; boundary="_000_fbee5f0026234d29a904f12fd992947fBL2PR05MB068namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [v6ops] RFC 4291, link local address defination X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Aug 2013 10:53:07 -0000 --_000_fbee5f0026234d29a904f12fd992947fBL2PR05MB068namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi As per RFC 4291 section 2.5.6 link local address are defines with the prefi= x fe80::/64, but many definition says even fe80::/10 qualifies as link loca= l address. Like on wiki: "In the Internet Protocol Version 6 (IPv= 6), the address block fe80::/10 has been reserved for link-local unicast ad= dressing.[2] The actual li= nk local addresses are assigned with the prefix fe80::/64.[6][note 2] They may be assigned by automatic (stateless) or stateful= e.g. manual) mechanisms." So if we have an address as below, which does not match prefix condition, h= ow an implementation should treat them. fe80:4888:208:ff8b:aa:21:0:2 process as global address surely not ??, but as link local , it does not qu= alify. Kindly suggest. Sorry if I am repeating a thread, Thanks & Regards Praveen Juniper Networks --_000_fbee5f0026234d29a904f12fd992947fBL2PR05MB068namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
As per RFC 4291 section 2.5.6 link local address are defines with the = prefix fe80::/64, but many definition says even fe80::/10 qualifies as link= local address.
Like on wiki:
“In the Inter= net Protocol Version 6 (IPv6), the address block fe80::/10 has bee= n reserved for link-local unicast addressing.[2] The actual link local addresses are assigned with the prefix fe80::/64.[6][note 2] They may be assigned by automatic (stateles= s) or stateful e.g. manual) mechanisms.”
&nbs= p;
So if we have an address as below, which does not match prefix conditi= on, how an implementation should treat them.
fe80:4888:208:ff8b:aa:21:0:2
&nbs= p;
process as global address surely not ??, but as link local , it does n= ot qualify. Kindly suggest.
&nbs= p;
Sorry if I am repeating a thread,
&nbs= p;
Thanks & Regards
Praveen
Juniper Networks
 
&nbs= p;
&nbs= p;
 --_000_fbee5f0026234d29a904f12fd992947fBL2PR05MB068namprd05pro_-- From otroan@employees.org Wed Aug 14 04:31: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 004CA11E81AB for ; Wed, 14 Aug 2013 04:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aog+kaetaZT for ; Wed, 14 Aug 2013 04:31:24 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 8742111E8131 for ; Wed, 14 Aug 2013 04:31:24 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-13.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 510485E9C; Wed, 14 Aug 2013 04:31:22 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Wed, 14 Aug 2013 13:31:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Praveen Chaudhary X-Mailer: Apple Mail (2.1508) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 4291, link local address defination X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Aug 2013 11:31:25 -0000 Praveen, > As per RFC 4291 section 2.5.6 link local address are defines with the = prefix fe80::/64, but many definition says even fe80::/10 qualifies as = link local address. > Like on wiki: > =93In the Internet Protocol Version 6 (IPv6), the address block = fe80::/10 has been reserved for link-local unicast addressing.[2] The = actual link local addresses are assigned with the prefix = fe80::/64.[6][note 2] They may be assigned by automatic (stateless) or = stateful e.g. manual) mechanisms.=94 > =20 > So if we have an address as below, which does not match prefix = condition, how an implementation should treat them. > fe80:4888:208:ff8b:aa:21:0:2 > =20 > process as global address surely not ??, but as link local , it does = not qualify. Kindly suggest. FE80::/10 are reserved for link-local addresses, so they should be = treated as link-locals in your implementation. RFC4291 does not say that link-local addresses must be assigned from = FE80::/64. it states that the prefix must be followed by 54 bits of 0. I = agree that RFC4291 is a little ambiguous, and that the link-local = address format should be defined like the global unicast address in = section 2.5.4. cheers, Ole= From cpraveen@juniper.net Wed Aug 14 04:40: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 DB76011E81F4 for ; Wed, 14 Aug 2013 04:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.650, 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 IC24xV9r+d33 for ; Wed, 14 Aug 2013 04:40:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9175711E81ED for ; Wed, 14 Aug 2013 04:40:24 -0700 (PDT) Received: from mail204-tx2-R.bigfish.com (10.9.14.230) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 11:40:23 +0000 Received: from mail204-tx2 (localhost [127.0.0.1]) by mail204-tx2-R.bigfish.com (Postfix) with ESMTP id 01712A8007E; Wed, 14 Aug 2013 11:40:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail204-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cpraveen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(189002)(199002)(377454003)(13464003)(56816003)(47446002)(74502001)(74366001)(76786001)(77096001)(76576001)(76796001)(83072001)(83322001)(31966008)(74662001)(19580405001)(19580395003)(56776001)(33646001)(81816001)(59766001)(54316002)(76482001)(81542001)(46102001)(66066001)(63696002)(77982001)(81342001)(74316001)(80022001)(54356001)(53806001)(51856001)(69226001)(47976001)(74706001)(65816001)(16406001)(49866001)(4396001)(47736001)(79102001)(80976001)(81686001)(50986001)(74876001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB068; H:BL2PR05MB068.namprd05.prod.outlook.com; CLIP:116.197.178.92; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail204-tx2 (localhost.localdomain [127.0.0.1]) by mail204-tx2 (MessageSwitch) id 1376480421643763_28575; Wed, 14 Aug 2013 11:40:21 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.250]) by mail204-tx2.bigfish.com (Postfix) with ESMTP id 8F1921C0041; Wed, 14 Aug 2013 11:40:21 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 11:40:21 +0000 Received: from BL2PR05MB068.namprd05.prod.outlook.com (10.255.232.23) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 11:40:20 +0000 Received: from BL2PR05MB068.namprd05.prod.outlook.com (10.255.232.23) by BL2PR05MB068.namprd05.prod.outlook.com (10.255.232.23) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 14 Aug 2013 11:40:13 +0000 Received: from BL2PR05MB068.namprd05.prod.outlook.com ([169.254.3.18]) by BL2PR05MB068.namprd05.prod.outlook.com ([169.254.3.18]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 11:40:13 +0000 From: Praveen Chaudhary To: Ole Troan , "v6ops@ietf.org" Thread-Topic: [v6ops] RFC 4291, link local address defination Thread-Index: AQHOmOHjzwpcrsodYEWoBjaokB5Us5mUk1HQ Date: Wed, 14 Aug 2013 11:40:12 +0000 Message-ID: <9c7c6df802614956a26a282513b9cdd4@BL2PR05MB068.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.92] x-forefront-prvs: 0938781D02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [v6ops] RFC 4291, link local address defination X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Aug 2013 11:40:32 -0000 Thanks Ole Yeah that's is the problem here, RFC 4291 says it must be followed by 54 bi= ts of 0.=20 So many implementations which may put this constraint and in such case fe80= :4888:208:ff8b:aa:21:0:2 may get discarded. Should not we have one fix definition :). Thanks & Regards Praveen Juniper Networks -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Wednesday, August 14, 2013 5:01 PM To: Praveen Chaudhary Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 4291, link local address defination Praveen, > As per RFC 4291 section 2.5.6 link local address are defines with the pre= fix fe80::/64, but many definition says even fe80::/10 qualifies as link lo= cal address. > Like on wiki: > "In the Internet Protocol Version 6 (IPv6), the address block fe80::/10 h= as been reserved for link-local unicast addressing.[2] The actual link loca= l addresses are assigned with the prefix fe80::/64.[6][note 2] They may be = assigned by automatic (stateless) or stateful e.g. manual) mechanisms." > =20 > So if we have an address as below, which does not match prefix condition,= how an implementation should treat them. > fe80:4888:208:ff8b:aa:21:0:2 > =20 > process as global address surely not ??, but as link local , it does not = qualify. Kindly suggest. FE80::/10 are reserved for link-local addresses, so they should be treated = as link-locals in your implementation. RFC4291 does not say that link-local addresses must be assigned from FE80::= /64. it states that the prefix must be followed by 54 bits of 0. I agree th= at RFC4291 is a little ambiguous, and that the link-local address format sh= ould be defined like the global unicast address in section 2.5.4. cheers, Ole From otroan@employees.org Wed Aug 14 04:52:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3A221E8084 for ; Wed, 14 Aug 2013 04:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZlQPy5FFcXx for ; Wed, 14 Aug 2013 04:52:30 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33F21E805D for ; Wed, 14 Aug 2013 04:52:30 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-13.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 77DA05FB3; Wed, 14 Aug 2013 04:52:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <9c7c6df802614956a26a282513b9cdd4@BL2PR05MB068.namprd05.prod.outlook.com> Date: Wed, 14 Aug 2013 13:52:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9c7c6df802614956a26a282513b9cdd4@BL2PR05MB068.namprd05.prod.outlook.com> To: Praveen Chaudhary X-Mailer: Apple Mail (2.1508) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 4291, link local address defination X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Aug 2013 11:52:36 -0000 Praveen, > Yeah that's is the problem here, RFC 4291 says it must be followed by = 54 bits of 0.=20 > So many implementations which may put this constraint and in such case = fe80:4888:208:ff8b:aa:21:0:2 may get discarded. > Should not we have one fix definition :). probably. the formation of the link-local address is link-specific. = which link-layer do you see this problem? or is this manual configuration? I remember BSD used to put interface = index in those bits, but I can't remember if they masked out those bits = before putting packets on the wire. cheers, Ole >=20 > Thanks & Regards > Praveen > Juniper Networks >=20 >=20 > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org]=20 > Sent: Wednesday, August 14, 2013 5:01 PM > To: Praveen Chaudhary > Cc: v6ops@ietf.org > Subject: Re: [v6ops] RFC 4291, link local address defination >=20 > Praveen, >=20 >> As per RFC 4291 section 2.5.6 link local address are defines with the = prefix fe80::/64, but many definition says even fe80::/10 qualifies as = link local address. >> Like on wiki: >> "In the Internet Protocol Version 6 (IPv6), the address block = fe80::/10 has been reserved for link-local unicast addressing.[2] The = actual link local addresses are assigned with the prefix = fe80::/64.[6][note 2] They may be assigned by automatic (stateless) or = stateful e.g. manual) mechanisms." >>=20 >> So if we have an address as below, which does not match prefix = condition, how an implementation should treat them. >> fe80:4888:208:ff8b:aa:21:0:2 >>=20 >> process as global address surely not ??, but as link local , it does = not qualify. Kindly suggest. >=20 > FE80::/10 are reserved for link-local addresses, so they should be = treated as link-locals in your implementation. >=20 > RFC4291 does not say that link-local addresses must be assigned from = FE80::/64. it states that the prefix must be followed by 54 bits of 0. I = agree that RFC4291 is a little ambiguous, and that the link-local = address format should be defined like the global unicast address in = section 2.5.4. >=20 > cheers, > Ole >=20 From cpraveen@juniper.net Wed Aug 14 05:11:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4E11E80EC for ; Wed, 14 Aug 2013 05:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIml8e3cYCra for ; Wed, 14 Aug 2013 05:11:13 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8BD11E8153 for ; Wed, 14 Aug 2013 05:11:13 -0700 (PDT) Received: from mail183-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE022.bigfish.com (10.236.130.85) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 12:11:11 +0000 Received: from mail183-co9 (localhost [127.0.0.1]) by mail183-co9-R.bigfish.com (Postfix) with ESMTP id 2C443D2011E; Wed, 14 Aug 2013 12:11:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail183-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cpraveen@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(377454003)(13464003)(77096001)(74366001)(76786001)(47446002)(74502001)(56816003)(83322001)(76576001)(31966008)(83072001)(74662001)(19580405001)(33646001)(19580395003)(56776001)(54316002)(76482001)(77982001)(59766001)(46102001)(81342001)(66066001)(74316001)(80022001)(81542001)(63696002)(65816001)(50986001)(47736001)(74876001)(51856001)(47976001)(16406001)(49866001)(69226001)(4396001)(74706001)(76796001)(81686001)(80976001)(79102001)(53806001)(54356001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB067; H:BL2PR05MB068.namprd05.prod.outlook.com; CLIP:116.197.178.92; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail183-co9 (localhost.localdomain [127.0.0.1]) by mail183-co9 (MessageSwitch) id 1376482269300056_24600; Wed, 14 Aug 2013 12:11:09 +0000 (UTC) Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.230]) by mail183-co9.bigfish.com (Postfix) with ESMTP id 42FD9DA00A2; Wed, 14 Aug 2013 12:11:09 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 12:11:05 +0000 Received: from BL2PR05MB067.namprd05.prod.outlook.com (10.255.232.22) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 12:11:04 +0000 Received: from BL2PR05MB068.namprd05.prod.outlook.com (10.255.232.23) by BL2PR05MB067.namprd05.prod.outlook.com (10.255.232.22) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 14 Aug 2013 12:11:03 +0000 Received: from BL2PR05MB068.namprd05.prod.outlook.com ([169.254.3.18]) by BL2PR05MB068.namprd05.prod.outlook.com ([169.254.3.18]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 12:11:03 +0000 From: Praveen Chaudhary To: Ole Troan Thread-Topic: [v6ops] RFC 4291, link local address defination Thread-Index: AQHOmOHjzwpcrsodYEWoBjaokB5Us5mUk1HQgAAEaACAAAPxYA== Date: Wed, 14 Aug 2013 12:11:02 +0000 Message-ID: <701a6d1a760a4bed9fd09da9445637fa@BL2PR05MB068.namprd05.prod.outlook.com> References: <9c7c6df802614956a26a282513b9cdd4@BL2PR05MB068.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.178.92] x-forefront-prvs: 0938781D02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 4291, link local address defination X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Aug 2013 12:11:19 -0000 These are manually configured on irb(logical) interface. (I was wondering i= f this config is correct). Thanks & Regards Praveen Juniper Networks -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Wednesday, August 14, 2013 5:22 PM To: Praveen Chaudhary Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC 4291, link local address defination Praveen, > Yeah that's is the problem here, RFC 4291 says it must be followed by 54 = bits of 0.=20 > So many implementations which may put this constraint and in such case fe= 80:4888:208:ff8b:aa:21:0:2 may get discarded. > Should not we have one fix definition :). probably. the formation of the link-local address is link-specific. which l= ink-layer do you see this problem? or is this manual configuration? I remember BSD used to put interface index= in those bits, but I can't remember if they masked out those bits before p= utting packets on the wire. cheers, Ole >=20 > Thanks & Regards > Praveen > Juniper Networks >=20 >=20 > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org]=20 > Sent: Wednesday, August 14, 2013 5:01 PM > To: Praveen Chaudhary > Cc: v6ops@ietf.org > Subject: Re: [v6ops] RFC 4291, link local address defination >=20 > Praveen, >=20 >> As per RFC 4291 section 2.5.6 link local address are defines with the pr= efix fe80::/64, but many definition says even fe80::/10 qualifies as link l= ocal address. >> Like on wiki: >> "In the Internet Protocol Version 6 (IPv6), the address block fe80::/10 = has been reserved for link-local unicast addressing.[2] The actual link loc= al addresses are assigned with the prefix fe80::/64.[6][note 2] They may be= assigned by automatic (stateless) or stateful e.g. manual) mechanisms." >>=20 >> So if we have an address as below, which does not match prefix condition= , how an implementation should treat them. >> fe80:4888:208:ff8b:aa:21:0:2 >>=20 >> process as global address surely not ??, but as link local , it does not= qualify. Kindly suggest. >=20 > FE80::/10 are reserved for link-local addresses, so they should be treate= d as link-locals in your implementation. >=20 > RFC4291 does not say that link-local addresses must be assigned from FE80= ::/64. it states that the prefix must be followed by 54 bits of 0. I agree = that RFC4291 is a little ambiguous, and that the link-local address format = should be defined like the global unicast address in section 2.5.4. >=20 > cheers, > Ole >=20 From wesley.george@twcable.com Wed Aug 14 05:40: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 5725D11E8152 for ; Wed, 14 Aug 2013 05:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0YRRFwzj4iX for ; Wed, 14 Aug 2013 05:40:12 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E56D821F9F77 for ; Wed, 14 Aug 2013 05:40:11 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,876,1367985600"; d="scan'208";a="117527093" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 14 Aug 2013 08:39:09 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 14 Aug 2013 08:40:10 -0400 From: "George, Wes" To: "Antonio M. Moreiras" , Mark ZZZ Smith Date: Wed, 14 Aug 2013 08:40:08 -0400 Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: Ac6Yo93fOvn8L0LMRBeZujFUh7sKSwARQVjA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439B6F9C3@PRVPEXVS15.corp.twcable.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <520AD94F.1050604@nic.br> <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com> <520B029C.3010308@nic.br> In-Reply-To: <520B029C.3010308@nic.br> 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" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 12:40:16 -0000 > From: Antonio M. Moreiras [mailto:moreiras@nic.br] > > On 13/08/13 22:54, Mark ZZZ Smith wrote: > > ----- Original Message ----- > >> For one of our trainings at NIC.br, [snip] > > > > ISPs don't just get a /32, they can get larger if they need it. > Placing too much value on using a /32 in your examples can strongly > imply that all IPv6 addressing plans must fit within a /32. > > We are the NIR in our country, we are aware of that. But the vast > majority of our allocations are indeed /32. The BCOP are also aware of > that, and if we want a experiment where we can follow strictly its > recommendations, then we need a /32 or something shorter. > > > The trouble is that if you are too prescriptive, it then creates > opportunities for people to be lazy in their learning. They rote learn > rather than understand, and that means they may not be able to cope with > the situation is even the slightest bit different. > > > > I think teaching people to subnet using a range of bits should be > taught first, so that they can work with a range allocations. Whether it > is a /32, a /48 or a /29 then doesn't matter. Then give examples of how > to apply those techniques to various sized IPv6 prefixes to re-enforce > the methods. > [WEG] +1. I think there's a fine line between trying to avoid confusion and= making it too easy to verbatim copy something without understanding it. > My team have been working with IPv6 trainings for 4 years. We trained > more than 3000 people, from hundreds of ISPs, in a 36h (1 week) hands on > course during this time, 32 people in each class. We tried a lot of > different approaches in these years. I don't want to appear rude, or > smug. I am just trying to demonstrate that we do have some experience in > this task, and that we know our specific public. I can't say you are > wrong. Your suggestions are good. Things can be done the way you are > proposing. But we would prefer, for now and based on our previous > experience, to do them the way I described before. > > I would like also to stress the point that we are not the only group > working with IPv6 learning, using prefixes other than 2001:db8::/32 in > labs and documents. > > >> Yes, we could use a > >> /32 from ULA space, instead of from GLA space. But we think it would > >> generate confusion. > >> > >> I think we are not really talking about impossibilities, but about > >> options. We are talking about to write documents easier to read, labs > >> easier to understand. > >> > >> In some situations, for teaching, or writing scripts for labs, > howtos, > > > >> books, brochures, etc, it's better, simpler, easier, more precise, > more > >> clear, to use a prefix shorter than /32. In some situations we are > doing > >> that, and we have seen other groups doing the same. > >> [WEG] I think over the course of this discussion, you've built a reasonable= case for this with real-world examples to back up your assertions. However= , just as teachers like you to show your work when solving a math problem, = I strongly suggest that you revise the draft to include this supporting inf= ormation in order to build the case, else you'll have this conversation eve= ry time someone reads the draft and is skeptical that more space is needed.= I realize that 3849 is light on justification and you patterned this draft= after that document, but few would argue that at least one prefix for docu= mentation is necessary and appropriate. As you've seen, fewer are convinced= that additional prefixes or larger prefixes are needed without some backgr= ound information from those with experience in training and documentation t= hat have observed some real-world problems with the current solution. I can= 't guarantee that you won't have more "you're doing it wrong" arguments, bu= t at least you're demonstrating that it's not an arbitrary request. Wes George Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Wed Aug 14 05:45: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 7531B11E81CD for ; Wed, 14 Aug 2013 05:45:08 -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 zXADB8DeYCc8 for ; Wed, 14 Aug 2013 05:45: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 2BB7A11E8152 for ; Wed, 14 Aug 2013 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126; q=dns/txt; s=iport; t=1376484303; x=1377693903; h=date:from:message-id:to:subject:cc; bh=UCfF1h++9uWmSa12/79Bnex+iWHFvh5W1XjHRvEm0pY=; b=bOpCMRp9oFf0jf/fGu06a+9ZHrqgwYgTcIbM2Axm1yCxiQHutfSq+IRo Hm9F0U8ZTLAFd8Oba88bD8Rg4rwFymXLMfmdH/T9M1sQGOnpFPXnzG7cs X4NWLMCOyE3GYtZiAV/8WVep+gwpHKWGlP4fqmv6c9BPzUmEv/v/dagAr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEPAGF7C1KrRDoJ/2dsb2JhbABbgwY1gyKoRIFaAZFtBAMBgSIWdIMkPC0HiHANuHaQUB2DfAOJLY9kkCWDOw X-IronPort-AV: E=Sophos;i="4.89,876,1367971200"; d="scan'208";a="89086532" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 14 Aug 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7ECj13w032643; Wed, 14 Aug 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7ECj1S09420; Wed, 14 Aug 2013 05:45:01 -0700 (PDT) Date: Wed, 14 Aug 2013 05:45:01 -0700 (PDT) From: Message-Id: <201308141245.r7ECj1S09420@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-dc-ipv6@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-dc-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: Wed, 14 Aug 2013 12:45:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-dc-ipv6. Please take a look at it and comment. From aservin@lacnic.net Wed Aug 14 09:15: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 2B90D21E808C for ; Wed, 14 Aug 2013 09:15: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 IOdvTiVy13pj for ; Wed, 14 Aug 2013 09:15:54 -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 17D9321F9B12 for ; Wed, 14 Aug 2013 09:15:47 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:fc91:b334:be1e:5ce9]) by mail.lacnic.net.uy (Postfix) with ESMTP id 8BDCA308432 for ; Wed, 14 Aug 2013 13:15:21 -0300 (UYT) Message-ID: <520BAD34.1080903@lacnic.net> Date: Wed, 14 Aug 2013 13:15:48 -0300 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <520AD94F.1050604@nic.br> <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com> <520B029C.3010308@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439B6F9C3@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439B6F9C3@PRVPEXVS15.corp.twcable.com> X-Enigmail-Version: 1.5.2 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] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:15:55 -0000 >>>> Yes, we could use a >>>> /32 from ULA space, instead of from GLA space. But we think it would >>>> generate confusion. >>>> >>>> I think we are not really talking about impossibilities, but about >>>> options. We are talking about to write documents easier to read, labs >>>> easier to understand. >>>> >>>> In some situations, for teaching, or writing scripts for labs, >> howtos, >>> >>>> books, brochures, etc, it's better, simpler, easier, more precise, >> more >>>> clear, to use a prefix shorter than /32. In some situations we are >> doing >>>> that, and we have seen other groups doing the same. >>>> > [WEG] I think over the course of this discussion, you've built a reasonable case for this with real-world examples to back up your assertions. However, just as teachers like you to show your work when solving a math problem, I strongly suggest that you revise the draft to include this supporting information in order to build the case, else you'll have this conversation every time someone reads the draft and is skeptical that more space is needed. I realize that 3849 is light on justification and you patterned this draft after that document, but few would argue that at least one prefix for documentation is necessary and appropriate. As you've seen, fewer are convinced that additional prefixes or larger prefixes are needed without some background information from those with experience in training and documentation that have observed some real-world problems with the current solution. I can't guarantee that you won't have more "you're doing it wrong" arguments, but at least yo u' > re demonstrating that it's not an arbitrary request. > > Wes George > Thank Wes, very valuable input. Regards, as From owen@delong.com Wed Aug 14 13:20:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62521F967C for ; Wed, 14 Aug 2013 13:20:43 -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 idFUTtxMwLha for ; Wed, 14 Aug 2013 13:20: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 9045821F9CDF for ; Wed, 14 Aug 2013 13:20:40 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7EKHgdp016128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Aug 2013 13:17:43 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7EKHgdp016128 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376511464; bh=9/qeqqPvaKZbauxCe3qHuCiQCNA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Yjjwf/qB/7HLhGrrwY7QT8I1khc+kBmv93KqNXY/KM9+dirPaYmVnr4LFP4U8b/bV 9hF2LXeaNqzeyr3b7Wu/YX92xSX5M+eSSnV8E0WxHMmTKp8vbyvONw3a3NuTDhUlKG ZGMNLFfH1+QVmiicHALXbYY7z2icxPbeCXYF6vTU= 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: <1376435086.63006.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Wed, 14 Aug 2013 13:17:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> <1376435086.63006.YahooMailNeo@web142506.mail.bf1.yahoo.com> To: Mark ZZZ Smith 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]); Wed, 14 Aug 2013 13:17:44 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 20:20:43 -0000 >>>=20 >>> [WEG] at the risk of debating bikeshed colors, I would suggest = perhaps=20 >> using :db8:: for both the proposed GUA and ULA doc prefixes so that = it serves as=20 >> a visual cue. >>=20 >> I have no problem with that. >>=20 >> How about 02db:8000::/20 and fc00:0db8::/32? >> =20 >=20 > As fc00:0db8::/32 is from within the existing but albeit unused = portion of ULA prefix, any future use of fc00::/8 will need to = specifically exclude it. I think exceptions to the normal case are = better to avoid because they're another thing to remember, program as an = exception case and therefore a prone to errors etc. By definition, a documentation prefix is going to be an exception. > I think it would be better to specify a documentation ULA prefix that = has the nearly the properties as conventional ULAs, but doesn't fall = within fc00::/7 (perhaps fe::/7 or something within it?). The only = differences would be statements about no forwarding, no accepting routes = etc. That's an awful lot of space to devote to documentation. Personally, I = thought a /32 was excessive for ULA. A 7 is ridiculous, IMHO. > Ultimately though, I think it is fundamentally impossible to prevent = something silly like using documentation prefixes on a production = network, unless you use actually invalid IPv6 prefixes. The only way I = can think of to do that would be by doing things such as adding invalid = hexadecimal 'g-z' numbers into the example prefixes. I'm not sure I like = the idea, although it might cause people who get tripped up on it to go = back and think some more about what they're doing and put more effort = into getting it right. It is impossible to prevent. This aims to: 1. Make it less likely. 2. Make it easier to identify 3. Cause earlier identification (and thus easier = rectification) when it does occur. The doc prefix, in order to achieve full value, needs to be = implementable in some training lab scenarios. As such, g-z would be a = non-starter. Owen From owen@delong.com Wed Aug 14 13:26: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 84E4E21F9B26 for ; Wed, 14 Aug 2013 13:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_BACKHAIR_23=1, J_BACKHAIR_32=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 jPj3yScrSyU0 for ; Wed, 14 Aug 2013 13:26:48 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1221F9A14 for ; Wed, 14 Aug 2013 13:26:47 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7EKO8nG016251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Aug 2013 13:24:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7EKO8nG016251 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376511848; bh=8g1Bb1zhm9kzO/SWcyl9Xq4Skq0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hOoEOPYc2f6kn0aRx8yfAcaNuThpU2H222kMAqOo4te4kaAcmSiOCcrNNZ0CAPsd8 rUB1iAFsB+2OoX4ey0EAGYm+Jhx5torChl2POQLOR+N0jd7hlNthHxPhN45olj0+SI ES84mX4D5EXv724e7wo+B61+PXACi3RJ4hnqhYps= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <20130814011433.7A75C3851DE2@drugs.dv.isc.org> Date: Wed, 14 Aug 2013 13:24:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9F1F1D79-8AEE-440A-BFDF-2F08CC6FB100@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> <20130813025336.918353846F7A@drugs.dv.isc.org> <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com> <20130813070157.6D9D5384B2C5@drugs.dv.isc.org> <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com> <20130814011433.7A75C3851DE2@drugs.dv.isc.org> To: Mark Andrews 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]); Wed, 14 Aug 2013 13:24:08 -0700 (PDT) Cc: Alejandro Acosta , v6ops@ietf.org Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 20:26:49 -0000 On Aug 13, 2013, at 18:14 , Mark Andrews wrote: >=20 > In message <4B2E191C-B8BE-4B71-91D9-CD0995296F32@delong.com>, Owen = DeLong write > s: >>>=20 >>> With ULA you end up with: >>>=20 >>> site1: P1, P2 announce P2 to site2 >>> site2: P1, P3 announce P3 to site1 >>>=20 >>> When you have two sites colliding on P1. (P1, P2 and P3 are = different >>> ULA prefixes). >>=20 >> No, with ULA, the average IT group is going to start with: >>=20 >> site 1: P1 >> site 2: P1 >>=20 >> They're going to not want to roll out a whole new addressing plan to = both >> sites, so, instead, they will do what they did in IPv4. >>=20 >> P1<->NAT<->P2<->NAT<->P1 >>=20 >> You need to come down out of whatever ivory tower you live in and = look >> at how things happen in the real world. >=20 > Really how is what I am saying different to moving providers with > PA addresses? We expect renumbering event to occur then. We expect > ipv6 vendors to support this sort of renumbering. Large enterprises will likely implement IPv6 either with PI space or = with NPTv6. So in that regard, it's not different and the consequences = are also similar. As a result, I make sure that as many of my consulting clients as = possible (all that qualify under RIR policy) are aware of these things. = So far, I have nearly 100% opt-in on going with BGP and PI rather than = facing the potential to renumber in the future. > You bring up the new prefix along side the old prefix. You > decommission the old prefix. The only difference is delaying > decommissioning the old prefix longer if not forever. You say this as if that will actually happen at scale. In reality, what will happen at scale if these scenarios start occurring = is that people will fall back to what they know. It's much easier to = deploy a couple of extra NAT boxes than it is to renumber an entire = enterprise. You know how vitriolic my opinion of NAT is, so the fact = that I'm conceding that NAT is what will happen here should be a bit of = a wakeup call for you. >>> You have IP stacks that are designed to deal with multiple prefixes >>> and to choose particular source addresses for particular destination >>> addresses. >>>=20 >>> You have applications that are designed to deal with multiple >>> addresses. >>>=20 >>> IPv4 only stacks don't have all of these features which forces one >>> to use NAT. >>=20 >> None of that overcomes the realities if modern corporate IT staffing. >>=20 >>> With IPv6 they are there so you can depend on them and take = advantage >>> of them. If P2 and P3 differ only in the 48th bit longest match >>> will select the right source address. >>=20 >> If you know about them. >> If you're willing to put in the effort to use them. >> If you completely understand them. >> IF and only IF all of your applications are actually that savvy. >> etc. >=20 > If you are using ULA along side GUA then yes the applications and > stacks will do the right thing already which is almost certainly > what you will be doing if you are using ULA in the first place. Except when they don't... Which in my experience has turned out to not = be an insignificant fraction of time. I notice you addressed only one of the 4 conditions above. Owen From owen@delong.com Wed Aug 14 13: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 8F8AD11E81A7 for ; Wed, 14 Aug 2013 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHe3b2pggxoy for ; Wed, 14 Aug 2013 13:33:16 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB511E81A6 for ; Wed, 14 Aug 2013 13:33:16 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7EKSeg5016410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Aug 2013 13:28:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7EKSeg5016410 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376512121; bh=5I9kdwIMWlU7FYqZDgzwMiefY7c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jzg3MPA3yGh0Yx3fSgG2lE00na9VYWg3KmNNyn8GNo8lBZL6nzC+yqep7HCTY7RUK jXZF1nzBiOyFMOXx5oYxUgJz5COAeKb9+SFQFAnq2KsbR75a3+5Hd/BB2ccegCHct1 4U1PdWFhE65L3IUjXCVmZYenp8PwbOEy719K2wOc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439B6F9C3@PRVPEXVS15.corp.twcable.com> Date: Wed, 14 Aug 2013 13:28:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <520AD94F.1050604@nic.br> <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com> <520B029C.3010308@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439B6F9C3@PRVPEXVS15.corp.twcable.com> To: "George, Wes" 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]); Wed, 14 Aug 2013 13:28:41 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 20:33:17 -0000 On Aug 14, 2013, at 05:40 , "George, Wes" = wrote: >=20 >> From: Antonio M. Moreiras [mailto:moreiras@nic.br] >>=20 >> On 13/08/13 22:54, Mark ZZZ Smith wrote: >>> ----- Original Message ----- >>>> For one of our trainings at NIC.br, [snip] >>>=20 >>> ISPs don't just get a /32, they can get larger if they need it. >> Placing too much value on using a /32 in your examples can strongly >> imply that all IPv6 addressing plans must fit within a /32. >>=20 >> We are the NIR in our country, we are aware of that. But the vast >> majority of our allocations are indeed /32. The BCOP are also aware = of >> that, and if we want a experiment where we can follow strictly its >> recommendations, then we need a /32 or something shorter. >>=20 >>> The trouble is that if you are too prescriptive, it then creates >> opportunities for people to be lazy in their learning. They rote = learn >> rather than understand, and that means they may not be able to cope = with >> the situation is even the slightest bit different. >>>=20 >>> I think teaching people to subnet using a range of bits should be >> taught first, so that they can work with a range allocations. Whether = it >> is a /32, a /48 or a /29 then doesn't matter. Then give examples of = how >> to apply those techniques to various sized IPv6 prefixes to = re-enforce >> the methods. >>=20 > [WEG] +1. I think there's a fine line between trying to avoid = confusion and making it too easy to verbatim copy something without = understanding it. >=20 I completely agree and I'm pretty sure that Antonio would agree as well. >>>> In some situations, for teaching, or writing scripts for labs, >> howtos, >>>=20 >>>> books, brochures, etc, it's better, simpler, easier, more precise, >> more >>>> clear, to use a prefix shorter than /32. In some situations we are >> doing >>>> that, and we have seen other groups doing the same. >>>>=20 > [WEG] I think over the course of this discussion, you've built a = reasonable case for this with real-world examples to back up your = assertions. However, just as teachers like you to show your work when = solving a math problem, I strongly suggest that you revise the draft to = include this supporting information in order to build the case, else = you'll have this conversation every time someone reads the draft and is = skeptical that more space is needed. I realize that 3849 is light on = justification and you patterned this draft after that document, but few = would argue that at least one prefix for documentation is necessary and = appropriate. As you've seen, fewer are convinced that additional = prefixes or larger prefixes are needed without some background = information from those with experience in training and documentation = that have observed some real-world problems with the current solution. I = can't guarantee that you won't have more "you're doing it wrong" = arguments, but at least you' > re demonstrating that it's not an arbitrary request. I support adding the supporting details to the draft. I think that's an = excellent suggestion. It will not only make the draft more palatable to = a wider audience, it will also help inform future instructors that may = be reading the draft about things like the need to teach VLSM as a core = principle prior to showing examples of predetermined prefix sizes. > Wes George >=20 > Anything below this line has been added by my company's mail server, I = have no control over it. > ----------------- Does this mean that I am now a Time Warner mail server? (sorry, couldn't resist) Owen From fred@cisco.com Wed Aug 14 16:06: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 743DB21E80F0 for ; Wed, 14 Aug 2013 16:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ElefBkNIuSTU for ; Wed, 14 Aug 2013 16:06:16 -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 9134811E81BF for ; Wed, 14 Aug 2013 16:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=533; q=dns/txt; s=iport; t=1376521575; x=1377731175; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DnBtwVaGr4BxHmLhbopgcU4KQ266DC7n0fuIwjCm7r8=; b=DtS6apknDeAchGejvNYI6n1qV2anXQ6yl8q+BdAvwkIkEVT+EpMq0QVs N7CKacVhMTJzS+SjRDX4y6y3hYhJZNU5O4VvaqE5LyNW6/lgdGpIs8Bfc Re5bmiLOnH/QwkrY/niPPM+CiG7uBK0o1wZwahTk5IvjbKx/53oM3YWOY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIAMDFKtJXHA/2dsb2JhbABbgwaBBb8jgSEWdIIlAQEBAzo/EAIBCCIUEDIlAgQOBQiICLkgkB0CMQeDG3cDqTaDG4Iq X-IronPort-AV: E=Sophos;i="4.89,880,1367971200"; d="scan'208";a="244464728" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 14 Aug 2013 23:06:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7EN6EGh007899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 23:06:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 18:06:14 -0500 From: "Fred Baker (fred)" To: "George, Wes" Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: AQHOmULfdJgBdM2bwEKWRDg9RDcKbg== Date: Wed, 14 Aug 2013 23:06:13 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B997A52@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 23:06:22 -0000 On Aug 13, 2013, at 12:58 PM, "George, Wes" wro= te: > [WEG] at the risk of debating bikeshed colors, I would suggest perhaps us= ing :db8:: for both the proposed GUA and ULA doc prefixes so that it serves= as a visual cue. Hmm. I actually like that color for bike sheds. Reason: if someone ever typ= es that into a configuration, he'll get a statement to the effect that he's= an idiot and needs to think harder. An alternative would be to include a n= on-hex character as in 0GB8::/16= From tomosann@gmail.com Wed Aug 14 17:36: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 68C2F21E80F2 for ; Wed, 14 Aug 2013 17:36:59 -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 HQwlS-sn35Or for ; Wed, 14 Aug 2013 17:36:58 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6562E21E80F1 for ; Wed, 14 Aug 2013 17:36:58 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f14so2622555wiw.3 for ; Wed, 14 Aug 2013 17:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ly6dI5BJNMN72wC3wGJUkmjuifXYZZQPLvT8bjYrWuk=; b=rPoEB2o/3xtP108ZQEZAES1QQHW/yEOjcxbtqO06VDPKxdE8WX5kPya/Ia9W1DZIyT upwpW8tp2o4hxjLWkm3qG8NksyZ6eH5AxmtHa27ZU2WkRyBrM9m0/o6OMJVRfOQIM4zu j9MK8PNDTyzLZuVZKXreZLhhF2Dq4RLAvR2QGmtGTc9cWzSN9zOraGY6X4mVfXLj1ta+ pSQBxpbwNZoW/EdYnn868dLpcFj1cjHiXCVJhdbyms3YS+ybYW3KJ7XsVRg7Vus/QN57 XgYCXX5B5POmc686WPu3j08FNRUQfH1AzcvqnptveZD6O7pt7I+lDbWfOnSdOLEX1jOS mocw== MIME-Version: 1.0 X-Received: by 10.194.109.68 with SMTP id hq4mr8352779wjb.12.1376527017380; Wed, 14 Aug 2013 17:36:57 -0700 (PDT) Sender: tomosann@gmail.com Received: by 10.194.19.42 with HTTP; Wed, 14 Aug 2013 17:36:57 -0700 (PDT) In-Reply-To: References: <9c7c6df802614956a26a282513b9cdd4@BL2PR05MB068.namprd05.prod.outlook.com> Date: Thu, 15 Aug 2013 09:36:57 +0900 X-Google-Sender-Auth: GLd9KgIw2T0ciRlQAaKTwTcupIw Message-ID: From: Tomoyuki Sahara To: Ole Troan Content-Type: multipart/alternative; boundary=089e0102e6dae5117704e3f1abdf Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 4291, link local address defination X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Aug 2013 00:36:59 -0000 --089e0102e6dae5117704e3f1abdf Content-Type: text/plain; charset=ISO-8859-1 NetBSD, a KAME-derived implementation, rejects incoming packets if one of the source/destination addresses is in fe80:XXXX::/32 where XXXX != 0, and we cannot send such packets in normal way on NetBSD. Thanks, Tomoyuki On Wed, Aug 14, 2013 at 8:52 PM, Ole Troan wrote: > Praveen, > > > Yeah that's is the problem here, RFC 4291 says it must be followed by 54 > bits of 0. > > So many implementations which may put this constraint and in such case > fe80:4888:208:ff8b:aa:21:0:2 may get discarded. > > Should not we have one fix definition :). > > probably. the formation of the link-local address is link-specific. which > link-layer do you see this problem? > or is this manual configuration? I remember BSD used to put interface > index in those bits, but I can't remember if they masked out those bits > before putting packets on the wire. > > cheers, > Ole > > > > > > Thanks & Regards > > Praveen > > Juniper Networks > > > > > > -----Original Message----- > > From: Ole Troan [mailto:otroan@employees.org] > > Sent: Wednesday, August 14, 2013 5:01 PM > > To: Praveen Chaudhary > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] RFC 4291, link local address defination > > > > Praveen, > > > >> As per RFC 4291 section 2.5.6 link local address are defines with the > prefix fe80::/64, but many definition says even fe80::/10 qualifies as link > local address. > >> Like on wiki: > >> "In the Internet Protocol Version 6 (IPv6), the address block fe80::/10 > has been reserved for link-local unicast addressing.[2] The actual link > local addresses are assigned with the prefix fe80::/64.[6][note 2] They may > be assigned by automatic (stateless) or stateful e.g. manual) mechanisms." > >> > >> So if we have an address as below, which does not match prefix > condition, how an implementation should treat them. > >> fe80:4888:208:ff8b:aa:21:0:2 > >> > >> process as global address surely not ??, but as link local , it does > not qualify. Kindly suggest. > > > > FE80::/10 are reserved for link-local addresses, so they should be > treated as link-locals in your implementation. > > > > RFC4291 does not say that link-local addresses must be assigned from > FE80::/64. it states that the prefix must be followed by 54 bits of 0. I > agree that RFC4291 is a little ambiguous, and that the link-local address > format should be defined like the global unicast address in section 2.5.4. > > > > cheers, > > Ole > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e0102e6dae5117704e3f1abdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
NetBSD, a KAME-derived implementation, rejects incomi= ng packets=A0if one of
the source/destination addresses is in fe8= 0:XXXX::/32 where=A0XXXX !=3D 0,=A0and
we cannot send such packet= s in normal way on NetBSD.


Thanks,
Tomoyuki


On Wed, Aug 14, 2013 = at 8:52 PM, Ole Troan <otroan@employees.org> wrote:
Praveen,

> Yeah that's is the problem here, RFC 4291 says it must be followed= by 54 bits of 0.
> So many implementations which may put this constraint and in such case= fe80:4888:208:ff8b:aa:21:0:2 may get discarded.
> Should not we have one fix definition :).

probably. the formation of the link-local address is link-specific. w= hich link-layer do you see this problem?
or is this manual configuration? I remember BSD used to put interface index= in those bits, but I can't remember if they masked out those bits befo= re putting packets on the wire.

cheers,
Ole


>
> Thanks & Regards
> Praveen
> Juniper Networks
>
>
> -----Original Message-----
> From: Ole Troan [mailto:otroan= @employees.org]
> Sent: Wednesday, August 14, 2013 5:01 PM
> To: Praveen Chaudhary
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] RFC 4291, link local address defination
>
> Praveen,
>
>> As per RFC 4291 section 2.5.6 link local address are defines with = the prefix fe80::/64, but many definition says even fe80::/10 qualifies as = link local address.
>> Like on wiki:
>> "In the Internet Protocol Version 6 (IPv6), the address block= fe80::/10 has been reserved for link-local unicast addressing.[2] The actu= al link local addresses are assigned with the prefix fe80::/64.[6][note 2] = They may be assigned by automatic (stateless) or stateful e.g. manual) mech= anisms."
>>
>> So if we have an address as below, which does not match prefix con= dition, how an implementation should treat them.
>> fe80:4888:208:ff8b:aa:21:0:2
>>
>> process as global address surely not ??, but as link local , it do= es not qualify. Kindly suggest.
>
> FE80::/10 are reserved for link-local addresses, so they should be tre= ated as link-locals in your implementation.
>
> RFC4291 does not say that link-local addresses must be assigned from F= E80::/64. it states that the prefix must be followed by 54 bits of 0. I agr= ee that RFC4291 is a little ambiguous, and that the link-local address form= at should be defined like the global unicast address in section 2.5.4.
>
> cheers,
> Ole
>

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

--089e0102e6dae5117704e3f1abdf-- From owen@delong.com Wed Aug 14 17:37: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 50D8421E80FA for ; Wed, 14 Aug 2013 17:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVcnifoFlWee for ; Wed, 14 Aug 2013 17:37:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 38FE921E80F9 for ; Wed, 14 Aug 2013 17:37:18 -0700 (PDT) Received: from [192.168.32.177] (adsl-69-228-94-30.dsl.pltn13.pacbell.net [69.228.94.30]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7F0YiAP022694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Aug 2013 17:35:20 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7F0YiAP022694 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376526922; bh=JWWI0/0+BieVZSizieU+vtB6eOk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=50hY8p1410khlahajVAAu4Ax3JdrYk3BqqpwxiINIzwViT5kwycAdHL0mFHD5fZ/a bCwed0kehD/D9gNNIXXS54AP6XOEQsDXKcyfkSbPQ6uHRG8EaRCG60RFV7M5tR48jT jQydP5s2tclbf4Nz9dF80ipbHUfC/IkYfhMEvkAA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <8C48B86A895913448548E6D15DA7553B997A52@xmb-rcd-x09.cisco.com> Date: Wed, 14 Aug 2013 17:34:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <8C48B86A895913448548E6D15DA7553B997A52@xmb-rcd-x09.cisco.com> To: Fred Baker (fred) 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]); Wed, 14 Aug 2013 17:35:22 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 00:37:25 -0000 On Aug 14, 2013, at 4:06 PM, Fred Baker (fred) wrote: >=20 > On Aug 13, 2013, at 12:58 PM, "George, Wes" = wrote: >=20 >> [WEG] at the risk of debating bikeshed colors, I would suggest = perhaps using :db8:: for both the proposed GUA and ULA doc prefixes so = that it serves as a visual cue. >=20 > Hmm. I actually like that color for bike sheds. Reason: if someone = ever types that into a configuration, he'll get a statement to the = effect that he's an idiot and needs to think harder. An alternative = would be to include a non-hex character as in 0GB8::/16 I don't mind the "error message" idea (so long as it can be bypassed for = classroom situations, e.g. "no ipv6 doc-prefix-error"). The 0gb8 is problematic for the reasons I outlined earlier. Owen From internet-drafts@ietf.org Wed Aug 14 18:20: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 919F721E80FC; Wed, 14 Aug 2013 18:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, 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 g6Q0WZAc6gA4; Wed, 14 Aug 2013 18:20:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E75021E805A; Wed, 14 Aug 2013 18:20:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815012013.17734.45000.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 18:20:13 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-monitor-ds-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 01:20:14 -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 : Monitoring Dual Stack/IPv6-only Networks and Services Author(s) : Arturo Servin Mariela Rocha Filename : draft-ietf-v6ops-monitor-ds-ipv6-00.txt Pages : 10 Date : 2013-08-14 Abstract: This document describes a set of recommendations and guidelines to help operators to monitor dual stack and IPv6-only networks. The document describes how to monitor these networks using SNMP, Flow Analyzers and other means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-monitor-ds-ipv6-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From markzzzsmith@yahoo.com.au Thu Aug 15 00:33: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 00AB021E8118 for ; Thu, 15 Aug 2013 00:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.448, 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 DZ01XeyT0WjD for ; Thu, 15 Aug 2013 00:33:52 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7F621E8116 for ; Thu, 15 Aug 2013 00:33:52 -0700 (PDT) Received: from [98.139.215.140] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2013 07:33:51 -0000 Received: from [98.139.212.197] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2013 07:33:51 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 15 Aug 2013 07:33:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 52093.64531.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 18466 invoked by uid 60001); 15 Aug 2013 07:33:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1376552030; bh=GOXfdpBR/7d2i9zadP5s/gNYIUnTzara57tnY9vgJhE=; 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=xi6Ld76Jk5NXAszFo/18xAKvRUdBYgki+2HBe57+qWSodqwIAj97Ska4Vegk7d8Ysg4Zf9W+OcyQPBUj35KT0/EAflO7Hj2hIEV7wqLh0F0FN7Qe6fL1IWkEMapeGXPB5Ntp1oBpaCayhIQ3Gb15WNwmA93UfpSOnAMMrUznzRY= 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=T4WtnO7lgjiE0XvP0X7q0C0eCjy0CPbR+syxzJjxfXxFwrU2XsqqzbZelWq2pSvBhNgQoJaRDn7KjsurCWnEVTWmwNWJU+f47Mxhw+Ei1DjDe7158aOyk8HeKO+Z/f7SNocjpnMtIe8KkIWmwZ2oKj+YVjvUUlilPZRzaYx53N4=; X-YMail-OSG: MSfQoPgVM1lqWqU1okv133g7HK3AukkE.1G8i1_dcrdzj5C bMy0KC8dlVNGExHek6xHAiLJlktDAXFkHOEvG2r81gSNPOHLYltsnlgFDblS jqMDPvBY0Y_4vV2Tc8zhcSYHIc_NumhgKZywPHAyDBsPBycovih2UoGtO7vz 1eLSYbPjNuKs428qqxzK.JLNoGjaSsyO_0HnEfC7oCp9TZuGh0B6Q9uj1RlO BmEm9lvfMFynozhN2nLI6Bp0ebmEfW4EB_KvNYdi7OJkG49SWm40o6xFiHMx LItCmkrxYPxGNER8ihbOFeiUjLGthm31OgW2MzXZP5Y47SZMQ7YUFwHmsjYv C7sYl02kgZ5kcisq.Sx5uHBQZL3GR7X2mBawMbHyw4eJ7jjavy5PqCC_vWcp rNkTae6k7qW7raiWSQbVb8bx.ntnbuDekDc.2twvWus.mQcRQTTF.O5ZfT7u DJKRdxvjmZmnZU3M8Wqsym54FD93v0x0xIxdw_IawV2TyEoaSJP9r2wx.KYt liAaIHAgee1TknjcszLrAdy2xWiE1yLIF0ZQ35NBJAlz1eH_NLCok22k3G46 uswwXMZvKVfaLWDI4Y5E7.FwTbd3m7H6oGo0- Received: from [118.208.74.180] by web142501.mail.bf1.yahoo.com via HTTP; Thu, 15 Aug 2013 00:33:50 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBDYzogIkdlb3JnZSwgV2VzIiA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFRodXJzZGF5LCAxNSBBdWd1c3QgMjAxMyA2OjE3IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtbW9yZWlyYXMtdjZvcHMtcmYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> <1376435086.63006.YahooMailNeo@web142506.mail.bf1.yahoo.com> Message-ID: <1376552030.18421.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 15 Aug 2013 00:33:50 -0700 (PDT) From: Mark ZZZ Smith To: Owen DeLong 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] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 07:33:58 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: Mark ZZZ Smith =0A> Cc: "George, W= es" ; "v6ops@ietf.org" =0A> Sent= : Thursday, 15 August 2013 6:17 AM=0A> Subject: Re: [v6ops] draft-moreiras-= v6ops-rfc3849bis-00=0A> =0A>>>> =0A>>>> [WEG] at the risk of debating bike= shed colors, I would suggest =0A> perhaps =0A>>> using :db8:: for both the= proposed GUA and ULA doc prefixes so that it =0A> serves as =0A>>> a visu= al cue.=0A>>> =0A>>> I have no problem with that.=0A>>> =0A>>> How about = 02db:8000::/20 and fc00:0db8::/32?=0A>>> =A0 =0A>> =0A>> As fc00:0db8::/32= is from within the existing but albeit unused portion of =0A> ULA prefix, = any future use of fc00::/8 will need to specifically exclude it. I =0A> thi= nk exceptions to the normal case are better to avoid because they're =0A> a= nother thing to remember, program as an exception case and therefore a pron= e to =0A> errors etc.=0A> =0A> By definition, a documentation prefix is goi= ng to be an exception.=0A>=A0=0A=0AYes, but there has to be code to except = it when it is being generated, recorded, precluded from ACLs etc. If=A0fc00= :0db8::/32 was used, then a potential future registry would have to exclude= that range of prefixes, and assuming the operational rules are applied, th= en there would be mixed cases where parts of fc00::/8 are permitted/accepte= d/forwarded and then fc00:0db8::/32 has to either explicitly or implicitly = denied/filtered/blocked. I think it is better to make the network's handlin= g of all prefixes within fc00::/8 consistent, with no exceptions.=0A=0A>> = I think it would be better to specify a documentation ULA prefix that has = =0A> the nearly the properties as conventional ULAs, but doesn't fall withi= n =0A> fc00::/7 (perhaps fe::/7 or something within it?). The only differen= ces would be =0A> statements about no forwarding, no accepting routes etc.= =0A> =0A> That's an awful lot of space to devote to documentation. Personal= ly, I =0A> thought a /32 was excessive for ULA. A 7 is ridiculous, IMHO.=0A= >=A0=0A=0AI agree the /7 is large and excessive, and I'm not really advocat= ing for it. I suggested fe::/7 only to make a documentation ULA look simila= r to and adjacent to the existing non-documentation ULA space, rather than = falling within the existing ULA space. Choosing to use a /7 for a documenta= tion ULA would obviously need a lot of thought and justification, and I wou= ldn't think it'd be likely to be accepted.=A0=0A=0A>> Ultimately though, I= think it is fundamentally impossible to prevent =0A> something silly like = using documentation prefixes on a production network, =0A> unless you use a= ctually invalid IPv6 prefixes. The only way I can think of to do =0A> that = would be by doing things such as adding invalid hexadecimal 'g-z' =0A> numb= ers into the example prefixes. I'm not sure I like the idea, although it = =0A> might cause people who get tripped up on it to go back and think some = more about =0A> what they're doing and put more effort into getting it righ= t.=0A> =0A> It is impossible to prevent. This aims to:=0A> =0A> =A0=A0=A0 1= .=A0=A0=A0 Make it less likely.=0A> =A0=A0=A0 2.=A0=A0=A0 Make it easier to= identify=0A=0AThis is the key reason I think outside of fc00::/7 would be = better.=0A=0A> =A0=A0=A0 3.=A0=A0=A0 Cause earlier identification (and thus= easier rectification) when it =0A> does occur.=0A> =0A> The doc prefix, in= order to achieve full value, needs to be implementable in =0A> some traini= ng lab scenarios.=0A=0AIf it is a documentation prefix then I think it shou= ld never be implemented in training labs, otherwise it is now more than jus= t a documentation prefix. For a lab, standard ULA prefixes should do fine, = and the exercise of students generating and deploying a conventional ULA pr= efix for their own network would be a good one to teach them how ULAs are t= o be properly generated and used.=0A=0A> As such, g-z would be a non-starte= r.=0A=0A>=A0=0A=0AI do agree it's not the greatest idea, but it would ensur= e the prefix can only be used in documentation and nothing else, and would = facilitate training people on paper in how to subnet ULA-like space. After = they've had that training they could then use real ULAs to implement a subn= etting plan in their lab scenarios.=0A=0ARegards,=0AMark. From moreiras@nic.br Thu Aug 15 05:07: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 1136511E8119 for ; Thu, 15 Aug 2013 05:07: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 9ZHZlOyM3rZq for ; Thu, 15 Aug 2013 05:07:23 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA511E80F8 for ; Thu, 15 Aug 2013 05:07:21 -0700 (PDT) Received: from moreiras.in.nic.br (5.96.net.registro.br [200.160.5.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 2BE2520800FD for ; Thu, 15 Aug 2013 09:07:16 -0300 (BRT) Message-ID: <520CC474.3050004@nic.br> Date: Thu, 15 Aug 2013 09:07:16 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> <1376435086.63006.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1376552030.18421.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1376552030.18421.YahooMailNeo@web142501.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 12:07:29 -0000 On 15/08/13 04:33, Mark ZZZ Smith wrote: > ----- Original Message ----- >> > From: Owen DeLong >> > To: Mark ZZZ Smith >> > Cc: "George, Wes" ; "v6ops@ietf.org" >> > Sent: Thursday, 15 August 2013 6:17 AM >> > Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 >> > >>>>> >>>> >>>>> >>>> [WEG] at the risk of debating bikeshed colors, I would suggest >> > perhaps >>>> >>> using :db8:: for both the proposed GUA and ULA doc prefixes so that it >> > serves as >>>> >>> a visual cue. >>>> >>> >>>> >>> I have no problem with that. >>>> >>> >>>> >>> How about 02db:8000::/20 and fc00:0db8::/32? >>>> >>> >>> >> >>> >> As fc00:0db8::/32 is from within the existing but albeit unused portion of >> > ULA prefix, any future use of fc00::/8 will need to specifically exclude it. I >> > think exceptions to the normal case are better to avoid because they're >> > another thing to remember, program as an exception case and therefore a prone to >> > errors etc. >> > >> > By definition, a documentation prefix is going to be an exception. >> > > Yes, but there has to be code to except it when it is being generated, recorded, precluded from ACLs etc. If fc00:0db8::/32 was used, then a potential future registry would have to exclude that range of prefixes, and assuming the operational rules are applied, then there would be mixed cases where parts of fc00::/8 are permitted/accepted/forwarded and then fc00:0db8::/32 has to either explicitly or implicitly denied/filtered/blocked. I think it is better to make the network's handling of all prefixes within fc00::/8 consistent, with no exceptions. > I am not following closely the discussions on ULA-C. I think this matter isn't discussed since 2007, or 2008, is it? But let's suppose that someone revives the subject, and we come to create such a central registry for ULA-C space. Based on previous discussions, I think it is safe to assume that it would just allocate /48 prefixes from fc00::/8, probably choosing them randomically. In this context, what could happen if we reserve some prefixes for documentation, now? They would just be marked as already in use, by such central registry. What else could happen? The networks could treat the ULA documentation prefixes the same way they treat any other ULA prefix that are not their own. As ULA, in general, is already being filtered at network borders, maybe we really wouldn't need special rules, or exceptions, as we need with 2001:0db8::/32. The main advantage of an ULA documentation prefix, such as fc00:0db8::/32 would be the "visual clue", then. If someone a bit experienced sees something like fc00:db8:a:coffe::1 in the network, it would be very clear that it was copied from some example, and should not be there. Moreiras. From fred@cisco.com Thu Aug 15 05:45: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 0E5D821E8087 for ; Thu, 15 Aug 2013 05:45:08 -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 XoCBcKHplZyq for ; Thu, 15 Aug 2013 05:45:03 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 59ADA21F9E9F for ; Thu, 15 Aug 2013 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134; q=dns/txt; s=iport; t=1376570703; x=1377780303; h=date:from:message-id:to:subject:cc; bh=0V/iS1F4Nh9OBiHc9g1kFfi4CgTkXCHNYDhPq8ggQ9M=; b=Fp1NNQZEPNoYK5vJGU38gm/xv/RPz/rHWoudc3xrwE8n3A1QptsyR9GU ffwAKbqIWyzYPoPDttRavmKQqlZxO4YPDuLaNbzYdn+4XGQhTpUJ79Pk3 Qzi9fJivJnb6sXWY0kmBulOAFD+bKtogObauPzhrRosRKkOSnXs5LT6nB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwPAG3MDFKrRDoH/2dsb2JhbABbgwY1gyKqJAGSEwQDAYEiFnSDJDwtB4hwDblgkFAdg3wDiS2PZJAlgzs X-IronPort-AV: E=Sophos;i="4.89,885,1367971200"; d="scan'208";a="86671375" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 15 Aug 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7FCj0uh001050; Thu, 15 Aug 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r7FCj0021061; Thu, 15 Aug 2013 05:45:00 -0700 (PDT) Date: Thu, 15 Aug 2013 05:45:00 -0700 (PDT) From: Message-Id: <201308151245.r7FCj0021061@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-monitor-ds-ipv6@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-monitor-ds-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, 15 Aug 2013 12:45:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-monitor-ds-ipv6. Please take a look at it and comment. From owen@delong.com Thu Aug 15 11:55:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE211E8182 for ; Thu, 15 Aug 2013 11:55:48 -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 OK-1BF4i4OVn for ; Thu, 15 Aug 2013 11:55:47 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 23F7D11E8128 for ; Thu, 15 Aug 2013 11:55:46 -0700 (PDT) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7FIrwYl019482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Aug 2013 11:53:58 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7FIrwYl019482 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376592840; bh=/2AMz59BZBLRSvipdb21ZB/Jatk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wddgJlsEEo4ByIQjIrF4sUW7ZFtv7REvjex6jt0oX5DCORNii+NcLgN62RDO+wI4u Yqga848G4YlrSWpQMrCX0kFOOZShaoPOvXuzMXM7gGZohr6+/A5q2AXrpXG0OtBBuS mIaI5AMverlM7WKFRpDHn8uNgHV9DpNf02EuxV/o= 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: <1376552030.18421.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 15 Aug 2013 11:53:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D8B12FB-E090-4910-87EE-8F11B11D6A1E@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> <1376435086.63006.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1376552030.18421.YahooMailNeo@web142501.mail.bf1.yahoo.com> To: Mark ZZZ Smith 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]); Thu, 15 Aug 2013 11:54:00 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 18:55:48 -0000 >> By definition, a documentation prefix is going to be an exception. >> =20 >=20 > Yes, but there has to be code to except it when it is being generated, = recorded, precluded from ACLs etc. If fc00:0db8::/32 was used, then a = potential future registry would have to exclude that range of prefixes, = and assuming the operational rules are applied, then there would be = mixed cases where parts of fc00::/8 are permitted/accepted/forwarded and = then fc00:0db8::/32 has to either explicitly or implicitly = denied/filtered/blocked. I think it is better to make the network's = handling of all prefixes within fc00::/8 consistent, with no exceptions. I don't see that as a significant hurdle. If (and I think that's a big = IF at this point) a registry is created, then you prime the registry = with an entry for fc00:0db8::/32 as a Doc prefix and you're done. By definition, any given network which uses space within fc00::/8 will = not be able to handle it consistently with no exceptions. They will need = to permit the ranges they are using and exclude the rest anyway. OTOH, any network not using fc00::/8 space can reject all of fc00::/8 = without exception. As such, I think you're pushing a red herring. >>> I think it would be better to specify a documentation ULA prefix = that has=20 >> the nearly the properties as conventional ULAs, but doesn't fall = within=20 >> fc00::/7 (perhaps fe::/7 or something within it?). The only = differences would be=20 >> statements about no forwarding, no accepting routes etc. >>=20 >> That's an awful lot of space to devote to documentation. Personally, = I=20 >> thought a /32 was excessive for ULA. A 7 is ridiculous, IMHO. >> =20 >=20 > I agree the /7 is large and excessive, and I'm not really advocating = for it. I suggested fe::/7 only to make a documentation ULA look similar = to and adjacent to the existing non-documentation ULA space, rather than = falling within the existing ULA space. Choosing to use a /7 for a = documentation ULA would obviously need a lot of thought and = justification, and I wouldn't think it'd be likely to be accepted.=20 I don't see it as offering any advantages over fc00:0db8::/32, either. >=20 >>> Ultimately though, I think it is fundamentally impossible to prevent=20= >> something silly like using documentation prefixes on a production = network,=20 >> unless you use actually invalid IPv6 prefixes. The only way I can = think of to do=20 >> that would be by doing things such as adding invalid hexadecimal = 'g-z'=20 >> numbers into the example prefixes. I'm not sure I like the idea, = although it=20 >> might cause people who get tripped up on it to go back and think some = more about=20 >> what they're doing and put more effort into getting it right. >>=20 >> It is impossible to prevent. This aims to: >>=20 >> 1. Make it less likely. >> 2. Make it easier to identify >=20 > This is the key reason I think outside of fc00::/7 would be better. Since 2001:0db8::/32 has proven to be perfectly viable for this purpose, = I thing that argument falls flat. >=20 >> 3. Cause earlier identification (and thus easier = rectification) when it=20 >> does occur. >>=20 >> The doc prefix, in order to achieve full value, needs to be = implementable in=20 >> some training lab scenarios. >=20 > If it is a documentation prefix then I think it should never be = implemented in training labs, otherwise it is now more than just a = documentation prefix. For a lab, standard ULA prefixes should do fine, = and the exercise of students generating and deploying a conventional ULA = prefix for their own network would be a good one to teach them how ULAs = are to be properly generated and used. We can agree to disagree on this. Admittedly, I prefer to do as you say = above, but there are other instructors that want to allow students to do = certain ab initio exercises using the exact book examples. I think both = should be supported. Owen From fred@cisco.com Fri Aug 16 14:12: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 3769921F9D8D for ; Fri, 16 Aug 2013 14:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 jy66kKPRqMdy for ; Fri, 16 Aug 2013 14:12:39 -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 1188E11E8159 for ; Fri, 16 Aug 2013 14:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=920; q=dns/txt; s=iport; t=1376687557; x=1377897157; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FqieOw6dVShgFuWlu0m/n2bi9gmkbMcIX45pLCkRZcA=; b=PaREypINJlNEwaDGtpnb0ilUTdh4QJH84OmQYnoM/pIYAyhYES4KcJF0 F/GWAQ2RiROwtwSi8+RXc4ViYViLIHU+NzVSylxe+JsmrY/lJeQxWK0Qm NG1QOsFUsscDH2hK5r5aY1xng2GjfBH/FLfHclUueauqqXrX6cGcbKHYJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucFAM6UDlKtJV2d/2dsb2JhbABbgwaBBoJTvE2BKxZ0giUBAQQ6PxACAQgiFBAyJQIEAQ0NiAi5N48CgRsCMQeDG3cDqTmDHIIq X-IronPort-AV: E=Sophos;i="4.89,897,1367971200"; d="scan'208";a="248341573" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 16 Aug 2013 21:12:36 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7GLCWWT014386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 21:12:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 16:12:31 -0500 From: "Fred Baker (fred)" To: "Antonio M. Moreiras" , Alejandro Acosta Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: AQHOmsVSl6fzlrtx9kmFZAMhzasS+Q== Date: Fri, 16 Aug 2013 21:12:31 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> In-Reply-To: <5207E319.6070601@nic.br> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] 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] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 21:12:44 -0000 Dumb question. I wonder if there is a less expensive way to go about this. By expensive, I= mean "choke. you want a /20?". It has been argued that we need something t= hat is shorter than a /32, and that we need something for ULAs. Whatever we= do, it needs to be consistent with class examples that need to get typed i= nto operational equipment. There's a lot more that has been said, but that'= s what I draw out of it. What if we shortened 2001:db8::/32 to 2001:db8::/29? I note that the prefix= doesn't show up in ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest,= and the IANA counterpart mentions it only in a footnote. We could also delegate fc00:db8::/29, or something longer (/44 perhaps, all= owing for the description of several ULA prefixes in documentation but not = chewing up as much address space), by the same logic. I see the argument, but not for the size requested.= From moreiras@nic.br Fri Aug 16 17:32: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 1146E11E8176 for ; Fri, 16 Aug 2013 17:32:29 -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 yBodghhpIAFr for ; Fri, 16 Aug 2013 17:32:28 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 240CE11E8158 for ; Fri, 16 Aug 2013 17:32:28 -0700 (PDT) Received: from moreiras.in.nic.br (unknown [IPv6:2001:12ff:0:5::96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 43A9020801B9; Fri, 16 Aug 2013 21:32:27 -0300 (BRT) Message-ID: <520EC49B.3000904@nic.br> Date: Fri, 16 Aug 2013 21:32:27 -0300 From: "Antonio M. Moreiras" Organization: NIC.br User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alejandro Acosta , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 00:32:29 -0000 On 16/08/13 18:12, Fred Baker (fred) wrote: > Dumb question. > > I wonder if there is a less expensive way to go about this. By expensive, I mean "choke. you want a /20?". It has been argued that we need something that is shorter than a /32, and that we need something for ULAs. Whatever we do, it needs to be consistent with class examples that need to get typed into operational equipment. There's a lot more that has been said, but that's what I draw out of it. > > What if we shortened 2001:db8::/32 to 2001:db8::/29? I note that the prefix doesn't show up in ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest, and the IANA counterpart mentions it only in a footnote. > > We could also delegate fc00:db8::/29, or something longer (/44 perhaps, allowing for the description of several ULA prefixes in documentation but not chewing up as much address space), by the same logic. > > I see the argument, but not for the size requested. It's a very good question. For our BGP trainings at NIC.br, as they are today, we need at least a /27 (we have 23 simulated ASs in our lab, each one using a /32). Since APNIC could shorten the 2001:db8:: only to a /29, which is not enough for our classes, we saw as a better alternative asking for a new prefix. We thought that maybe we shouldn't be so conservative, asking exactly for what we need at the moment. The /20 is the shortest prefix allocated to an ISP in our region, and it seemed to be a good choice. Moreiras. From owen@delong.com Sat Aug 17 01:00: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 93F5F21F99F4 for ; Sat, 17 Aug 2013 01:00:35 -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 Zddr3oGffRt6 for ; Sat, 17 Aug 2013 01:00:34 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 55CEC21F99DE for ; Sat, 17 Aug 2013 01:00:34 -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 r7H7tajg016389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 17 Aug 2013 00:55:36 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7H7tajg016389 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376726138; bh=m+EsfWVEFZGVG/QPgIzi7+a+gIw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=p0NKbq+LWPzxfoHLmncOIXJ6qeM1m+L0E8z17DxIKDFEC+TcgRv1KlWeIY0nAvwjn /zktIOnQMq7zdF/PAXMKSfrZ8zQbdEG2n1uUDhzqy9oUfT0lIhGdyzBblBmloeeSrK QQioBl3WLWzoxQRfOvJh1nT3T7zpRqWM3CPDtxcQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> Date: Sat, 17 Aug 2013 00:55:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <86115BE4-F2F3-4B1E-AAEE-A83D6EFB1B0C@delong.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 17 Aug 2013 00:55:38 -0700 (PDT) Cc: Alejandro Acosta , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 08:00:35 -0000 On Aug 16, 2013, at 14:12 , "Fred Baker (fred)" wrote: > Dumb question. >=20 > I wonder if there is a less expensive way to go about this. By = expensive, I mean "choke. you want a /20?". It has been argued that we = need something that is shorter than a /32, and that we need something = for ULAs. Whatever we do, it needs to be consistent with class examples = that need to get typed into operational equipment. There's a lot more = that has been said, but that's what I draw out of it. >=20 > What if we shortened 2001:db8::/32 to 2001:db8::/29? I note that the = prefix doesn't show up in = ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest, and the IANA = counterpart mentions it only in a footnote. I think at least a /28 is necessary. I'm not entirely convinced that a = /20 is needed, but I can see good argument for a /24. >=20 > We could also delegate fc00:db8::/29, or something longer (/44 = perhaps, allowing for the description of several ULA prefixes in = documentation but not chewing up as much address space), by the same = logic. I think this would be fine (even at the /44 level). > I see the argument, but not for the size requested. I'll leave it to Antonio et. al to justify a /20, but I'd like to see us = get at least a /28. Owen From mukom.tamon@gmail.com Sat Aug 17 11:38: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 DA56A11E81EA for ; Sat, 17 Aug 2013 11:38:06 -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 LvxV9c9lNLSY for ; Sat, 17 Aug 2013 11:38:06 -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 D972C11E81E3 for ; Sat, 17 Aug 2013 11:38:05 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so1120196qab.11 for ; Sat, 17 Aug 2013 11:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=kJMogBAE3Ap7TJlttGxtbN+ZjDOW6EXuF/ozAsU/DNc=; b=PBrVHE2tj41TDv+XMmmGR94akFWMvo4BzP/y4H81cxM4w6LjHMmqli5zvE6q3eNjP7 VvsD2kvpBjfU9rH0901nj9txyOcIAvSP8EF6OU6aIJdZhTVMgq7ijSRiomJFGgghsgdU gYoOvIYlVfBoSzikSQQI2d0Jjobhyktp+9jau1mEUckRXzd5LbnwFvV5Pk551o0PQsU7 mrP6LcB9qsitk/eoTNYvnoQkWEYJz5rFaIID6LVR9H/IHe2wJ6NbSO+MPw3MNw383EYp TmBAP6zSgg3EOK4vnPWQN/lIFidhQgBDv4bhgpfl2xWrrvEuEri8ZvXgSCW9UQUvFXe/ vGqQ== X-Received: by 10.224.156.197 with SMTP id y5mr2399648qaw.83.1376764684272; Sat, 17 Aug 2013 11:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.47.82 with HTTP; Sat, 17 Aug 2013 11:37:24 -0700 (PDT) In-Reply-To: <201308131245.r7DCj0k27831@ftpeng-update.cisco.com> References: <201308131245.r7DCj0k27831@ftpeng-update.cisco.com> From: "Mukom Akong T." Date: Sat, 17 Aug 2013 22:37:24 +0400 Message-ID: To: draft-ma-v6ops-ipv6-address-assignment@tools.ietf.org, v6ops@ietf.org Content-Type: multipart/alternative; boundary=089e01537592f20df904e4290165 Subject: Re: [v6ops] new draft: draft-ma-v6ops-ipv6-address-assignment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 18:38:07 -0000 --089e01537592f20df904e4290165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all, I am a total newbie to posting here so please forgive any lapses in protocol. I've got some comments In section 3 (2) it is mentioned "....MiFi should receive a /60 prefix for downstream interface, can address 2^4 hosts" I believe the author meant to say 2^4 subnets (each being of size /64). Same mistake is made for 3 (3) which should be On second thoughts, a typical MiFI (apart from the 3G or 4G wireless WAN interface) typically only has one subnet behind it. In this case I believe a single /64 (received through DHCPv6-PD) will suffice. In section 3 (4), while a broad recommendation of "one or more /48s" might serve as a default recommendation, I'd rather go with "A single /48 but it is highly recommended that proper address planning be done to estimate exactly how many /48s are required" ... or something similar. I'd rather also use the term "End site" rather than user so as to avoid confusion. 1 million users on a GGSN is not necessarily need 1 million /64s= . In 4 (4) the authors says "Each CPE need a / 64 LAN interface address and a /56 WAN interface address，". I am curious, why a /56 on a WAN interface? Regards On Tue, Aug 13, 2013 at 4:45 PM, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-ma-v6ops-ipv6-address-assignment. Please > take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --089e01537592f20df904e4290165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

I am a total newbie to= posting here so please forgive any lapses in protocol. I've got some c= omments=C2=A0

In section 3 (2) it is m= entioned =C2=A0"....MiFi should receive a /60 prefix for=C2=A0downstre= am interface, can address 2^4 hosts" I believe the author meant to say= 2^4 subnets (each being of size /64). Same mistake is made for 3 (3) which= should be=C2=A0

On second thoughts, a typical MiFI (apart f= rom the 3G or 4G wireless WAN interface) typically only has one subnet behi= nd it. In this case I believe a single /64 (received through DHCPv6-PD) wil= l suffice.

In section 3 (4), while a broad recommendat= ion of "one or more /48s" might serve as a default recommendation= , I'd rather go with "A single /48 but it is highly recommended th= at proper address planning be done to estimate exactly how many /48s are re= quired" ... or something similar.=C2=A0

I'd rather also use the term "End = site" rather than user so as to avoid confusion. 1 million users on a = GGSN is not necessarily need 1 million /64s.

In 4 (4) the authors says "Each CPE need a / 64 LAN interfa= ce address and a=C2=A0/56 WAN interface address&#65292". I am curi= ous, why a /56 on a WAN interface? =C2=A0

Regards


On Tue,= Aug 13, 2013 at 4:45 PM, <fred@cisco.com> wrote:

A new draft has been posted, at http://tools.ietf.org/= html/draft-ma-v6ops-ipv6-address-assignment. Please take a look at it a= nd comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



--

Mukom Ak= ong T.

= http://about.me/perfexcellence | =C2=A0twitter: @perfexcellent --------------------------------------------------------------------------= ----------------------------------------------------------------
=E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran
--------------------= ---------------------------------------------------------------------------= --------------------------------------------
--089e01537592f20df904e4290165-- From fred@cisco.com Sun Aug 18 11:00: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 C94E021F9950 for ; Sun, 18 Aug 2013 11:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1lCqruRmU+h for ; Sun, 18 Aug 2013 11:00:10 -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 D30FD11E814B for ; Sun, 18 Aug 2013 11:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=622; q=dns/txt; s=iport; t=1376848809; x=1378058409; h=date:from:message-id:to:subject:cc; bh=d3vhLiPD+eYys0ee9X9VEBYNb8CT3x/i9O1UfJ5E+L8=; b=H1DPpfjlT+ie8jsWfmOjtJqGZe9pom1rJJ1sFv8v2bGSQdzG4ue/Zcx3 krgJ6+NLBZQaLpUKgkibZ2dLdPCG/O9NfWvX+fGxQlsWAAPKtJ2WR+XIY JE6Fx0ZUc3oB4ybSHpe2ukffubpWqJQ3cHKbrVrHDHsA5jNXAdVzzbl4/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEJALoKEVKrRDoG/2dsb2JhbABbgwY1gySqVAGSBYEcFnSDJDw0iHANtWeQYB2DfAOJLY9kkCiDPA X-IronPort-AV: E=Sophos;i="4.89,908,1367971200"; d="scan'208";a="86163538" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 18 Aug 2013 18:00:08 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7II07XL029935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Aug 2013 18:00:07 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r7II064g003300; Sun, 18 Aug 2013 11:00:07 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r7II06mv003294; Sun, 18 Aug 2013 11:00:06 -0700 (PDT) Date: Sun, 18 Aug 2013 11:00:06 -0700 (PDT) From: Fred Baker Message-Id: <201308181800.r7II06mv003294@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 18:00:14 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From jfesler@gigo.com Sun Aug 18 20:11: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 D523121F9C4E for ; Sun, 18 Aug 2013 20:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ZQb0ZyNw6rjR for ; Sun, 18 Aug 2013 20:11:43 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7445A21F9C38 for ; Sun, 18 Aug 2013 20:11:43 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so3295973wes.16 for ; Sun, 18 Aug 2013 20:11:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9nVmj4id3YFO+rCZ8JIDIj9fZxOzGhIZgHX2jNJ1qH0=; b=WKBTvFhPFe0fN85uNbV8K5M/CbnNzlbLnlBCNQaU9PIAkZjRY1eoINxDb51rl9GBkq d6irgWLIn6IcaQWP79F/49CreaQvQBUPduai/8XC3y99AZBkMVSwCo3lob+KUQaX+C/t 2KgxYWBQkZ9906/b59rpnz47nXzt6dLGOZ3CTHYG5Y22n3bT+TMyVTfe1WW+sS1xYASh rMm4iio+41CrZuZwM098S718jcRooFNiPTyaJnFnjYRe9PFKlzY5wv9aLa0QLP+DHZDo fvUoh2idCdFTURcFe2DKTJ19uDvzV/wOtnCCqXDkLLTyP0Qtqef6UhP1vpeMOdyYkenQ 88Hg== X-Gm-Message-State: ALoCoQnzUt9kD099VMGFLJnWJbssCpadIJIpr3PuuayZVA61tRqBEVeWBhJOPIIu+7bDdFX1TT6s MIME-Version: 1.0 X-Received: by 10.180.205.163 with SMTP id lh3mr6399631wic.27.1376881902558; Sun, 18 Aug 2013 20:11:42 -0700 (PDT) Received: by 10.216.248.131 with HTTP; Sun, 18 Aug 2013 20:11:42 -0700 (PDT) In-Reply-To: <201308181800.r7II06mv003294@irp-view13.cisco.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> Date: Sun, 18 Aug 2013 20:11:42 -0700 Message-ID: From: Jason Fesler To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 03:11:48 -0000 On Sun, Aug 18, 2013 at 11:00 AM, Fred Baker wrote: > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. I do believe there is a value in this document being published. The contents very much reflect the operational reality of $employer; both on the technical issues at hand, and the related practices we now take as a result. And I believe this will be a useful document for the context of other papers relating to fragments. From jiangsheng@huawei.com Sun Aug 18 20:43: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 264AC11E81A7; Sun, 18 Aug 2013 20:43:33 -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 OJDSVHA9qm+l; Sun, 18 Aug 2013 20:43:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8E11E80D1; Sun, 18 Aug 2013 20:43:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWD36529; Mon, 19 Aug 2013 03:43:27 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 04:42:42 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 19 Aug 2013 04:43:26 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.66]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Mon, 19 Aug 2013 11:43:19 +0800 From: Sheng Jiang To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-taylor-v6ops-fragdrop WGLC Thread-Index: AQHOnDzVcyHroPwXkkimHplb/XQgn5mb4oOA Date: Mon, 19 Aug 2013 03:43:18 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACF4BEA@nkgeml512-mbx.china.huawei.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> In-Reply-To: <201308181800.r7II06mv003294@irp-view13.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 03:43:33 -0000 UmVhZGluZyB0aGlzIGRvY3VtZW50IG1hZGUgbWUgYmVsaWV2ZSB0aGF0IGZyYWdtZW50IHNob3Vs ZCBOT1QgYmUgZGVwcmVjYXRlZCBhbmQgdGhlIHN1cHBvcnQgZm9yIGZyYWdtZW50IHdvdWxkIGJl IGJldHRlciBpbiBsb25nLXRlcm0uIEkgcGVyc29uYWxseSBhZ3JlZSBvbiBzdWNoIG9ic2VydmF0 aW9ucyBhbmQgY29uY2x1c2lvbnMuIEkgc3VwcG9ydCB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gVGhhbmtzIGF1dGhvcnMgZm9yIGdhdGhlciB0aGVzZSB2YWx1ZSBpbmZvcm1hdGlv bi4NCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogdjZvcHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPk9mIEZyZWQgQmFrZXINCj5TZW50OiBNb25kYXksIEF1Z3VzdCAxOSwgMjAxMyAyOjAwIEFN DQo+VG86IHY2b3BzQGlldGYub3JnDQo+U3ViamVjdDogW3Y2b3BzXSBkcmFmdC10YXlsb3ItdjZv cHMtZnJhZ2Ryb3AgV0dMQw0KPg0KPlRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvZg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRheWxvci12Nm9wcy1mcmFnZHJvcC4gIFBsZWFzZSByZWFkIGl0IG5vdy4NCj5JZiB5b3UgZmlu ZCBuaXRzDQo+KHNwZWxsaW5nIGVycm9ycywgbWlub3Igc3VnZ2VzdGVkIHdvcmRpbmcgY2hhbmdl cywgZXRjKSwgY29tbWVudCB0byB0aGUNCj5hdXRob3JzOyBpZiB5b3UgZmluZCBncmVhdGVyIGlz c3Vlcywgc3VjaCBhcyBkaXNhZ3JlZWluZyB3aXRoIGENCj5zdGF0ZW1lbnQgb3IgZmluZGluZyBh ZGRpdGlvbmFsIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkLA0KPnBsZWFzZSBwb3N0 IHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuDQo+DQo+V2UgYXJlIGxvb2tpbmcgc3BlY2lmaWNh bGx5IGZvciBjb21tZW50cyBvbiB0aGUgaW1wb3J0YW5jZSBvZiB0aGUNCj5kb2N1bWVudCBhcyB3 ZWxsIGFzIGl0cyBjb250ZW50LiBJZiB5b3UgaGF2ZSByZWFkIHRoZSBkb2N1bWVudCBhbmQNCj5i ZWxpZXZlIGl0IHRvIGJlIG9mIG9wZXJhdGlvbmFsIHV0aWxpdHksIHRoYXQgaXMgYWxzbyBhbiBp bXBvcnRhbnQNCj5jb21tZW50IHRvIG1ha2UuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From ggm@algebras.org Sun Aug 18 21:27: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 836FC11E81AA for ; Sun, 18 Aug 2013 21:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.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_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 YFlI4QuDUTBz for ; Sun, 18 Aug 2013 21:27:03 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCEB11E80FE for ; Sun, 18 Aug 2013 21:27:03 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so4481376pbc.22 for ; Sun, 18 Aug 2013 21:27:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=25om7KaPl1/MzxvBX00pU+Rbdvaq4yAu9FbCCgXqBaA=; b=l3kZaT0Q6UMjWohb9bIjX1sLeU9XuZ2uyHbTDgMT+jsUeWdXvHFgl/2yPX8Nf6cffS nW74wgG+T2ULKTgl39K5dUxKf5J+auDeNzKbFpIuhw5gdJ7J1DryxIrqn1B/ziW3XR3A YInVhn2MoTiwOjKdottkP5kzjOqUyNV870GtMeCTdNLhJ/YaDCvSDwd6HVbXODaeIdk0 dBwQLHPBlaiNp8TYVyFm3HWuuhHhtue9uEFn4sonJ838IIcsNtDwOrsZ4UmlS65ZFi+F bAk3QzQkFeIhk49r5FUpNzXEsELdGJ261RLC+OLSZS4v+mtfI6dyIcCxUQUn1C11+1JH VAXA== X-Gm-Message-State: ALoCoQl0+E89754Titahmi15+/dyeCVRyKzY/mw4M27y3BrZHxNx9uDairM9NtBt0kxJ2RmbmlCV MIME-Version: 1.0 X-Received: by 10.68.225.232 with SMTP id rn8mr8217731pbc.32.1376886423138; Sun, 18 Aug 2013 21:27:03 -0700 (PDT) Received: by 10.70.19.98 with HTTP; Sun, 18 Aug 2013 21:27:03 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:f567:12a5:25e1:ccc9] In-Reply-To: <201308181800.r7II06mv003294@irp-view13.cisco.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> Date: Mon, 19 Aug 2013 14:27:03 +1000 Message-ID: From: George Michaelson To: Fred Baker Content-Type: multipart/alternative; boundary=047d7b2ee28325c5b404e4455a3e Cc: "" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 04:27:07 -0000 --047d7b2ee28325c5b404e4455a3e Content-Type: text/plain; charset=ISO-8859-1 I think this is a useful review of the issues. I think it makes operationally pertinant observations. I think it stands reasonably neutrally in the 'frag or not' debate, because both sides can inform themselves from it. I doubt its going to change many people's minds on the fundamental question. I think it helps inform the question(s) being asked. It made me think harder about the potential for changes to fragments to include upper-layer headers, and to what extent that kind of change might break things, or help with the considerations of risk and load and capability in deployed equipment. I am a little worried the document makes unattributed statements about ASIC and FPGA costs. I think they need to be fleshed out, because this kind of unsubstantiated and unattributed comment can lead to people continuing to assume things which applied once, to some vendors, but doesn't apply now (consider the whole thing about secure disk wiping which was predicated on a very specific generation of HDD hardware. Or, the "BGP is dying we need locator+id" debate, which arguably stems from a false premise) Having said that, if google employees say that they use systems on their 'edge' which do this, thats certainly attributed. -G On Mon, Aug 19, 2013 at 4:00 AM, Fred Baker wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please read it > now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b2ee28325c5b404e4455a3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think this is a useful review of the issues. I think it = makes operationally pertinant observations.

I think it s= tands reasonably neutrally in the 'frag or not' debate, because bot= h sides can inform themselves from it. I doubt its going to change many peo= ple's minds on the fundamental question.

I think it helps inform the question(s) being asked. It= made me think harder about the potential for changes to fragments to inclu= de upper-layer headers, and to what extent that kind of change might break = things, or help with the considerations of risk and load and capability in = deployed equipment.

I am a little worried the document makes unattributed s= tatements about ASIC and FPGA costs. I think they need to be fleshed out, b= ecause this kind of unsubstantiated and unattributed comment can lead to pe= ople continuing to assume things which applied once, to some vendors, but d= oesn't apply now (consider the whole thing about secure disk wiping whi= ch was predicated on a very specific generation of HDD hardware. Or, the &q= uot;BGP is dying we need locator+id" debate, which arguably stems from= a false premise)

Having said that, if google employees say that they use= systems on their 'edge' which do this, thats certainly attributed.=

-G


On Mon, Aug 19, 2013 at 4:00 AM, Fred Baker <fred@= cisco.com> wrote:
This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. =A0= Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a
statement or finding additional issues that need to be addressed,
please post your comments to the list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b2ee28325c5b404e4455a3e-- From he@uninett.no Mon Aug 19 01:47:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8B711E820C for ; Mon, 19 Aug 2013 01:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHslU7Wb7X+I for ; Mon, 19 Aug 2013 01:47:07 -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 9B3C811E8212 for ; Mon, 19 Aug 2013 01:47:06 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 0BA253D0B3 for ; Mon, 19 Aug 2013 10:47:05 +0200 (CEST) Date: Mon, 19 Aug 2013 10:47:04 +0200 (CEST) Message-Id: <20130819.104704.119047008.he@uninett.no> To: v6ops@ietf.org From: Havard Eidnes In-Reply-To: <201308181800.r7II06mv003294@irp-view13.cisco.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> 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 Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 08:47:14 -0000 Some perhaps non-nit comments (I sent the nits privately): Under section 2.1, Possible Causes: Some filtering and dropping of fragments is known to be done for hardware, performance, or topological considerations. That's quite vague, I think it could stand with some more details. The entire section 2.1.1. "Stateful inspection" is about problems with resource exhaustion in middleboxes or end-system firewalls. Implementations which willingly devote unlimited resources to fragment reassembly display a severe lack robustness, and IMHO should not be used as justification for why we can't use fragments. Yes, I'm suggesting that one can forego the specified 60s fragmentation reassembly timeout in the case of resource shortage of a fixed pool. Under section 2.1.2. Stateless ACLs: Stateless load balancing schemes may hash fragmented datagrams from the same flow to different paths because the 5-tuple may be available on only the initial fragment. While rehashing has the possibility of reordering packets in ISP cores it is not disastrous. However, in front of a stateful inspection device, load balancer tier, or anycast service instance, where headers other than the L3 header -- for example, the L4 header= , interface index (for traffic already rehashed onto different paths),= DS fields -- are considered as part of the hash, rehashing may resul= t in the fragments being delivered to different end-systems AFAIK the use of a 5-tuple which includes the L4 header to compute a hash to make a forwarding decisions among otherwise equal paths is an implementation optimization only, it is not something which is explicitly prescribed by our standards. Therefore, I'll claim that applying this logic to fragments, causing packet delivery to different hosts for initial and subsequent fragments (e.g. in the case of a load balancer) is an incorrectly applied optimization, also known as a bug. Under section 2.1.3. Performance considerations Leaving aside these incentives towards fragment dropping, other considerations may weigh on the operator's mind. One example cited on the NANOG list was that of a router where fragment processing was= done by the control plane processor rather than in the forwarding plane hardware, with a consequent hit on performance. Is this about traffic directed at the one of the local addresses of the router? "Of course", one needs to be careful about letting fragments from anywhere from passing into the data-plane / control- plane bottleneck (but you could conceivably allow fragments from a small controllable subset, e.g. your iBGP neighbors etc.) The impact of having limited ability to send fragments from any source to the routers should be minimal, if noticeable at all. Or is this about traffic passing through the router? If so, doesn't that discussion belong under section 2.1.2? In section 2.1.4. Other considerations you say: It is common practice [RFC6192] to recommend that control-plane ACLs protecting routers and network devices be configured to drop all fragments. Well, there exists an informational RFC [6192] which contains an example policy and also some detailed discussion about handling of fragments. I don't think it in sum says what is said here, though. Best regards, - H=E5vard From gert@space.net Mon Aug 19 05:35: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 733FD11E80E3 for ; Mon, 19 Aug 2013 05:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEJekB3odGKB for ; Mon, 19 Aug 2013 05:35:03 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 1852111E80D3 for ; Mon, 19 Aug 2013 05:35:01 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 48A0D60659 for ; Mon, 19 Aug 2013 14:34:50 +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 1D3DC6029F for ; Mon, 19 Aug 2013 14:34:50 +0200 (CEST) Received: (qmail 18213 invoked by uid 1007); 19 Aug 2013 14:34:50 +0200 Date: Mon, 19 Aug 2013 14:34:50 +0200 From: Gert Doering To: "Fred Baker \(fred\)" Message-ID: <20130819123450.GY65295@Space.Net> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alejandro Acosta , "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 12:35:07 -0000 Hi, On Fri, Aug 16, 2013 at 09:12:31PM +0000, Fred Baker (fred) wrote: > What if we shortened 2001:db8::/32 to 2001:db8::/29? I note that > the prefix doesn't show up in > ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest, and the > IANA counterpart mentions it only in a footnote. 2001:db8 came from APNIC, that's why :-) - their delegated file lists apnic|AU|ipv6|2001:db0::|32|20031112|allocated apnic|AU|ipv6|2001:dc0::|32|20030124|assigned so an extention to /29 would technically be possible, to a /28 won't. As I can't speak for APNIC, this is just about the allocation maths. Their whois *does* list the prefix, though: inet6num: 2001:0DB8::/32 netname: IPV6-DOC-AP descr: IPv6 prefix for documentation purpose ... remarks: http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html 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 iesg-secretary@ietf.org Mon Aug 19 06:52: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 9C89911E8102; Mon, 19 Aug 2013 06:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, 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 04dW2-O5v1Xm; Mon, 19 Aug 2013 06:52:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2595621F99B7; Mon, 19 Aug 2013 06:52:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 06:52:19 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:52:22 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Aug 19 06:55: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 6573411E827E; Mon, 19 Aug 2013 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.141, 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 RcC4BVmGTDEb; Mon, 19 Aug 2013 06:55:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1031E11E8102; Mon, 19 Aug 2013 06:55:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130819135537.17412.77263.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 06:55:37 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv6 for 3GPP Cellular Hosts) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:55:45 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 for 3GPP Cellular Hosts' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionalities that need to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis/ballot/ No IPR declarations have been submitted directly on this I-D. From joelja@bogus.com Mon Aug 19 07:40: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 8FC0721F9B18 for ; Mon, 19 Aug 2013 07:40:59 -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 6bRQXJP2njuO for ; Mon, 19 Aug 2013 07:40:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 16AFE21F9B0D for ; Mon, 19 Aug 2013 07:40:59 -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 r7JEerVx060590 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 14:40:53 GMT (envelope-from joelja@bogus.com) Message-ID: <52122E6F.903@bogus.com> Date: Mon, 19 Aug 2013 07:40:47 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: George Michaelson , Fred Baker References: <201308181800.r7II06mv003294@irp-view13.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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, 19 Aug 2013 14:40:55 +0000 (UTC) Cc: "" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 14:40:59 -0000 On 8/18/13 9:27 PM, George Michaelson wrote: > I think this is a useful review of the issues. I think it makes > operationally pertinant observations. > > I think it stands reasonably neutrally in the 'frag or not' debate, > because both sides can inform themselves from it. I doubt its going to > change many people's minds on the fundamental question. > > I think it helps inform the question(s) being asked. It made me think > harder about the potential for changes to fragments to include > upper-layer headers, and to what extent that kind of change might > break things, or help with the considerations of risk and load and > capability in deployed equipment. > > I am a little worried the document makes unattributed statements about > ASIC and FPGA costs. I think they need to be fleshed out, because this > kind of unsubstantiated and unattributed comment can lead to people > continuing to assume things which applied once, to some vendors, but > doesn't apply now (consider the whole thing about secure disk wiping > which was predicated on a very specific generation of HDD hardware. > Or, the "BGP is dying we need locator+id" debate, which arguably stems > from a false premise) > Actually I think we pretty carefully skirted that in fragdrop, it's http://tools.ietf.org/html/draft-wkumari-long-headers-01 where there hardware is front and center. here it's fast vs slow (potentially no path) / no feasible way to do reassembly. 2.1 mentions hardware a consideration but stops there. > Having said that, if google employees say that they use systems on > their 'edge' which do this, thats certainly attributed. > > -G > > > On Mon, Aug 19, 2013 at 4:00 AM, Fred Baker > wrote: > > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please > read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment > to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Aug 19 10:38: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 AA71511E8131 for ; Mon, 19 Aug 2013 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.637 X-Spam-Level: X-Spam-Status: No, score=-109.637 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FRT_LOLITA1=1.865, 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 Ejmg6Rt+N3n0 for ; Mon, 19 Aug 2013 10:38:25 -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 A2B8611E813D for ; Mon, 19 Aug 2013 10:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3852; q=dns/txt; s=iport; t=1376933905; x=1378143505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PzUQX/KYE/26c7+FrTXcta1WK/LCQTRUn/tkaF4GUew=; b=fVwQffPXiIFUNnq3M4jgG4W6zITSlZA66CUCPsVmY9Thfz76feMG9S87 ZqLIwfw+TLHuDDgn+b2prblIYgbLqQlfSDWFAES9IkK9JhSbu3q6XKTxL TkEqMT4t8OGaGCIyk0zjcaderHPYmy95jR+EOMfzEEtX+F1qMJezKCBdz Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAJ5WElKtJXG9/2dsb2JhbABagwc1Ub8ygSMWdIIkAQEBAwF5BQsCAQgiJDIlAgQBDQUIAQUOh24GDLYgkCsxB4MbdwOQFoEul3WDHIIq X-IronPort-AV: E=Sophos;i="4.89,914,1367971200"; d="asc'?scan'208";a="249088601" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 19 Aug 2013 17:38:25 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7JHcPDL027819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Aug 2013 17:38:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.28]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 12:38:24 -0500 From: "Fred Baker (fred)" To: "Antonio M. Moreiras" , Alejandro Acosta Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: AQHOnQLnfxLPnI7P/02x30eIFMb3Rg== Date: Mon, 19 Aug 2013 17:38:24 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> In-Reply-To: <20130819123450.GY65295@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_3EFB6E92-EFBD-4316-AA73-9A77E7295F90"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:38:30 -0000 --Apple-Mail=_3EFB6E92-EFBD-4316-AA73-9A77E7295F90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 19, 2013, at 5:34 AM, Gert Doering wrote: > 2001:db8 came from APNIC, that's why :-) - their delegated file lists >=20 > apnic|AU|ipv6|2001:db0::|32|20031112|allocated > apnic|AU|ipv6|2001:dc0::|32|20030124|assigned >=20 > so an extention to /29 would technically be possible, to a /28 won't. Hmm. Tell me about 2001:da0:: and 2001:d80::? Per = ftp://ftp.apnic.net/public/stats/apnic/delegated-apnic-ipv6-assigned-lates= t > apnic|AU|ipv6|2001:7fa:b::|48|20050922 > apnic|AU|ipv6|2001:7fa:c::|48|20050922 > apnic|AU|ipv6|2001:7fa:d::|48|20050922 > apnic|AU|ipv6|2001:7fa:e::|48|20050922 > apnic|ID|ipv6|2001:7fa:f::|48|20050929 > apnic|CN|ipv6|2001:7fa:10::|48|20060531 > apnic|AU|ipv6|2001:7fa:11::|48|20061031 > apnic|AU|ipv6|2001:dc0::|32|20030124 > apnic|TW|ipv6|2001:dc1::|32|20030331 > apnic|JP|ipv6|2001:dc2::|32|20030529 > apnic|JP|ipv6|2001:dc3::|32|20030619 To my small mind, that suggests 2001:d80::/26 (64 prefixes), = 2001:da0::/27 (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter = than /26 includes 2001:dc0:: and 2001:de0::, which have been allocated. = The neighborhood, however, includes 2001:db8::, which we already use. I, = for one, would like to see one documentation range, at least for the = global unicast address space, which is to say a prefix shorter than and = including 2001:db8::/32. = http://www.apnic.net/publications/research-and-insights/ip-address-trends/= apnic-resource-range#IPv6Allocation notes that 2001:DB8::/29 is reserved = and by definition available. I note that we are not discussing the recommendation per se; we are = narrowing in on the length of the prefix. Unless someone disagrees, I = think we have pretty much agreed that something shorter than /32 makes = sense. Here's my suggestion. The 6man chairs tell me that RFC 3489 was their = work group product, so it's replacement should be. I'd suggest = respinning the draft as draft-moreiras-6man-rfc3849bis (and tell = internet-drafts@ietf.org that it replaces this one). You want to do two = separate things: a) argue for a shorter prefix in 2000::/3, and make a = separate-but-analogous argument for a prefix in fc00::/8. In those, focus on need, not want. "We designed a lab that has 2^128 = different addresses in it, we obviously need the entire IPv6 address = space" doesn't follow. Say what you *need* and why you *need* it. While = the request was for a /20, I have not heard a cogent argument for a /26 = or shorter, I heard that there was a training lab somewhere that = required a /27 (32 /32s) but have not heard that the intent of the lab = could not have been done with 16 /32s, and observe that a nibble = boundary would suggest a /28 (16 /32s). b) in the IANA considerations section, note: b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28, or = 2001:db8::/29 b.2) the suggestion of fc00:db8:?::/44, which I think we more or less = agreed to in the thread b.3) the fact that this would also affect = http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-speci= al-registry.xhtml#iana-ipv6-special-registry-1 --Apple-Mail=_3EFB6E92-EFBD-4316-AA73-9A77E7295F90 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSElgPbjEdbHIsm0MRAm89AKDXDWZK5xuw/eUa1vjhoVI+mjGBGQCfRW6Q JWcgUffsjjcaRaz0LGtOYEc= =MwP9 -----END PGP SIGNATURE----- --Apple-Mail=_3EFB6E92-EFBD-4316-AA73-9A77E7295F90-- From owen@delong.com Mon Aug 19 10:56: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 179BB11E8145 for ; Mon, 19 Aug 2013 10:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, FRT_LOLITA1=1.865, 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 hm6zXfLlU-sW for ; Mon, 19 Aug 2013 10:56:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 20E7821F9263 for ; Mon, 19 Aug 2013 10:56:18 -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 r7JHqGfK006739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Aug 2013 10:52:16 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7JHqGfK006739 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376934737; bh=GQi+bwoKS5gFJWZIkiqmgV3tVyE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HSbb5ltAKU27Y1YauRfOaQyxcn2gvMMol28FPM1Zuw+1k4p7n7LwpgvbZV4uC3f4V wrlrTj0e0nUiqEjCaUv5bnW0LeSdcSxS9Ybe4DqFYXdN9FyMdV6lo5zJVfbYukRNUg xIWK4/qFHTssAQ5B2Zzr5aj+teeB7Ywp1ObQVdd4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> Date: Mon, 19 Aug 2013 10:52:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 19 Aug 2013 10:52:17 -0700 (PDT) Cc: Alejandro Acosta , "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:56:19 -0000 I think all of Fred's recommendations below are spot on. I support the = changes and I like the idea of 2001:db0::/28. In such a case, should we stick with fc00:db8::/44 or should we consider = fc00:db0::/28 for parity? I'm OK either way, just looking to minimize = potential confusion and wondering if the tradeoff in space is worth = while or not. What do others think? Owen On Aug 19, 2013, at 10:38 , "Fred Baker (fred)" wrote: >=20 > On Aug 19, 2013, at 5:34 AM, Gert Doering wrote: >=20 >> 2001:db8 came from APNIC, that's why :-) - their delegated file lists >>=20 >> apnic|AU|ipv6|2001:db0::|32|20031112|allocated >> apnic|AU|ipv6|2001:dc0::|32|20030124|assigned >>=20 >> so an extention to /29 would technically be possible, to a /28 won't. >=20 > Hmm. Tell me about 2001:da0:: and 2001:d80::? Per = ftp://ftp.apnic.net/public/stats/apnic/delegated-apnic-ipv6-assigned-lates= t >=20 >> apnic|AU|ipv6|2001:7fa:b::|48|20050922 >> apnic|AU|ipv6|2001:7fa:c::|48|20050922 >> apnic|AU|ipv6|2001:7fa:d::|48|20050922 >> apnic|AU|ipv6|2001:7fa:e::|48|20050922 >> apnic|ID|ipv6|2001:7fa:f::|48|20050929 >> apnic|CN|ipv6|2001:7fa:10::|48|20060531 >> apnic|AU|ipv6|2001:7fa:11::|48|20061031 >> apnic|AU|ipv6|2001:dc0::|32|20030124 >> apnic|TW|ipv6|2001:dc1::|32|20030331 >> apnic|JP|ipv6|2001:dc2::|32|20030529 >> apnic|JP|ipv6|2001:dc3::|32|20030619 >=20 >=20 > To my small mind, that suggests 2001:d80::/26 (64 prefixes), = 2001:da0::/27 (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter = than /26 includes 2001:dc0:: and 2001:de0::, which have been allocated. = The neighborhood, however, includes 2001:db8::, which we already use. I, = for one, would like to see one documentation range, at least for the = global unicast address space, which is to say a prefix shorter than and = including 2001:db8::/32. >=20 > = http://www.apnic.net/publications/research-and-insights/ip-address-trends/= apnic-resource-range#IPv6Allocation notes that 2001:DB8::/29 is reserved = and by definition available. >=20 > I note that we are not discussing the recommendation per se; we are = narrowing in on the length of the prefix. Unless someone disagrees, I = think we have pretty much agreed that something shorter than /32 makes = sense. >=20 > Here's my suggestion. The 6man chairs tell me that RFC 3489 was their = work group product, so it's replacement should be. I'd suggest = respinning the draft as draft-moreiras-6man-rfc3849bis (and tell = internet-drafts@ietf.org that it replaces this one). You want to do two = separate things: >=20 > a) argue for a shorter prefix in 2000::/3, and make a = separate-but-analogous argument for a prefix in fc00::/8. > In those, focus on need, not want. "We designed a lab that has 2^128 = different addresses in it, we obviously need the entire IPv6 address = space" doesn't follow. Say what you *need* and why you *need* it. While = the request was for a /20, I have not heard a cogent argument for a /26 = or shorter, I heard that there was a training lab somewhere that = required a /27 (32 /32s) but have not heard that the intent of the lab = could not have been done with 16 /32s, and observe that a nibble = boundary would suggest a /28 (16 /32s). >=20 > b) in the IANA considerations section, note: > b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28, = or 2001:db8::/29 > b.2) the suggestion of fc00:db8:?::/44, which I think we more or less = agreed to in the thread > b.3) the fact that this would also affect = http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-speci= al-registry.xhtml#iana-ipv6-special-registry-1 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From touch@isi.edu Mon Aug 19 11:29: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 2A43C11E814F for ; Mon, 19 Aug 2013 11:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iH1wnjBNlpT for ; Mon, 19 Aug 2013 11:29:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBE311E814E for ; Mon, 19 Aug 2013 11:29:32 -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 r7JISa3U025916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 11:28:36 -0700 (PDT) Message-ID: <521263D3.6070704@isi.edu> Date: Mon, 19 Aug 2013 11:28:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Fred Baker References: <201308181800.r7II06mv003294@irp-view13.cisco.com> In-Reply-To: <201308181800.r7II06mv003294@irp-view13.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:29:37 -0000 Hi, all, I don't quite understand a WGLC on an individual submission. IMO, if it's a WG doc it needs to be opened up for substantial revision. As an individual submission, I think it strays too far into the purview of this WG to be permitted. On the specific point of content, the paragraph at the end of the intro is disingenuous; Section 2.2 is far too brief to be considered anything but dismissive of the cons of dropping fragments, and the rest of the document reads like justification of that behavior. Joe On 8/18/2013 11:00 AM, Fred Baker wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alejandroacostaalamo@gmail.com Mon Aug 19 11:53: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 BC99811E82C2 for ; Mon, 19 Aug 2013 11:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_LOLITA1=1.865, 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 OM8RFnbBLgbx for ; Mon, 19 Aug 2013 11:53:02 -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 9DA0F21F9AFE for ; Mon, 19 Aug 2013 11:53:02 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so1379674wes.29 for ; Mon, 19 Aug 2013 11:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:subject:to:reply-to:mime-version:content-type :content-transfer-encoding; bh=SxESgtfo/BGdAJVGowcSA3h/pPXboXZngBJ5Zu8rH/U=; b=CTs+AOdOpcVcjqOlWj6q3GE6NQFynJqDEf5sbvI8vb+R/UJ9WFslXIK1IHzgvrSzxd YnfvdQgEJlrjNp5iS8GE1RrRhDHnq+XcFJKdDVnYcRi7C9Q/6s67Q1/xnNOl1bl2BdBd muvdes/4qlaECjzWZoVCQnp8jScn5P+3gpByqueWZ9yk9qxcCXsUrfA9REnBHGcdm5tU upg/3qyfmBSvSg7qvmMkJL1w8p8oaxf36NmiJ13aTEp1YeJGGuYEUnSJhEcauz3HxaFD VqBkWiD19vi3yDFAIgUUudJsHzIzTzUsb4Mejj1MD2dd9wZeUfJdOwk+623wfJKPZR9l TKvg== X-Received: by 10.180.160.240 with SMTP id xn16mr9325418wib.62.1376938381783; Mon, 19 Aug 2013 11:53:01 -0700 (PDT) Received: from lhrnms-0059-fe.pr.nmsg.s.nokia.com (em1x-8.lhr.messaging.nokia.com. [131.228.18.8]) by mx.google.com with ESMTPSA id a8sm18821847wie.6.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 19 Aug 2013 11:53:01 -0700 (PDT) Message-ID: <5212698d.0813b40a.4957.ffff8847@mx.google.com> Date: Mon, 19 Aug 2013 18:52:51 +0000 From: "Alejandro Acosta" To: "" , "v6ops@ietf.org" MIME-Version: 1.0 X-Priority: 3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: alejandroacostaalamo@gmail.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:53:03 -0000 Hi, That is a good option. Another posibility is to tale another RIR similar space and to use so= mething like 2800:db8::/nn Thanks, -----Mensaje original----- De: Fred Baker (fred) Enviados: 08/19/2013 1:08:24 PM Asunto: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 On Aug 19, 2013, at 5:34 AM, Gert Doering wrote: > 2001:db8 came from APNIC, that's why :-) - their delegated file lists >=20 > apnic|AU|ipv6|2001:db0::|32|20031112|allocated > apnic|AU|ipv6|2001:dc0::|32|20030124|assigned >=20 > so an extention to /29 would technically be possible, to a /28 won't. Hmm. Tell me about 2001:da0:: and 2001:d80::? Per ftp://ftp.apnic.net/p= ublic/stats/apnic/delegated-apnic-ipv6-assigned-latest > apnic|AU|ipv6|2001:7fa:b::|48|20050922 > apnic|AU|ipv6|2001:7fa:c::|48|20050922 > apnic|AU|ipv6|2001:7fa:d::|48|20050922 > apnic|AU|ipv6|2001:7fa:e::|48|20050922 > apnic|ID|ipv6|2001:7fa:f::|48|20050929 > apnic|CN|ipv6|2001:7fa:10::|48|20060531 > apnic|AU|ipv6|2001:7fa:11::|48|20061031 > apnic|AU|ipv6|2001:dc0::|32|20030124 > apnic|TW|ipv6|2001:dc1::|32|20030331 > apnic|JP|ipv6|2001:dc2::|32|20030529 > apnic|JP|ipv6|2001:dc3::|32|20030619 To my small mind, that suggests 2001:d80::/26 (64 prefixes), 2001:da0::= /27 (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter than /26 in= cludes 2001:dc0:: and 2001:de0::, which have been allocated. The neighb= orhood, however, includes 2001:db8::, which we already use. I, for one,= would like to see one documentation range, at least for the global uni= cast address space, which is to say a prefix shorter than and including= 2001:db8::/32. http://www.apnic.net/publications/research-and-insights/ip-address-tren= ds/apnic-resource-range#IPv6Allocation notes that 2001:DB8::/29 is rese= rved and by definition available. I note that we are not discussing the recommendation per se; we are nar= rowing in on the length of the prefix. Unless someone disagrees, I thin= k we have pretty much agreed that something shorter than /32 makes sens= e. Here's my suggestion. The 6man chairs tell me that RFC 3489 was their w= ork group product, so it's replacement should be. I'd suggest respinnin= g the draft as draft-moreiras-6man-rfc3849bis (and tell internet-drafts= @ietf.org that it replaces this one). You want to do two separate thing= s: a) argue for a shorter prefix in 2000::/3, and make a separate-but-anal= ogous argument for a prefix in fc00::/8. In those, focus on need, not want. "We designed a lab that has 2^128 di= fferent addresses in it, we obviously need the entire IPv6 address spac= e" doesn't follow. Say what you *need* and why you *need* it. While the= request was for a /20, I have not heard a cogent argument for a /26 or= shorter, I heard that there was a training lab somewhere that required= a /27 (32 /32s) but have not heard that the intent of the lab could no= t have been done with 16 /32s, and observe that a nibble boundary would= suggest a /28 (16 /32s). b) in the IANA considerations section, note: b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28, o= r 2001:db8::/29 b.2) the suggestion of fc00:db8:?::/44, which I think we more or less a= greed to in the thread b.3) the fact that this would also affect http://www.iana.org/assignmen= ts/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#iana-ipv= 6-special-registry-1 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Aug 19 12:13: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 BCD9411E82E0 for ; Mon, 19 Aug 2013 12:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.187 X-Spam-Level: X-Spam-Status: No, score=-110.187 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 ssjc5zCWpxsi for ; Mon, 19 Aug 2013 12:13:46 -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 E708911E82DE for ; Mon, 19 Aug 2013 12:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2674; q=dns/txt; s=iport; t=1376939626; x=1378149226; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kjzOGPJBPLmaqdMRb0MJkRToG2uDGE2jI6E+OTJ1+pE=; b=lrCWDB8gHe/IusY5i+UDEqqsTjZ/81sqnAKSXGTFvHEsb82CaNBVgBt9 6O6Vt3843aWbArGCRYIeK79Zq7VfM/xcPJRqNXvBEnWn5+HlKpfR8kJyI aNZHzQds/CRAA0lDQAVp+E3H/2QoJCDHXla+B6E7SRzBh7k6XVMww2f0D k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFABJuElKtJV2Y/2dsb2JhbABaDoJ5NVG/MoEjFnSCJAEBAQMBAQEBawsFCwIBCBgKJCcLJQIEDgUIBod8Bgy2MJArMQeDG3cDkBaBLodNkCiCXT+CKg X-IronPort-AV: E=Sophos;i="4.89,914,1367971200"; d="asc'?scan'208";a="249111202" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 19 Aug 2013 19:13:45 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7JJDjI3010975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Aug 2013 19:13:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.28]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 14:13:45 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] draft-taylor-v6ops-fragdrop WGLC Thread-Index: AQHOnRA5eHCcTs451kadvEuCKo14UQ== Date: Mon, 19 Aug 2013 19:13:44 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9A92CB@xmb-rcd-x09.cisco.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <521263D3.6070704@isi.edu> In-Reply-To: <521263D3.6070704@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_191333E8-C2B9-4943-8BF6-7DEEF684A61E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:13:50 -0000 --Apple-Mail=_191333E8-C2B9-4943-8BF6-7DEEF684A61E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 19, 2013, at 11:28 AM, Joe Touch wrote: > Hi, all, >=20 > I don't quite understand a WGLC on an individual submission. IMO, if = it's a WG doc it needs to be opened up for substantial revision. >=20 > As an individual submission, I think it strays too far into the = purview of this WG to be permitted. I can see this both ways. v6ops has in the past sent individual = documents this way when it agreed to them. My perspective is that the = draft is largely agreed to and is close to being ready to move on. If we = need to rework it in some way, we can have the reworked draft as a = working group document. If we agree to it as it stands, I'm not sure I = see the mechanical point. > On the specific point of content, the paragraph at the end of the = intro is disingenuous; Section 2.2 is far too brief to be considered = anything but dismissive of the cons of dropping fragments, and the rest = of the document reads like justification of that behavior. Ack. Thanks. > Joe >=20 > On 8/18/2013 11:00 AM, Fred Baker wrote: >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please read = it now. If you find nits >> (spelling errors, minor suggested wording changes, etc), comment to = the >> authors; if you find greater issues, such as disagreeing with a >> statement or finding additional issues that need to be addressed, >> please post your comments to the list. >>=20 >> We are looking specifically for comments on the importance of the >> document as well as its content. If you have read the document and >> believe it to be of operational utility, that is also an important >> comment to make. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein --Apple-Mail=_191333E8-C2B9-4943-8BF6-7DEEF684A61E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSEm5objEdbHIsm0MRAjvwAJ9xc421FoCbe1/fEh4wRj+7ZMvOGACaAqDr 2gJNFrPWUglzyCM6zLvcqTc= =8dN/ -----END PGP SIGNATURE----- --Apple-Mail=_191333E8-C2B9-4943-8BF6-7DEEF684A61E-- From brian.e.carpenter@gmail.com Mon Aug 19 13:37: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 D975E21F9AAB for ; Mon, 19 Aug 2013 13:37:05 -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 jmRbVaetuybH for ; Mon, 19 Aug 2013 13:37:04 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1E74311E82EA for ; Mon, 19 Aug 2013 13:36:33 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so5434764pbb.0 for ; Mon, 19 Aug 2013 13:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JbsnSeO8i/Fq5i3TFRwPsqTpv245ZpLy0oWdUYD2MXY=; b=AZbQtxWl3lwB1L8/4Tj7UqwlqBXNpz9bYrLY27vC56rC4hjsSUi/pchHscgIY/TuCe MZIu41WsnM2E+LqMX74s+PBFvGaKTiytEO7d//+Nh3uXfe+b7x1N58YNxErQk8BSNmJu mWvTL+/k3duxn6zIV3UOAM4/d77r43u9etzXhSVQPLKFXdxQ4vVPkhuG6MIOC88mnTTG VJWo51JdK9kmWxZ9V/ayXQkuMkPwZ7SoBIEqwcO4EwrdhMFYXf94OB6cQCb3Zm1jSzuJ MEzcR6CdRhNmBofxomW0duGsn/EvtPq52pxZTY2j6+OrIMacCY2pyQ9s5U6HhCXtj/0n KQXg== X-Received: by 10.66.142.42 with SMTP id rt10mr14981218pab.1.1376944591621; Mon, 19 Aug 2013 13:36:31 -0700 (PDT) Received: from [192.168.178.20] (204.200.69.111.dynamic.snap.net.nz. [111.69.200.204]) by mx.google.com with ESMTPSA id ut7sm16935052pbc.31.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 13:36:30 -0700 (PDT) Message-ID: <521281D0.9050808@gmail.com> Date: Tue, 20 Aug 2013 08:36:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <521263D3.6070704@isi.edu> <8C48B86A895913448548E6D15DA7553B9A92CB@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9A92CB@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:37:06 -0000 On 20/08/2013 07:13, Fred Baker (fred) wrote: > On Aug 19, 2013, at 11:28 AM, Joe Touch > wrote: > >> Hi, all, >> >> I don't quite understand a WGLC on an individual submission. IMO, if it's a WG doc it needs to be opened up for substantial revision. >> >> As an individual submission, I think it strays too far into the purview of this WG to be permitted. > > I can see this both ways. v6ops has in the past sent individual documents this way when it agreed to them. My perspective is that the draft is largely agreed to and is close to being ready to move on. If we need to rework it in some way, we can have the reworked draft as a working group document. If we agree to it as it stands, I'm not sure I see the mechanical point. The fact that the draft doesn't happen to match the draft-ietf-v6ops naming convention is beside the point, and there is no formal stage called "WG adoption" in the IETF standards process. It's perfectly "legal" to bypass these two conventional steps. I think the document is valuable and should be published, but... >> On the specific point of content, the paragraph at the end of the intro is disingenuous; Section 2.2 is far too brief to be considered anything but dismissive of the cons of dropping fragments, and the rest of the document reads like justification of that behavior. I agree that section 2.2 needs more work. Dropping fragments breaks stuff that is supposed to work, and we should explain this thoroughly. I agree that work-arounds are out of scope - this draft should focus on current reality. At the minimum, the last sentence of 2.2 needs to be turned into English. I can't understand it at all. Brian > Ack. Thanks. > >> Joe >> >> On 8/18/2013 11:00 AM, Fred Baker wrote: >>> This is to initiate a two week working group last call of >>> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop. Please read it now. If you find nits >>> (spelling errors, minor suggested wording changes, etc), comment to the >>> authors; if you find greater issues, such as disagreeing with a >>> statement or finding additional issues that need to be addressed, >>> please post your comments to the list. >>> >>> We are looking specifically for comments on the importance of the >>> document as well as its content. If you have read the document and >>> believe it to be of operational utility, that is also an important >>> comment to make. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > If at first the idea is not absurd, then there is no hope for it. > Albert Einstein > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From touch@isi.edu Mon Aug 19 13:51: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 E86CE21F89A6 for ; Mon, 19 Aug 2013 13:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnMYqdyMb3YF for ; Mon, 19 Aug 2013 13:51:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B521F9EA9 for ; Mon, 19 Aug 2013 13:51:22 -0700 (PDT) Received: from [128.9.176.27] (c1-vpn1.isi.edu [128.9.176.27]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r7JKoVqS023192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 13:50:31 -0700 (PDT) Message-ID: <52128518.3050307@isi.edu> Date: Mon, 19 Aug 2013 13:50:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian E Carpenter References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <521263D3.6070704@isi.edu> <8C48B86A895913448548E6D15DA7553B9A92CB@xmb-rcd-x09.cisco.com> <521281D0.9050808@gmail.com> In-Reply-To: <521281D0.9050808@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: "" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:51:43 -0000 On 8/19/2013 1:36 PM, Brian E Carpenter wrote: > On 20/08/2013 07:13, Fred Baker (fred) wrote: >> On Aug 19, 2013, at 11:28 AM, Joe Touch >> wrote: >> >>> Hi, all, >>> >>> I don't quite understand a WGLC on an individual submission. IMO, if it's a WG doc it needs to be opened up for substantial revision. >>> >>> As an individual submission, I think it strays too far into the purview of this WG to be permitted. >> >> I can see this both ways. v6ops has in the past sent individual documents this way when it agreed to them. My perspective is that the draft is largely agreed to and is close to being ready to move on. If we need to rework it in some way, we can have the reworked draft as a working group document. If we agree to it as it stands, I'm not sure I see the mechanical point. > > The fact that the draft doesn't happen to match the draft-ietf-v6ops naming > convention is beside the point, and there is no formal stage called "WG > adoption" in the IETF standards process. It's perfectly "legal" to bypass > these two conventional steps. Like some of the content of the doc, IMO that is misleading at best. There is a well-understood convention for WG docs: http://www.ietf.org/id-info/guidelines.html#naming I did assume that this isn't a WG doc because of its naming. IMO, a WG shouldn't endorse non-WG docs that are within its purview. Joe From carlosm3011@gmail.com Mon Aug 19 14: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 AC71521F92B9 for ; Mon, 19 Aug 2013 14:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, FRT_LOLITA1=1.865, 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 gADt9YAksn1Z for ; Mon, 19 Aug 2013 14:13:24 -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 2DDCD21F9263 for ; Mon, 19 Aug 2013 14:13:23 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eo20so3799098lab.3 for ; Mon, 19 Aug 2013 14:13:23 -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:date:message-id :subject:from:to:cc:content-type; bh=I/z9esZArDzv3VmqlR8EG6U3G/zJc2+4bDNnihjVwnc=; b=1CDTlARYHH9zMVwkgfWrZoVx864zEmigCGWEn0SN3scpX6MXGH/r9oAZiKZbhvOb5y v40hwgIqPYW/3uU+WWUzjdmLW1A1JBfZN9Z0baVDIToclYvFiN3ch6cNaUqltSPS9L2e 468jzYLOxZTS4XGKQRRy+NtfzuZDro4c75OgkKif6Z5LAzIx0i+IoDuHW66Mg2gfjdDq 4BSHISY8Y1lPMJT0d5MFHRq8C/upMNuDexG1yiA2xv3YcllNfY2BUqzuDahx1NQplz2b ElT8yLic7n22VfKHmEKSxOcSyMpV3fIhPR6UMfPem/mv0R2kXS0ETIiUMp0u6cXn+GQh zMlQ== MIME-Version: 1.0 X-Received: by 10.152.8.12 with SMTP id n12mr13948379laa.10.1376946802968; Mon, 19 Aug 2013 14:13:22 -0700 (PDT) Received: by 10.112.168.225 with HTTP; Mon, 19 Aug 2013 14:13:22 -0700 (PDT) In-Reply-To: <5212698d.0813b40a.4957.ffff8847@mx.google.com> References: <5212698d.0813b40a.4957.ffff8847@mx.google.com> Date: Mon, 19 Aug 2013 18:13:22 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: Alejandro Acosta Content-Type: multipart/alternative; boundary=001a11c365b610cdb504e45369ce Cc: "" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:13:25 -0000 --001a11c365b610cdb504e45369ce Content-Type: text/plain; charset=ISO-8859-1 Alejandro, I like that. From a teacher's PoV it would probably very illustrative to have this proposed /20 or /24 but _made up from non-contiguous prefixes_. In the end the goal is to provide each 'team' with a dedicated /32, but if the blocks that these /32s come from are quite different, well, it would look a lot like the 'real' Internet. I can't speak from anyone, but if 4 more blocks like 2001:dbX/29 could be obtained, I think we've mostly solved the problem, in a better way than originally envisioned. The problem of operators having to revisit their prefix lists / ingress ACLs remains, though. Just a thought. ~Carlos On Mon, Aug 19, 2013 at 3:52 PM, Alejandro Acosta < alejandroacostaalamo@gmail.com> wrote: > Hi, > That is a good option. > Another posibility is to tale another RIR similar space and to use > something like 2800:db8::/nn > > Thanks, > > > -----Mensaje original----- > De: Fred Baker (fred) > Enviados: 08/19/2013 1:08:24 PM > Asunto: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 > > > On Aug 19, 2013, at 5:34 AM, Gert Doering wrote: > > > 2001:db8 came from APNIC, that's why :-) - their delegated file lists > > > > apnic|AU|ipv6|2001:db0::|32|20031112|allocated > > apnic|AU|ipv6|2001:dc0::|32|20030124|assigned > > > > so an extention to /29 would technically be possible, to a /28 won't. > > Hmm. Tell me about 2001:da0:: and 2001:d80::? Per > ftp://ftp.apnic.net/public/stats/apnic/delegated-apnic-ipv6-assigned-latest > > > apnic|AU|ipv6|2001:7fa:b::|48|20050922 > > apnic|AU|ipv6|2001:7fa:c::|48|20050922 > > apnic|AU|ipv6|2001:7fa:d::|48|20050922 > > apnic|AU|ipv6|2001:7fa:e::|48|20050922 > > apnic|ID|ipv6|2001:7fa:f::|48|20050929 > > apnic|CN|ipv6|2001:7fa:10::|48|20060531 > > apnic|AU|ipv6|2001:7fa:11::|48|20061031 > > apnic|AU|ipv6|2001:dc0::|32|20030124 > > apnic|TW|ipv6|2001:dc1::|32|20030331 > > apnic|JP|ipv6|2001:dc2::|32|20030529 > > apnic|JP|ipv6|2001:dc3::|32|20030619 > > > To my small mind, that suggests 2001:d80::/26 (64 prefixes), 2001:da0::/27 > (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter than /26 includes > 2001:dc0:: and 2001:de0::, which have been allocated. The neighborhood, > however, includes 2001:db8::, which we already use. I, for one, would like > to see one documentation range, at least for the global unicast address > space, which is to say a prefix shorter than and including 2001:db8::/32. > > > http://www.apnic.net/publications/research-and-insights/ip-address-trends/apnic-resource-range#IPv6Allocationnotes that 2001:DB8::/29 is reserved and by definition available. > > I note that we are not discussing the recommendation per se; we are > narrowing in on the length of the prefix. Unless someone disagrees, I think > we have pretty much agreed that something shorter than /32 makes sense. > > Here's my suggestion. The 6man chairs tell me that RFC 3489 was their work > group product, so it's replacement should be. I'd suggest respinning the > draft as draft-moreiras-6man-rfc3849bis (and tell internet-drafts@ietf.orgthat it replaces this one). You want to do two separate things: > > a) argue for a shorter prefix in 2000::/3, and make a > separate-but-analogous argument for a prefix in fc00::/8. > In those, focus on need, not want. "We designed a lab that has 2^128 > different addresses in it, we obviously need the entire IPv6 address space" > doesn't follow. Say what you *need* and why you *need* it. While the > request was for a /20, I have not heard a cogent argument for a /26 or > shorter, I heard that there was a training lab somewhere that required a > /27 (32 /32s) but have not heard that the intent of the lab could not have > been done with 16 /32s, and observe that a nibble boundary would suggest a > /28 (16 /32s). > > b) in the IANA considerations section, note: > b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28, or > 2001:db8::/29 > b.2) the suggestion of fc00:db8:?::/44, which I think we more or less > agreed to in the thread > b.3) the fact that this would also affect > http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#iana-ipv6-special-registry-1 > _______________________________________________ > 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 > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= --001a11c365b610cdb504e45369ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alejandro,

I like that. From a teacher&= #39;s PoV it would probably very illustrative to have this proposed /20 or = /24 but _made up from non-contiguous prefixes_. In the end the goal is to p= rovide each 'team' with a dedicated /32, but if the blocks that the= se /32s come from are quite different, well, it would look a lot like the &= #39;real' Internet.

I can't speak from anyone, but if 4 more blocks lik= e 2001:dbX/29 could be obtained, I think we've mostly solved the proble= m, in a better way than originally envisioned. The problem of operators hav= ing to revisit their prefix lists / ingress ACLs remains, though.

Just a thought.

~Carlos
<= /div>


On Mon, = Aug 19, 2013 at 3:52 PM, Alejandro Acosta <alejandroacostaala= mo@gmail.com> wrote:
Hi,
=A0 That is a good option.
=A0 Another posibility is to tale another RIR similar space and to use some= thing like 2800:db8::/nn

Thanks,


-----Mensaje original-----
De: Fred Baker (fred)
Enviados: =A008/19/2013 1:08:24 PM
Asunto: =A0Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00


On Aug 19, 2013, at 5:34 AM, Gert Doering <gert@space.net> wrote:

> 2001:db8 came from APNIC, that's why :-) - their delegated file li= sts
>
> apnic|AU|ipv6|2001:db0::|32|20031112|allocated
> apnic|AU|ipv6|2001:dc0::|32|20030124|assigned
>
> so an extention to /29 would technically be possible, to a /28 won'= ;t.

Hmm. Tell me about 2001:da0:: and 2001:d80::? Per ftp://ftp.apnic.net/public/stats/apnic/delegated-apnic-ipv6-assigned-= latest

> apnic|AU|ipv6|2001:7fa:b::|48|20050922
> apnic|AU|ipv6|2001:7fa:c::|48|20050922
> apnic|AU|ipv6|2001:7fa:d::|48|20050922
> apnic|AU|ipv6|2001:7fa:e::|48|20050922
> apnic|ID|ipv6|2001:7fa:f::|48|20050929
> apnic|CN|ipv6|2001:7fa:10::|48|20060531
> apnic|AU|ipv6|2001:7fa:11::|48|20061031
> apnic|AU|ipv6|2001:dc0::|32|20030124
> apnic|TW|ipv6|2001:dc1::|32|20030331
> apnic|JP|ipv6|2001:dc2::|32|20030529
> apnic|JP|ipv6|2001:dc3::|32|20030619


To my small mind, that suggests 2001:d80::/26 (64 prefixes), 2001:da0::/27 = (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter than /26 includes 2= 001:dc0:: and 2001:de0::, which have been allocated. The neighborhood, howe= ver, includes 2001:db8::, which we already use. I, for one, would like to s= ee one documentation range, at least for the global unicast address space, = which is to say a prefix shorter than and including 2001:db8::/32.

http://www= .apnic.net/publications/research-and-insights/ip-address-trends/apnic-resou= rce-range#IPv6Allocation notes that 2001:DB8::/29 is reserved and by de= finition available.

I note that we are not discussing the recommendation per se; we are narrowi= ng in on the length of the prefix. Unless someone disagrees, I think we hav= e pretty much agreed that something shorter than /32 makes sense.

Here's my suggestion. The 6man chairs tell me that RFC 3489 was their w= ork group product, so it's replacement should be. I'd suggest respi= nning the draft as draft-moreiras-6man-rfc3849bis (and tell internet-drafts@ietf.org that it replaces = this one). You want to do two separate things:

a) argue for a shorter prefix in 2000::/3, and make a separate-but-analogou= s argument for a prefix in fc00::/8.
In those, focus on need, not want. "We designed a lab that has 2^128 d= ifferent addresses in it, we obviously need the entire IPv6 address space&q= uot; doesn't follow. Say what you *need* and why you *need* it. While t= he request was for a /20, I have not heard a cogent argument for a /26 or s= horter, I heard that there was a training lab somewhere that required a /27= (32 /32s) but have not heard that the intent of the lab could not have bee= n done with 16 /32s, and observe that a nibble boundary would suggest a /28= (16 /32s).

b) in the IANA considerations section, note:
b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28, or 20= 01:db8::/29
b.2) the suggestion of fc00:db8:?::/44, which I think we more or less agree= d to in the thread
b.3) the fact that this would also affect http://www.iana.org/assignments/= iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#iana-ipv6-speci= al-registry-1
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

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



--
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--001a11c365b610cdb504e45369ce-- From fred@cisco.com Mon Aug 19 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 52B8921F8E70 for ; Mon, 19 Aug 2013 14:25:57 -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 vS1ySuzLpSkK for ; Mon, 19 Aug 2013 14:25:52 -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 5B63711E8118 for ; Mon, 19 Aug 2013 14:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3314; q=dns/txt; s=iport; t=1376947548; x=1378157148; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MWLKdKkBXhRrAmCYJEfY0IPa9Hcbt6BWa6umWiucyNY=; b=htuQmjMNam2uGpI5AomtP2/l97VNMo+LU/cKYm8gyUGrkV6AfR+ekzBB ajTKfxzlmI+kppQL8OXAnb/UMcfmvqbvF1r5wtDv9EoUDAXfiXYUR0q6o WjnVOK7d5xHHorR/YVRy+NBvQ/a96jCO8KVttayfsxYw4yJnoFkkUsubo s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPeMElKtJXG+/2dsb2JhbABbDoJ3NVG/M4EkFnSCJQEBBHQFEAIBCCIkMiUCBAENBQgBBYgCDKt9kCsxB4MbdwOQFoEul3WCXT+CKg X-IronPort-AV: E=Sophos;i="4.89,914,1367971200"; d="asc'?scan'208";a="249178732" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 19 Aug 2013 21:25:38 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7JLPc8X005979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Aug 2013 21:25:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.28]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 16:25:37 -0500 From: "Fred Baker (fred)" To: Joe Touch , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-taylor-v6ops-fragdrop WGLC Thread-Index: AQHOnSKlhZTiLuG/r0W2rG0DGNaH0A== Date: Mon, 19 Aug 2013 21:25:37 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9A950F@xmb-rcd-x09.cisco.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <521263D3.6070704@isi.edu> <8C48B86A895913448548E6D15DA7553B9A92CB@xmb-rcd-x09.cisco.com> <521281D0.9050808@gmail.com> <52128518.3050307@isi.edu> In-Reply-To: <52128518.3050307@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_8ED13F54-0CC6-4F8E-86E7-CA82C2711BF0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:25:57 -0000 --Apple-Mail=_8ED13F54-0CC6-4F8E-86E7-CA82C2711BF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 19, 2013, at 1:50 PM, Joe Touch wrote: >>>> I don't quite understand a WGLC on an individual submission. IMO, = if it's a WG doc it needs to be opened up for substantial revision. >>>>=20 >>>> As an individual submission, I think it strays too far into the = purview of this WG to be permitted. >>>=20 >>> I can see this both ways. v6ops has in the past sent individual = documents this way when it agreed to them. My perspective is that the = draft is largely agreed to and is close to being ready to move on. If we = need to rework it in some way, we can have the reworked draft as a = working group document. If we agree to it as it stands, I'm not sure I = see the mechanical point. >>=20 >> The fact that the draft doesn't happen to match the draft-ietf-v6ops = naming >> convention is beside the point, and there is no formal stage called = "WG >> adoption" in the IETF standards process. It's perfectly "legal" to = bypass >> these two conventional steps. >=20 > Like some of the content of the doc, IMO that is misleading at best. = There is a well-understood convention for WG docs: >=20 > http://www.ietf.org/id-info/guidelines.html#naming >=20 > I did assume that this isn't a WG doc because of its naming. IMO, a WG = shouldn't endorse non-WG docs that are within its purview. As I note, this isn't the first time it has been done in this working = group. That said, I'm not sure what a legal discussion of the naming of = the draft has to do with the charter of the working group. Here's my = proposed resolution: (1) Joe, please go to whatever list it would be that naming guidelines = are discussed (ietf@ietf.org?) and get me some guidance. If I'm doing it = wrong, let's have that discussion in the place that is chartered to have = it, and correct me. With my blessing. (2) I have heard several comments to the effect that, specific issues = with the draft notwithstanding, they support the document itself. I can = interpret that as support for adoption as a working group draft. General = request to the working group: if you would like it adopted, please feel = free to say so; if not, please say so. It would be a draft describing = operational practice of some operators, and the logic behind that = practice, but not recommending operational practice one way or the = other. (3) Given that, at the end of the WGLC (which turns out to be a "please = comment on the document" call), we know that we have some updates = coming. We will ask the authors to update it per the commentary and = resubmit as draft-ietf-v6ops-fragdrop. --Apple-Mail=_8ED13F54-0CC6-4F8E-86E7-CA82C2711BF0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSEo1QbjEdbHIsm0MRAm2zAKDVYY4WjqcyrUVrgrGqnhOzavyJLQCgy3fK qc5keBEpGFY3v6Dy2ST7Fp0= =H1JX -----END PGP SIGNATURE----- --Apple-Mail=_8ED13F54-0CC6-4F8E-86E7-CA82C2711BF0-- From fred@cisco.com Mon Aug 19 14:30: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 0EF4B11E814B for ; Mon, 19 Aug 2013 14:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.471 X-Spam-Level: X-Spam-Status: No, score=-110.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 kILkVC+h5v0G for ; Mon, 19 Aug 2013 14:29:57 -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 55E3121F977A for ; Mon, 19 Aug 2013 14:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1938; q=dns/txt; s=iport; t=1376947796; x=1378157396; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dOx71zvuCrcEpyYn/g6s+/ZYh5JghokkQ7bGvYctD+Y=; b=gUqK7Tbn5Yt6b5Ucm7+1Eppgv1QUoBB1XZ6+qdSGfMhPKR2hfbiufw9y /Oo6vkLcmmGwnyNXit8rAdGf5NdSH14UmOAWQBue7U6rmY7y/Xw46GqWk WcU/0q8xwAF7BaqIPDtEfN9DP/tt5I1l+RgNG/5cyOBPGquioaLeFU7lo k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAOeNElKtJV2d/2dsb2JhbABbgwWBBr80gSQWdIIkAQEBAwF5BQsCAQgiJDIlAgQOBQgGh3wGrAiPHoENMQeDG3cDkBaBLowai1uDHIFpQQ X-IronPort-AV: E=Sophos;i="4.89,914,1367971200"; d="asc'?scan'208";a="249134393" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 19 Aug 2013 21:29:55 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7JLTtAJ031552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Aug 2013 21:29:55 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.28]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 16:29:55 -0500 From: "Fred Baker (fred)" To: Owen DeLong Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: AQHOnSM/vb4c/joEcUaScjJd8+oWZA== Date: Mon, 19 Aug 2013 21:29:55 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9A9526@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_903DE1E8-D04E-48ED-8FC4-71654C252D68"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Alejandro Acosta , "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:30:12 -0000 --Apple-Mail=_903DE1E8-D04E-48ED-8FC4-71654C252D68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 19, 2013, at 10:52 AM, Owen DeLong wrote: > In such a case, should we stick with fc00:db8::/44 or should we = consider fc00:db0::/28 for parity? I'm concerned on two points.=20 I don't think "parity" is a strong argument. It seems to me that we want = to be able to have an example with several ULAs. ULAs are, by = definition, /48s. The discussion on 2000::/3 led us to somewhere in the = neighborhood of 16..32 prefixes that might be allocated to an operator = in an example making sense. 16..32 /48 prefixes takes me closer to /44 = than /28. When I wrote "fc00:db8:?::/44", the '?' was very deliberately there. = George Michaelson's talk at IETF 87 highlighted that APNIC sees ULA = source addresses in the traffic that makes it to their darknet, and = specifically they see people that have randomly chosen the 40 bit number = "0" to insert into fd00::/8 - the source address in the datagram is in = fd00:0000:0000:xxxx::/64. That suggests to me that people see the prefix = fd00::/8 and take it literally. Color me "cautious", but I think that = would be a bad precedent to follow. I'd rather the '?' was anything but = zero, if only to limit faults between the keyboard and the chair. --Apple-Mail=_903DE1E8-D04E-48ED-8FC4-71654C252D68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSEo5RbjEdbHIsm0MRAmEVAKD5ud2ZuYsgWTCYKLSZqYF5KF4GnACfdI+N G+GC+A8QdwlP+STOlYr31TQ= =4lkX -----END PGP SIGNATURE----- --Apple-Mail=_903DE1E8-D04E-48ED-8FC4-71654C252D68-- From touch@isi.edu Mon Aug 19 14: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 794B511E8162 for ; Mon, 19 Aug 2013 14:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.179 X-Spam-Level: X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqMlYjYhG7EL for ; Mon, 19 Aug 2013 14:33:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id C733011E8118 for ; Mon, 19 Aug 2013 14:33:37 -0700 (PDT) Received: from [128.9.176.27] (c1-vpn1.isi.edu [128.9.176.27]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r7JLXHOD022288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 14:33:18 -0700 (PDT) Message-ID: <52128F1E.1080101@isi.edu> Date: Mon, 19 Aug 2013 14:33:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <521263D3.6070704@isi.edu> <8C48B86A895913448548E6D15DA7553B9A92CB@xmb-rcd-x09.cisco.com> <521281D0.9050808@gmail.com> <52128518.3050307@isi.edu> <8C48B86A895913448548E6D15DA7553B9A950F@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9A950F@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:33:42 -0000 Hi, all, On 8/19/2013 2:25 PM, Fred Baker (fred) wrote: > > On Aug 19, 2013, at 1:50 PM, Joe Touch > wrote: > >>>>> I don't quite understand a WGLC on an individual submission. IMO, if it's a WG doc it needs to be opened up for substantial revision. >>>>> >>>>> As an individual submission, I think it strays too far into the purview of this WG to be permitted. >>>> >>>> I can see this both ways. v6ops has in the past sent individual documents this way when it agreed to them. My perspective is that the draft is largely agreed to and is close to being ready to move on. If we need to rework it in some way, we can have the reworked draft as a working group document. If we agree to it as it stands, I'm not sure I see the mechanical point. >>> >>> The fact that the draft doesn't happen to match the draft-ietf-v6ops naming >>> convention is beside the point, and there is no formal stage called "WG >>> adoption" in the IETF standards process. It's perfectly "legal" to bypass >>> these two conventional steps. >> >> Like some of the content of the doc, IMO that is misleading at best. There is a well-understood convention for WG docs: >> >> http://www.ietf.org/id-info/guidelines.html#naming >> >> I did assume that this isn't a WG doc because of its naming. IMO, a WG shouldn't endorse non-WG docs that are within its purview. > > As I note, this isn't the first time it has been done in this > working group. That said, I'm not sure what a legal discussion of the > naming of the draft has to do with the charter of the working group. It doesn't. Is this a WG doc or not? If it isn't a WG doc, then I fail to see the rational of a WGLC (even though "legally" there's no such thing as a WGLC anyway). > Here's my proposed resolution: > > (1) Joe, please go to whatever list it would be that naming > guidelines are discussed (ietf@ietf.org?) and get me some guidance. > If I'm doing it wrong, let's have that discussion in the place that > is chartered to have it, and correct me. With my blessing. The naming conventions are here: http://www.ietf.org/ietf-ftp/1id-guidelines.txt If you don't think that they're useful, you should take to whatever list is relevant. Note that I'm not claiming whether it's 'legal' to have a non-WG doc without using those conventions; it's clearly misleading given this is the widely-accepted convention. > (2) I have heard several comments to the effect that, specific > issues with the draft notwithstanding, they support the document itself. I can > interpret that as support for adoption as a working group draft. General > request to the working group: if you would like it adopted, please feel > free to say so; if not, please say so. It would be a draft describing > operational practice of some operators, and the logic behind that > practice, but not recommending operational practice one way or the other. I support having this be a WG doc. Joe > (3) Given that, at the end of the WGLC (which turns out to be a > "please comment on the document" call), we know that we have some > updates coming. We will ask the authors to update it per the commentary > and resubmit as draft-ietf-v6ops-fragdrop. From ggm@algebras.org Mon Aug 19 18:06:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BB121F8F97 for ; Mon, 19 Aug 2013 18:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSBvgnOXEZX6 for ; Mon, 19 Aug 2013 18:06:21 -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 E321221F8C71 for ; Mon, 19 Aug 2013 18:06:18 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so5906258pdj.26 for ; Mon, 19 Aug 2013 18:06:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KaS8Hf/XhIfCgTB8+ShdvLsK8HDVHqUyibn36JEsFDo=; b=iDNavnYDjpaV+MT9rsXAZU330tthJrOCVldJ1492qTJvrmqMoJKA8E5wL+I/v2rS6O 7f2Zt/XjUMJDeJHcTUugTkM/IlbagynHDoNXFzpqkhhjfxyHx8PJHNVnYEDEpva1Daq2 jfEp4d7oyrgytYGNmTkgQr8RbRke2WVGP5cnZUITvT8toWAzGUsYYJhUh/NgPRgUiUKs d/sEP8DDJC/uK6mumlLvBxLP31aCog+u7Mte4Zy4mfNKuh6naziC+ROFx63d/RwKtsJe RveSTH0JyiTsl6WLekHl84duGUcQxbkj8ex5pHfTHxYYt23+ZLUUSY505dm1lHK8vVNn 9WhQ== X-Gm-Message-State: ALoCoQkD+eruk08tIB0VLhzyPOigxj5NbOapJ1Zg8ptNIjR4UUVJ2JHd1sgFzmfxASAVq9sK8zp7 MIME-Version: 1.0 X-Received: by 10.68.1.9 with SMTP id 9mr5665456pbi.128.1376960778487; Mon, 19 Aug 2013 18:06:18 -0700 (PDT) Received: by 10.70.19.98 with HTTP; Mon, 19 Aug 2013 18:06:18 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:a91f:156b:a068:ed68] In-Reply-To: <52122E6F.903@bogus.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <52122E6F.903@bogus.com> Date: Tue, 20 Aug 2013 11:06:18 +1000 Message-ID: From: George Michaelson To: joel jaeggli Content-Type: multipart/alternative; boundary=bcaec520e4dd125f3004e456aab5 Cc: "" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 01:06:28 -0000 --bcaec520e4dd125f3004e456aab5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 20, 2013 at 12:40 AM, joel jaeggli wrote: > On 8/18/13 9:27 PM, George Michaelson wrote: > > > > > I am a little worried the document makes unattributed statements about > > ASIC and FPGA costs. I think they need to be fleshed out, because this > > kind of unsubstantiated and unattributed comment can lead to people > > continuing to assume things which applied once, to some vendors, but > > doesn't apply now (consider the whole thing about secure disk wiping > > which was predicated on a very specific generation of HDD hardware. > > Or, the "BGP is dying we need locator+id" debate, which arguably stems > > from a false premise) > > > Actually I think we pretty carefully skirted that in fragdrop, it's > > http://tools.ietf.org/html/draft-wkumari-long-headers-01 > > where there hardware is front and center. > > here it's fast vs slow (potentially no path) / no feasible way to do > reassembly. > > I think a citation at this point in the document would help. Really thats all my point is: If you repeat text inline which says "...is a problem..." then without a backchain to where you explore it fully, it becomes unsubstantiated, and untestable against changes in the h/w horizon. Why skirt it? Not a big deal anyway. I like the document and think its worth publishing. -G --bcaec520e4dd125f3004e456aab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2013 at 12:40 AM, joel jaeggli &l= t;joelja@bogus.com> wrote:
On 8/18/13 9:27 PM, George= Michaelson wrote:

>
> I am a little worried the document makes unattributed statements about=
> ASIC and FPGA costs. I think they need to be fleshed out, because this=
> kind of unsubstantiated and unattributed comment can lead to people > continuing to assume things which applied once, to some vendors, but > doesn't apply now (consider the whole thing about secure disk wipi= ng
> which was predicated on a very specific generation of HDD hardware. > Or, the "BGP is dying we need locator+id" debate, which argu= ably stems
> from a false premise)
>
Actually I think we pretty carefully skirted that in fragdrop, it'= ;s

http://tools.ietf.org/html/draft-wkumari-long-headers-01
where there hardware is front and center.

here it's fast vs slow (potentially no path) / no feasible way to do reassembly.


I think a citation at this point in the docume= nt would help. Really thats all my point is: If you repeat text inline whic= h says "...is a problem..." then without a backchain to where you= explore it fully, it becomes unsubstantiated, and untestable against chang= es in the h/w horizon.=A0

Why skirt it?

Not a big deal a= nyway. I like the document and think its worth publishing.

-G

--bcaec520e4dd125f3004e456aab5-- From Nick.Heatley@ee.co.uk Tue Aug 20 01:50: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 CBA8C11E81FB for ; Tue, 20 Aug 2013 01:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn+E16Kygm8F for ; Tue, 20 Aug 2013 01:50:11 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24711E81FD for ; Tue, 20 Aug 2013 01:50:08 -0700 (PDT) Received: from [85.158.137.67:32199] by server-10.bemta-3.messagelabs.com id E0/1B-30473-DBD23125; Tue, 20 Aug 2013 08:50:05 +0000 X-Env-Sender: Nick.Heatley@ee.co.uk X-Msg-Ref: server-5.tower-139.messagelabs.com!1376988604!30482697!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27970 invoked from network); 20 Aug 2013 08:50:04 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-5.tower-139.messagelabs.com with SMTP; 20 Aug 2013 08:50:04 -0000 Received: from hatmmar01.TMOUSERSUK.AD.T-MOBILE.CO.UK (Not Verified[172.27.190.4]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Tue, 20 Aug 2013 09:56:48 +0100 Received: from hatmsg001.TMOUSERSUK.AD.T-MOBILE.CO.UK (Not Verified[10.243.193.75]) by hatmmar01.TMOUSERSUK.AD.T-MOBILE.CO.UK with MailMarshal (v6, 8, 3, 9481) id ; Tue, 20 Aug 2013 09:50:03 +0100 Received: from HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK ([10.243.197.37]) by hatmsg001.TMOUSERSUK.AD.T-MOBILE.CO.UK with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Aug 2013 09:50:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 20 Aug 2013 09:50:02 +0100 Message-ID: In-Reply-To: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to Informational RFC Thread-Index: Ac6c45Y6p86QiVHMRoO9z7P1ON7d3wAmvCAg References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> From: "Heatley, Nick" To: , , "Byrne, Cameron" , , "Vizdal Ales (TMCZ)" X-OriginalArrivalTime: 20 Aug 2013 08:50:03.0569 (UTC) FILETIME=[42FFC210:01CE9D82] Cc: denghui@chinamobile.com Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Aug 2013 08:50:17 -0000 R2l2ZW4gd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgM0dQUCBJUHY2IFJvYW1pbmcsIEkgd2FzIHRo aW5raW5nIG9mIGFueSBtb2JpbGUgdGVybWluYWwgcmVxdWlyZW1lbnRzIHRoYXQgY29tZSBmcm9t IHJvYW1pbmcuDQpUaGVyZSBzZWVtcyB0byBiZSBubyBzcGVjaWZpY3MgcmVnYXJkaW5nIHJvYW1p bmcgaW4gdGhpcyBwYXBlci4NCg0KT25lIHNvbHV0aW9uIGFwcGVhcnMgdG8gYmUgY29taW5nIGlu dG8gZmF2b3VyIHRvIGZpeCBvbmUgdHlwZSBvZiBvcGVyYXRpb25hbCBkZWZpY2llbmNpZXMgaW4g Y3VycmVudCByb2FtaW5nOiB0aGF0IHRoZSB0ZXJtaW5hbCBjYW4gYmUgY29uZmlndXJlZCB3aXRo IGEgaG9tZSBJUCBwcm9maWxlIGFuZCBhIHJvYW1pbmcgSVAgcHJvZmlsZS4gVGhpcyBpcyBub3Qg c28gbXVjaCBhIGNvbXBsaWFuY2UgcmVxdWlyZW1lbnQsIGFzIHByb3RlY3RpbmcgdGhlIHN1YnNj cmliZXIgYWdhaW5zdCBleGNlcHRpb25zIHdoZW4gcm9hbWluZy4gU2hvdWxkIHRoaXMgYmUgaW5j bHVkZWQgaW4gdGhpcyBwYXBlcj8gT3Igd291bGQgdGhpcyBuZWVkIGZ1cnRoZXIgZGViYXRlIGJl eW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBwYXBlcj8NCldoYXQgYXJlIHlvdXIgdGhvdWdodHM/DQpO aWNrDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ IE9mIFRoZSBJRVNHDQo+IFNlbnQ6IDE5IEF1Z3VzdCAyMDEzIDE0OjUyDQo+IFRvOiBJRVRGLUFu bm91bmNlDQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdjZvcHNdIExhc3QgQ2Fs bDogPGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLQ0KPiAwNC50eHQ+KElu dGVybmV0IFByb3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmlsZSBmb3IgM0dQUA0KPiBNb2Jp bGVEZXZpY2VzKSB0byBJbmZvcm1hdGlvbmFsIFJGQw0KPiANCj4gDQo+IFRoZSBJRVNHIGhhcyBy ZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgSVB2NiBPcGVyYXRpb25zIFdHICh2Nm9wcykgdG8N Cj4gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCj4gLSAnSW50ZXJuZXQgUHJvdG9j b2wgVmVyc2lvbiA2IChJUHY2KSBQcm9maWxlIGZvciAzR1BQIE1vYmlsZSBEZXZpY2VzJw0KPiAg IDxkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0wNC50eHQ+IGFzIEluZm9y bWF0aW9uYWwgUkZDDQo+IA0KPiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4g dGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMNCj4gZmluYWwgY29tbWVudHMgb24gdGhp cyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KPiBpZXRm QGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxMy0wOS0wMi4gRXhjZXB0aW9uYWxseSwgY29t bWVudHMgbWF5DQo+IGJlIHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIg Y2FzZSwgcGxlYXNlIHJldGFpbiB0aGUNCj4gYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUg dG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQo+IA0KPiBBYnN0cmFjdA0KPiANCj4gDQo+ICAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIElQdjYgcHJvZmlsZSBmb3IgM0dQUCBtb2JpbGUg ZGV2aWNlcy4gIEl0DQo+ICAgIGxpc3RzIHRoZSBzZXQgb2YgZmVhdHVyZXMgYSAzR1BQIG1vYmls ZSBkZXZpY2UgaXMgdG8gYmUgY29tcGxpYW50DQo+ICAgIHdpdGggdG8gY29ubmVjdCB0byBhbiBJ UHY2LW9ubHkgb3IgZHVhbC1zdGFjayB3aXJlbGVzcyBuZXR3b3JrDQo+ICAgIChpbmNsdWRpbmcg M0dQUCBjZWxsdWxhciBuZXR3b3JrIGFuZCBJRUVFIDgwMi4xMSBuZXR3b3JrKS4NCj4gDQo+ICAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIGRpZmZlcmVudCBwcm9maWxlIHRoYW4gdGhlIG9uZSBm b3IgZ2VuZXJhbA0KPiAgICBjb25uZWN0aW9uIHRvIElQdjYgY2VsbHVsYXIgbmV0d29ya3MgZGVm aW5lZCBpbg0KPiAgICBbSS1ELmlldGYtdjZvcHMtcmZjMzMxNmJpc10uICBJbiBwYXJ0aWN1bGFy LCB0aGlzIGRvY3VtZW50DQo+IGlkZW50aWZpZXMNCj4gICAgYWxzbyBmZWF0dXJlcyB0byBkZWxp dmVyIElQdjQgY29ubmVjdGl2aXR5IHNlcnZpY2Ugb3ZlciBhbiBJUHY2LW9ubHkNCj4gICAgdHJh bnNwb3J0Lg0KPiANCj4gICAgQm90aCBob3N0cyBhbmQgZGV2aWNlcyB3aXRoIGNhcGFiaWxpdHkg dG8gc2hhcmUgdGhlaXIgV0FOIChXaWRlIEFyZWENCj4gICAgTmV0d29yaykgY29ubmVjdGl2aXR5 IGFyZSBpbiBzY29wZS4NCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5l ZCB2aWENCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3Bz LW1vYmlsZS1kZXZpY2UtcHJvZmlsZS8NCj4gDQo+IElFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJh Y2tlZCB2aWENCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2 b3BzLW1vYmlsZS1kZXZpY2UtDQo+IHByb2ZpbGUvYmFsbG90Lw0KPiANCj4gDQo+IE5vIElQUiBk ZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC4NCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRo aXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhl IGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBm cm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9z ZS4gIA0KIA0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMg aW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8g ZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkg dmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQg dmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0KDQpFdmVyeXRoaW5nIEV2ZXJ5 d2hlcmUgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBS ZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IEhh dGZpZWxkIEJ1c2luZXNzIFBhcmssIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVw0K From lorenzo@google.com Tue Aug 20 02:39: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 612AD11E819B for ; Tue, 20 Aug 2013 02:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=1.299, 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 5ZFVBw4jyeu5 for ; Tue, 20 Aug 2013 02:39:41 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9F11E8128 for ; Tue, 20 Aug 2013 02:39:41 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id l10so251986oag.19 for ; Tue, 20 Aug 2013 02:39:39 -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=DZPCBM3NwRWeXgwzENQOWenrjemQzOMP/GDFuZ+Sn0Y=; b=kS799GDK89wAqG49vcNzm0TOCyP5te6tL5aEEkFIG35UDGraieiNGmFvEP4sg0MWPq 0HKwGI2LC8lslAgfeg5D1GnWkf2evpJYyhOlnBqKF/0qSJSgLCSyH0aGaUf8xE4g4hcf AZNMsqAR6J6M048+IzfBfa9CmrhIrUDe1rPqoVIsdDz3Z/Imiiyr+AiXTRX94dHb+WYh wNskG+86UEB4C0e8VNX1Di0FCjKbTwHzZ4qXJhzszu3cafS1QrO0B1ths+EFyfpjmb6y Kw450SSSmMzT2Base6S44NZERnk0XpymrO2CTUrSatJQwzeluh3PA4vgHdvWK8S6fLcs GG+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DZPCBM3NwRWeXgwzENQOWenrjemQzOMP/GDFuZ+Sn0Y=; b=QY0kTl2r+kEngjjPxyJjNFb2cgjh/8YW+41Jix0NU+KwdUoXUGv84aS92Crc+L3n1d gcL0vnB2IzVf+Pi0PXgI8HD0zw0vUzT8/z6u9N9DQZuBmlqGaJtvSKPXf+9nh1Ukun9b Bn5LW8/zt4Ao6a4Q1etSc6yhQ+W4TxLQJK4/jvmzga9BMD/2+ZAM4SwlKboq1ElYktmf Bw10T1ae1tC4AiVE8YcPjppT/o9zMJqvgL3kqvmy5p2wLrcLIxxGLfMdor4OCtF4UCrS YKys2VGCY0T4Ci1lRWR344ijrJoyEypU291yV9Q2RZoqdkOIP4wvhktvEAoIIkfHxp0M PMRQ== X-Gm-Message-State: ALoCoQmDugNpWrRwEcwZyg/V1wQAzuH/sIUbcaKVK+450BWd6rObnpAJd1qVjsIqdU7VhQGxqYKkNoBf9pilgnlMx+UdpKPbDPy8eKDHvntiZG3psEfCMlYwdDnuKluFLvbSMEFP6pFW+OsfGVdlPk6XIXGmYXcIZWk+dAex7fzxo7P5hctAxMTX6QoBrUt2YTcJhMieKHQp X-Received: by 10.50.130.65 with SMTP id oc1mr4412691igb.49.1376991579484; Tue, 20 Aug 2013 02:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.221.132 with HTTP; Tue, 20 Aug 2013 02:39:18 -0700 (PDT) In-Reply-To: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Tue, 20 Aug 2013 18:39:18 +0900 Message-ID: To: IETF Discussion Content-Type: multipart/alternative; boundary=047d7b2e153bf470f504e45dd536 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Aug 2013 09:39:41 -0000 --047d7b2e153bf470f504e45dd536 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 19, 2013 at 10:52 PM, The IESG wrote: > 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). > I object to this document on the grounds that it is little more than a list of (34!) features with little technical justification. I see this as a problem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify which features or protocols should or should not be implemented in hosts. Even the hosts requirements RFCs are careful and sparing in their language. The IETF is certainly not in the business of rubberstamping feature wishlists without good technical reasons. I would challenge the authors to find a precedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necessary to build a mobile device that works well over IPv6. Today, the overwhelming majority of mobile device traffic comes from devices that implement only a handful of these requirements. More specifically, requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applications running on the device - yes, all of them), and #34, are not necessary to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would challenge the authors to find a single product today that implements all, or even a substantial majority, of these requirements. It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. 4. The document has few technical contributions of its own. Most of the requirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what seems like all the features that the IETF has ever developed, and then saying that they all need to be implemented, is not the way to get there. The way to do it is to document use cases and working scenarios gleaned from operational experience. Regards, Lorenzo --047d7b2e153bf470f504e45dd536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19, 2013 at 10:52 PM, The IESG <iesg-se= cretary@ietf.org> wrote:
=A0 =A0This document specifies an IPv6 profile for 3GPP mo= bile devices. =A0It
=A0 =A0lists the set of features a 3GPP mobile device is to be compliant =A0 =A0with to connect to an IPv6-only or dual-stack wireless network
=A0 =A0(including 3GPP cellular network and IEEE 802.11 network).
=A0
I object to this document on the grounds that it = is little more than a list of (34!) features with little technical justific= ation. I see this as a problem because:

1. It is out of the IETF's mandate. It is not the I= ETF's job to specify which features or protocols should or should not b= e implemented in hosts. Even the hosts requirements RFCs are careful and sp= aring in their language. The IETF is certainly not in the business of rubbe= rstamping feature wishlists without good technical reasons. I would challen= ge the authors to find a precedent RFC containing such broad requirements.<= /div>

2. It is over-broad. The vast majority of the features = are in no way necessary to build a mobile device that works well over IPv6.= Today, the overwhelming majority of mobile device traffic comes from devic= es that implement only a handful of these requirements. More specifically, = requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20,= #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (whic= h cover all applications running on the device - yes, all of them), and #34= , are not necessary to connect to IPv6 mobile networks.

3. It is so daunting as to act as a deterrent to IPv6 d= eployment. I would challenge the authors to find a single product today tha= t implements all, or even a substantial majority, of these requirements. It= seems to me that the sheer length of the list, and the fact that is not pr= ioritized, create a real risk that implementors will simply write it off as= wishful thinking or even=A0shy away in terror.

4. The document has few technical contributions o= f its own. Most of the requirements are simply listed one after another.

I'm all for IPv6 deployment in mobile networks, = but making a list of what seems like all the features that the IETF has eve= r developed, and then saying that they all need to be implemented, is not t= he way to get there. The way to do it is to document use cases and working = scenarios gleaned from operational experience.

Regards,
Lorenzo
--047d7b2e153bf470f504e45dd536-- From david.binet@orange.com Tue Aug 20 05:53: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 E308A11E80D5 for ; Tue, 20 Aug 2013 05:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXl2A8RaYDqf for ; Tue, 20 Aug 2013 05:53:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7E11E80D3 for ; Tue, 20 Aug 2013 05:53:13 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 5F2C22DCD17; Tue, 20 Aug 2013 14:53:12 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3A6B727C05B; Tue, 20 Aug 2013 14:53:12 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 20 Aug 2013 14:53:12 +0200 From: To: "Heatley, Nick" , "v6ops@ietf.org" , "Byrne, Cameron" , "phdgang@gmail.com" , "Vizdal Ales (TMCZ)" Date: Tue, 20 Aug 2013 14:53:11 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to Informational RFC Thread-Index: Ac6c45Y6p86QiVHMRoO9z7P1ON7d3wAmvCAgAAkMfuA= Message-ID: <25402_1377003192_521366B8_25402_66_1_1B2E7539FECD9048B261B791B1B24A7C5119A03DF0@PUEXCB1A.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418 Cc: "denghui@chinamobile.com" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Aug 2013 12:53:18 -0000 Hi Nick, A new version of the draft will be edited at least taking into account comm= ents received during this last call process.=20 A requirement to guarantee that the device has some IP connectivity in roam= ing context, like the one you mention, is likely to be integrated in this u= pcoming version even if the discussions about roaming will continue and wil= l go beyond device capabilities.=20=20 David > -----Message d'origine----- > De : Heatley, Nick [mailto:Nick.Heatley@ee.co.uk]=20 > Envoy=E9 : mardi 20 ao=FBt 2013 10:50 > =C0 : v6ops@ietf.org; BINET David IMT/OLN; Byrne, Cameron;=20 > phdgang@gmail.com; Vizdal Ales (TMCZ) > Cc : denghui@chinamobile.com > Objet : RE: [v6ops] Last Call:=20 > (Internet=20 > Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to=20 > Informational RFC >=20 > Given we have been discussing 3GPP IPv6 Roaming, I was=20 > thinking of any mobile terminal requirements that come from roaming. > There seems to be no specifics regarding roaming in this paper. >=20 > One solution appears to be coming into favour to fix one type=20 > of operational deficiencies in current roaming: that the=20 > terminal can be configured with a home IP profile and a=20 > roaming IP profile. This is not so much a compliance=20 > requirement, as protecting the subscriber against exceptions=20 > when roaming. Should this be included in this paper? Or would=20 > this need further debate beyond the scope of this paper? > What are your thoughts? > Nick >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf=20 > > Of The IESG > > Sent: 19 August 2013 14:52 > > To: IETF-Announce > > Cc: v6ops@ietf.org > > Subject: [v6ops] Last Call: > 04.txt>(Internet Protocol Version 6 (IPv6) Profile for 3GPP > > MobileDevices) to Informational RFC > >=20 > >=20 > > The IESG has received a request from the IPv6 Operations WG=20 > (v6ops) to=20 > > consider the following document: > > - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP=20 > Mobile Devices' > > as=20 > Informational RFC > >=20 > > The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > final comments on this action. Please send substantive=20 > comments to the=20 > > ietf@ietf.org mailing lists by 2013-09-02. Exceptionally,=20 > comments may=20 > > be sent to iesg@ietf.org instead. In either case, please retain the=20 > > beginning of the Subject line to allow automated sorting. > >=20 > > Abstract > >=20 > >=20 > > This document specifies an IPv6 profile for 3GPP mobile=20 > 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). > >=20 > > This document defines a different profile than the one=20 > for general > > connection to IPv6 cellular networks defined in > > [I-D.ietf-v6ops-rfc3316bis]. In particular, this document=20 > > identifies > > also features to deliver IPv4 connectivity service over=20 > an IPv6-only > > transport. > >=20 > > Both hosts and devices with capability to share their=20 > WAN (Wide Area > > Network) connectivity are in scope. > >=20 > >=20 > >=20 > >=20 > > The file can be obtained via > >=20 > http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > > / > >=20 > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device- > > profile/ballot/ > >=20 > >=20 > > No IPR declarations have been submitted directly on this I-D. > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jhw@apple.com Tue Aug 20 16: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 EB55111E8141; Tue, 20 Aug 2013 16:58:33 -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 TKVmdglMowfd; Tue, 20 Aug 2013 16:58:27 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 613A611E8134; Tue, 20 Aug 2013 16:58:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MRU0026XT9AVTQ0@mail-out.apple.com>; Tue, 20 Aug 2013 16:58:23 -0700 (PDT) X-AuditID: 1180715a-b7f8e6d000006c98-a8-5214029ea4c9 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 7F.A5.27800.F9204125; Tue, 20 Aug 2013 16:58:23 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MRU007VPT9ACN00@aniseed.apple.com>; Tue, 20 Aug 2013 16:58:22 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 20 Aug 2013 16:58:22 -0700 Message-id: References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> To: v6ops@ietf.org, WG X-Mailer: Apple Mail (2.1793.4) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUi2FAsrjufSSTI4Mh6NotnG+ezWJw+tpfZ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZb5f8YixYz1Jx/0ArawPjDuYuRk4OCQETiV9HG1kg bDGJC/fWs3UxcnEICfQzSTx8PZEJwmllkmg++IIdpIpZQEei9/s3oG4ODl4BA4nPDT4gNcIC axklXuzZyQRSwyagIvHt8l0wm1MgWGLCgXesIDaLgKrEuY0z2SDmKEu8OfOfCcLWlnjy7gJY Da+AjcSltfPZIRa3M0rc7zoA1iAioC6x+spRRohT5SXafv9km8AoMAvJTbMQbpqFZOwCRuZV jAJFqTmJlWZ6iQUFOal6yfm5mxjBQVgYtYOxYbnVIUYBDkYlHl7OEuEgIdbEsuLK3EOMEhzM SiK8O74ChXhTEiurUovy44tKc1KLDzFKc7AoifPu1QBKCaQnlqRmp6YWpBbBZJk4OKUaGFPu CW8KFfHd2Liv6J7s3VBvnWJG4wmzX7Q8rL6hWnHrqWqLTt3+XYsvnor6sPKHwJ7byqu3XQvd xBHrsOlCk/j/VY+4o9TX9aTqrvOU+fqJYUKXqVTDpuvmQtP9fh5x/pT0JOtzrcfk01MmrGEW 3vIv30T2QcEh3sMqGdvyrNLETgZq7PRq0VBiKc5INNRiLipOBABmCbu0PgIAAA== Cc: IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Aug 2013 23:58:34 -0000 On Aug 20, 2013, at 02:39 , Lorenzo Colitti wrote: > > [...] It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. [...] My views on the technical merits of this draft remain unchanged from the last time I offered them here, and I am basically in agreement with Lorenzo. This draft seems unnecessary to me. -- james woodyatt core os networking From owen@delong.com Tue Aug 20 17:16: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 3A7F511E815B; Tue, 20 Aug 2013 17:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.316, 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 D-Hw+dWrKRNc; Tue, 20 Aug 2013 17:16: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 2DA8911E8338; Tue, 20 Aug 2013 17:15:58 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7L0Dlnd025614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Aug 2013 17:13:48 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7L0Dlnd025614 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1377044028; bh=0X8dCqygwxFcYjpjKbFRr1j2WKI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Jqua9WepWcWH5E9dLUQPUH5ERShnvhESJOP8h3Tuj0Z16BM886+G0qXs6qR0bDZ0r B45B5Op+V8mviTNPE1HuP8E2eYw0X/eJg709PRUwmDrezWPg5M1y1Ua0Sv5rN/WNyM QNrKrtFfI61ywtxZrTHzKu7Dfd1c/qSbiW2TYpfk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: Date: Tue, 20 Aug 2013 17:13:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> To: james woodyatt 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]); Tue, 20 Aug 2013 17:13:48 -0700 (PDT) Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Aug 2013 00:16:10 -0000 I also agree with James and Lorenzo. Owen On Aug 20, 2013, at 4:58 PM, james woodyatt wrote: > On Aug 20, 2013, at 02:39 , Lorenzo Colitti = wrote: >>=20 >> [...] It seems to me that the sheer length of the list, and the fact = that is not prioritized, create a real risk that implementors will = simply write it off as wishful thinking or even shy away in terror. = [...] >=20 > My views on the technical merits of this draft remain unchanged from = the last time I offered them here, and I am basically in agreement with = Lorenzo. This draft seems unnecessary to me. >=20 >=20 > -- > james woodyatt > core os networking >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wesley.george@twcable.com Wed Aug 21 06:19: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 DDCA411E8394 for ; Wed, 21 Aug 2013 06:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTDKU9HhLW9g for ; Wed, 21 Aug 2013 06:19:39 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id B310311E8216 for ; Wed, 21 Aug 2013 06:19:39 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,928,1367985600"; d="scan'208";a="39722564" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Aug 2013 09:19:16 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 21 Aug 2013 09:19:26 -0400 From: "George, Wes" To: "v6ops@ietf.org" Date: Wed, 21 Aug 2013 09:19:24 -0400 Thread-Topic: [v6ops] draft-taylor-v6ops-fragdrop WGLC Thread-Index: Ac6cPNF8WBwh7jCZRlKM8NhFHsEMtwCLWfKg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A39@PRVPEXVS15.corp.twcable.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> In-Reply-To: <201308181800.r7II06mv003294@irp-view13.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 Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 13:19:45 -0000 As to whether this is ready for IETF LC or should be adopted by the WG, no = it's not ready, and I don't know if it should be adopted. Specifically, I t= hink that guidance for implementers about use of fragments is useful, espec= ially in documenting current behavior on the network and the justifications= for it. However, we're starting to get a lot of overlap between the drafts= dealing with fragmentation, whether it should be deprecated, whether we sh= ould simply provide a caveat implementer statement on using fragments but l= eave the standard alone, etc. It makes matters worse when one considers fra= gmented packets together with large headers, since at least some of the tec= hnical considerations overlap. To avoid confusion, I think we need to decid= e which direction we want to go before advancing drafts on the matter. If i= ndeed we want implementers to read and heed the advice in this draft (or ot= her related drafts), we should make sure we have a cohesive message. Right = now we have justifications and operational observations spread across at le= ast this draft and draft-bonica-6man-frag-deprecate (which I'd argue discus= ses the operational considerations much more robustly than this document), = and possibly even draft-generic-6man-tunfrag. Some specific comments on the draft, if indeed I'm in the minority and this= advances: General grammar pedantry nit - there's a good bit of passive voice in this = draft, most of which could be eliminated through rewording. Intro: "The filtering of IPv6 datagrams with fragmentation headers is presumed to be a non-issue in the core of the Internet, where fragments are routed just like any other IPv6 datagram. here fragments are routed just like any other IPv6 datagram. However, fragmentation can creates operational issues at the edges of the Internet" This is unclear. Use fewer words. I think what you're trying to say is that= "the core doesn't commonly filter fragments, but the edge does, and that c= reates operational issues". 2.1 - as others have said, the last sentence needs to be explained. This is= probably the place to add a reference to one or more of the drafts I menti= oned above rather than rehash it. (assuming that you don't end up incorpora= ting much of draft-bonica section 2 into this draft, such that draft-bonica= can simply recommend deprecation of fragmentation using this draft as a fo= undation) 2.1.3 - if this document wishes to remain neutral, I'd recommend that you d= rop the transition/intro text "Leaving aside these incentives towards fragm= ent dropping". It's not really adding anything, and "these incentives" is s= omewhat unclear anyway. 2.1.4 - control plane ACLs only affect traffic destined *to* the router, no= t through it. It would be better to make that clearer. "drop all fragments"= is misleading as currently written. 2.2 - folks have raised this point in discussion of the other fragmentation= drafts, but there are also legitimate uses for fragmentation when dealing = with data links that cannot support IPv6's minimum MTU of 1280. Some data l= inks will do their own fragmentation to compensate, others expect the IP la= yer to do it. A reference to RFC 6980 might also be useful, though I'm not certain where = it would best fit. Thanks, Wes George Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Wed Aug 21 06:33: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 4773F11E8395 for ; Wed, 21 Aug 2013 06:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.569 X-Spam-Level: X-Spam-Status: No, score=0.569 tagged_above=-999 required=5 tests=[AWL=-1.432, BAYES_00=-2.599, FRT_LOLITA1=1.865, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 KZUnIX6ZhzOI for ; Wed, 21 Aug 2013 06:33:16 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75711E839B for ; Wed, 21 Aug 2013 06:33:13 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,928,1367985600"; d="scan'208";a="39728709" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Aug 2013 09:33:02 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 21 Aug 2013 09:33:12 -0400 From: "George, Wes" To: Owen DeLong , "Fred Baker (fred)" Date: Wed, 21 Aug 2013 09:33:11 -0400 Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: Ac6dBW4nSqk2FJNWQTKtkJF/xKnVrwBa/6Wg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A74@PRVPEXVS15.corp.twcable.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alejandro Acosta , "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 13:33:20 -0000 The main problem with extending 2001:db8::/32 to a /29, or allocating 2xxx:= db8::/xx is that it requires everyone to make changes to their Martian rout= ing and packet filters, unlike pulling something from outside of 2000::/3. = I don't view that as "less expensive", at least operationally. Also, if we're talking about your heartburn with a fairly large requested p= refix (e.g. a /20 or /27 or whatever), that lends support to the idea of re= using space that otherwise is likely to become the IPv6 version of IPv4 Cla= ss E space (e.g. 6bone space, or 0200::) - formerly reserved, now reclaimab= le, but unusable as "normal" space on account of currently existing filters= (and probably some dumb implementation hardcoding of "invalid" space). Thanks, Wes > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Owen DeLong > Sent: Monday, August 19, 2013 1:52 PM > To: Fred Baker (fred) > Cc: Alejandro Acosta; 6man-chairs@tools.ietf.org; v6ops@ietf.org WG > Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 > > I think all of Fred's recommendations below are spot on. I support the > changes and I like the idea of 2001:db0::/28. > > In such a case, should we stick with fc00:db8::/44 or should we consider > fc00:db0::/28 for parity? I'm OK either way, just looking to minimize > potential confusion and wondering if the tradeoff in space is worth > while or not. What do others think? > > Owen > > On Aug 19, 2013, at 10:38 , "Fred Baker (fred)" wrote: > > > > > On Aug 19, 2013, at 5:34 AM, Gert Doering wrote: > > > >> 2001:db8 came from APNIC, that's why :-) - their delegated file lists > >> > >> apnic|AU|ipv6|2001:db0::|32|20031112|allocated > >> apnic|AU|ipv6|2001:dc0::|32|20030124|assigned > >> > >> so an extention to /29 would technically be possible, to a /28 won't. > > > > Hmm. Tell me about 2001:da0:: and 2001:d80::? Per > ftp://ftp.apnic.net/public/stats/apnic/delegated-apnic-ipv6-assigned- > latest > > > >> apnic|AU|ipv6|2001:7fa:b::|48|20050922 > >> apnic|AU|ipv6|2001:7fa:c::|48|20050922 > >> apnic|AU|ipv6|2001:7fa:d::|48|20050922 > >> apnic|AU|ipv6|2001:7fa:e::|48|20050922 > >> apnic|ID|ipv6|2001:7fa:f::|48|20050929 > >> apnic|CN|ipv6|2001:7fa:10::|48|20060531 > >> apnic|AU|ipv6|2001:7fa:11::|48|20061031 > >> apnic|AU|ipv6|2001:dc0::|32|20030124 > >> apnic|TW|ipv6|2001:dc1::|32|20030331 > >> apnic|JP|ipv6|2001:dc2::|32|20030529 > >> apnic|JP|ipv6|2001:dc3::|32|20030619 > > > > > > To my small mind, that suggests 2001:d80::/26 (64 prefixes), > 2001:da0::/27 (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter > than /26 includes 2001:dc0:: and 2001:de0::, which have been allocated. > The neighborhood, however, includes 2001:db8::, which we already use. I, > for one, would like to see one documentation range, at least for the > global unicast address space, which is to say a prefix shorter than and > including 2001:db8::/32. > > > > http://www.apnic.net/publications/research-and-insights/ip-address- > trends/apnic-resource-range#IPv6Allocation notes that 2001:DB8::/29 is > reserved and by definition available. > > > > I note that we are not discussing the recommendation per se; we are > narrowing in on the length of the prefix. Unless someone disagrees, I > think we have pretty much agreed that something shorter than /32 makes > sense. > > > > Here's my suggestion. The 6man chairs tell me that RFC 3489 was their > work group product, so it's replacement should be. I'd suggest > respinning the draft as draft-moreiras-6man-rfc3849bis (and tell > internet-drafts@ietf.org that it replaces this one). You want to do two > separate things: > > > > a) argue for a shorter prefix in 2000::/3, and make a separate-but- > analogous argument for a prefix in fc00::/8. > > In those, focus on need, not want. "We designed a lab that has 2^128 > different addresses in it, we obviously need the entire IPv6 address > space" doesn't follow. Say what you *need* and why you *need* it. While > the request was for a /20, I have not heard a cogent argument for a /26 > or shorter, I heard that there was a training lab somewhere that > required a /27 (32 /32s) but have not heard that the intent of the lab > could not have been done with 16 /32s, and observe that a nibble > boundary would suggest a /28 (16 /32s). > > > > b) in the IANA considerations section, note: > > b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28, > or 2001:db8::/29 > > b.2) the suggestion of fc00:db8:?::/44, which I think we more or less > agreed to in the thread > > b.3) the fact that this would also affect > http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6- > special-registry.xhtml#iana-ipv6-special-registry-1 > > _______________________________________________ > > 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 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Wed Aug 21 09:35: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 8B5CB11E825B for ; Wed, 21 Aug 2013 09:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.249 X-Spam-Level: X-Spam-Status: No, score=-109.249 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, FRT_LOLITA1=1.865, 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 AvcVRZcRYl+s for ; Wed, 21 Aug 2013 09:35:15 -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 F3D4E11E8250 for ; Wed, 21 Aug 2013 09:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8112; q=dns/txt; s=iport; t=1377102915; x=1378312515; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bnn+1/nwtCczDtUYClNYMAicGYCtvwl6aGifwJiydoQ=; b=cEgNQj0skbWoBk5kTsoBapIxwiTHmke5K60Cw2nPmY4XW3T6AYJQpoE7 xiYG/BD6OXj47POgjsGfruDPFl79sPwyK3Pndgjr3AA4GYi0nNP9/Eaf7 zGf2KC4iBKiv68bsGVJaFWQLHTaAGHgJui2Sk2H0IXVTn/67xPTRJ2eaw k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIzrFFKtJXG//2dsb2JhbABagwU1Ub9kgR8WdIIkAQEBAwEBAQFrBAcFBwQCAQgRAQMBAQEKCxIHJwsUAwYIAgQOBQgBBQ6HbgYMrXmPHIEILAUHBgSDEXkDkBSBLpd4gx2Bcjk X-IronPort-AV: E=Sophos;i="4.89,929,1367971200"; d="asc'?scan'208";a="250071278" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 21 Aug 2013 16:35:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7LGZCev028439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Aug 2013 16:35:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.28]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 11:35:12 -0500 From: "Fred Baker (fred)" To: "George, Wes" Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: AQHOnoxnJQHdXvZNRkyDsJ3Wlb23ag== Date: Wed, 21 Aug 2013 16:35:11 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9AE1B1@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A74@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A74@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_22CD4DC3-4F26-41B7-AE04-CF3396348765"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Alejandro Acosta , "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 16:35:20 -0000 --Apple-Mail=_22CD4DC3-4F26-41B7-AE04-CF3396348765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 21, 2013, at 6:33 AM, "George, Wes" wrote: > The main problem with extending 2001:db8::/32 to a /29, or allocating = 2xxx:db8::/xx is that it requires everyone to make changes to their = Martian routing and packet filters, unlike pulling something from = outside of 2000::/3. I don't view that as "less expensive", at least = operationally. > Also, if we're talking about your heartburn with a fairly large = requested prefix (e.g. a /20 or /27 or whatever), that lends support to = the idea of reusing space that otherwise is likely to become the IPv6 = version of IPv4 Class E space (e.g. 6bone space, or 0200::) - formerly = reserved, now reclaimable, but unusable as "normal" space on account of = currently existing filters (and probably some dumb implementation = hardcoding of "invalid" space). Well, that is how we came up with 10.0.0.0/8; that was the ARPANET's = allocation. He could include that in the IANA section of the 6man draft = as another alternative, and come to that conclusion in 6man. Understand my heartburn, please. To my mind, there are two arguments for = IPv6 deployment: more addresses, and operational simplicity. When Axel = Clauberg talks about his Terastream architecture, he shows an = interesting slide in which he identifies the set of technologies in use = in his network and which he has to manage, and he observes that there is = nothing in it that can't be replaced by one of four protocol = technologies - IPv6, optical communications, a management architecture = (for which he selects NetConf), and an overlay architecture (for which = he selects L2TPv3/IPv6). He figures he is saving operational expense by = converting his network to exactly that set of technologies. When I talk = about heartburn, I'm talking about things that chew up address space = unnecessarily (the difference between "need" and "want") or which add = complexity - of which the random filters you comment on are an example. > Thanks, >=20 > Wes >=20 >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Owen DeLong >> Sent: Monday, August 19, 2013 1:52 PM >> To: Fred Baker (fred) >> Cc: Alejandro Acosta; 6man-chairs@tools.ietf.org; v6ops@ietf.org WG >> Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 >>=20 >> I think all of Fred's recommendations below are spot on. I support = the >> changes and I like the idea of 2001:db0::/28. >>=20 >> In such a case, should we stick with fc00:db8::/44 or should we = consider >> fc00:db0::/28 for parity? I'm OK either way, just looking to minimize >> potential confusion and wondering if the tradeoff in space is worth >> while or not. What do others think? >>=20 >> Owen >>=20 >> On Aug 19, 2013, at 10:38 , "Fred Baker (fred)" = wrote: >>=20 >>>=20 >>> On Aug 19, 2013, at 5:34 AM, Gert Doering wrote: >>>=20 >>>> 2001:db8 came from APNIC, that's why :-) - their delegated file = lists >>>>=20 >>>> apnic|AU|ipv6|2001:db0::|32|20031112|allocated >>>> apnic|AU|ipv6|2001:dc0::|32|20030124|assigned >>>>=20 >>>> so an extention to /29 would technically be possible, to a /28 = won't. >>>=20 >>> Hmm. Tell me about 2001:da0:: and 2001:d80::? Per >> ftp://ftp.apnic.net/public/stats/apnic/delegated-apnic-ipv6-assigned- >> latest >>>=20 >>>> apnic|AU|ipv6|2001:7fa:b::|48|20050922 >>>> apnic|AU|ipv6|2001:7fa:c::|48|20050922 >>>> apnic|AU|ipv6|2001:7fa:d::|48|20050922 >>>> apnic|AU|ipv6|2001:7fa:e::|48|20050922 >>>> apnic|ID|ipv6|2001:7fa:f::|48|20050929 >>>> apnic|CN|ipv6|2001:7fa:10::|48|20060531 >>>> apnic|AU|ipv6|2001:7fa:11::|48|20061031 >>>> apnic|AU|ipv6|2001:dc0::|32|20030124 >>>> apnic|TW|ipv6|2001:dc1::|32|20030331 >>>> apnic|JP|ipv6|2001:dc2::|32|20030529 >>>> apnic|JP|ipv6|2001:dc3::|32|20030619 >>>=20 >>>=20 >>> To my small mind, that suggests 2001:d80::/26 (64 prefixes), >> 2001:da0::/27 (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter >> than /26 includes 2001:dc0:: and 2001:de0::, which have been = allocated. >> The neighborhood, however, includes 2001:db8::, which we already use. = I, >> for one, would like to see one documentation range, at least for the >> global unicast address space, which is to say a prefix shorter than = and >> including 2001:db8::/32. >>>=20 >>> http://www.apnic.net/publications/research-and-insights/ip-address- >> trends/apnic-resource-range#IPv6Allocation notes that 2001:DB8::/29 = is >> reserved and by definition available. >>>=20 >>> I note that we are not discussing the recommendation per se; we are >> narrowing in on the length of the prefix. Unless someone disagrees, I >> think we have pretty much agreed that something shorter than /32 = makes >> sense. >>>=20 >>> Here's my suggestion. The 6man chairs tell me that RFC 3489 was = their >> work group product, so it's replacement should be. I'd suggest >> respinning the draft as draft-moreiras-6man-rfc3849bis (and tell >> internet-drafts@ietf.org that it replaces this one). You want to do = two >> separate things: >>>=20 >>> a) argue for a shorter prefix in 2000::/3, and make a separate-but- >> analogous argument for a prefix in fc00::/8. >>> In those, focus on need, not want. "We designed a lab that has 2^128 >> different addresses in it, we obviously need the entire IPv6 address >> space" doesn't follow. Say what you *need* and why you *need* it. = While >> the request was for a /20, I have not heard a cogent argument for a = /26 >> or shorter, I heard that there was a training lab somewhere that >> required a /27 (32 /32s) but have not heard that the intent of the = lab >> could not have been done with 16 /32s, and observe that a nibble >> boundary would suggest a /28 (16 /32s). >>>=20 >>> b) in the IANA considerations section, note: >>> b.1) the availability of 2001:d80::/26, 2001:da0::/27, = 2001:db0::/28, >> or 2001:db8::/29 >>> b.2) the suggestion of fc00:db8:?::/44, which I think we more or = less >> agreed to in the thread >>> b.3) the fact that this would also affect >> http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6- >> special-registry.xhtml#iana-ipv6-special-registry-1 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. =95 Make things as simple as possible, but not simpler. Albert Einstein --Apple-Mail=_22CD4DC3-4F26-41B7-AE04-CF3396348765 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSFOw/bjEdbHIsm0MRAufDAJ9q0PfnPXFzKfGAw5hueJA1k8FXfACglshO VLIOFMjm+HDDDC4OBs4GnYk= =ZWZE -----END PGP SIGNATURE----- --Apple-Mail=_22CD4DC3-4F26-41B7-AE04-CF3396348765-- From tperrine@scea.com Wed Aug 21 10:19: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 94BF611E8268 for ; Wed, 21 Aug 2013 10:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DEKzdyD4qsU for ; Wed, 21 Aug 2013 10:19:44 -0700 (PDT) Received: from ironport03a.scea.com (ironport03a.scea.com [160.33.44.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4A411E8395 for ; Wed, 21 Aug 2013 10:19:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,929,1367996400"; d="scan'208";a="1226260" Received: from inbetweener02.scea.com ([160.33.45.196]) by ironport03a.scea.com with ESMTP; 21 Aug 2013 10:19:40 -0700 Received: from sd-tperrine-mpl.local (unknown [10.56.0.12]) by inbetweener02.scea.com (Postfix) with ESMTP id BDD10B835A for ; Wed, 21 Aug 2013 10:19:40 -0700 (PDT) Message-ID: <5214F6AC.8070105@scea.com> Date: Wed, 21 Aug 2013 10:19:40 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <3374_1375690984_51FF60E8_3374_427_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C5041E1E5@PUEXCB1C.nanterre.francetelecom.fr> <8C48B86A895913448548E6D15DA7553B96E2C5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B96EAE7@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E113128FA2@xmb-aln-x02.cisco.com> <520945FF.4000700@gmail.com> In-Reply-To: <520945FF.4000700@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:19:49 -0000 On 8/12/13 1:30 PM, Brian E Carpenter wrote: > On 12/08/2013 17:27, Arie Vayner (avayner) wrote: >> Owen, >> >> While the arguments about moving the firewalls closer to the users are valid they are often are not practical (or at least the customers I worked with would not implement this option). >> Imagine an enterprise network with 300 spoke sites, but only 2 or 3 Internet gateway locations (with some private WAN in between). >> Moving the firewalls to the spoke sites would increase the number of firewalls from ~3 to ~300 (I am ignoring redundancy and scale for a second)... This is a major CAPEX and OPEX impact... > > Clearly DOS and scanning protection has to be done as close to the Internet > border routers as possible, and there your logic applies. > > However, as Steve Bellovin pointed out many years ago, the best number of > firewalls for upper layer protection is one per host, which scales nicely > and has less CAPEX and OPEX than middlebox firewalls will ever have. SDSC.EDU ran a major HPC center without border firewalls for the 10 years I was there (1993-2003), and still does. "Firewalls are for things too stupid to protect themselves" was the design principle I put in place then, and it can still be valid today, if you have very good host management. You can manage all of those on-host firewalls as a single large virtual firewall, whether it is Puppet/cfengine + iptables, or your Windows host management tool of choice. None of this is IPv6-specific, it just seems that people want to use "OMG firewalls!!!!!" as a reason to avoid moving to IPv6. Same arguments, different advancement they are trying to avoid, different decade. From aservin@lacnic.net Wed Aug 21 10:35: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 68B1B11E826F for ; Wed, 21 Aug 2013 10:35:47 -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 1WkUjJ-17Ob7 for ; Wed, 21 Aug 2013 10:35:46 -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 73C5E11E83DD for ; Wed, 21 Aug 2013 10:35:46 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:d06a:9ea1:cd0a:5769]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7E13A30849A for ; Wed, 21 Aug 2013 14:35:19 -0300 (UYT) Message-ID: <5214FA74.5030607@lacnic.net> Date: Wed, 21 Aug 2013 14:35:48 -0300 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A74@PRVPEXVS15.corp.twcable.com> <8C48B86A895913448548E6D15DA7553B9AE1B1@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9AE1B1@xmb-rcd-x09.cisco.com> X-Enigmail-Version: 1.5.2 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] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:35:48 -0000 On 8/21/13 1:35 PM, Fred Baker (fred) wrote: > > > On Aug 21, 2013, at 6:33 AM, "George, Wes" > wrote: > >> The main problem with extending 2001:db8::/32 to a /29, or >> allocating 2xxx:db8::/xx is that it requires everyone to make >> changes to their Martian routing and packet filters, unlike >> pulling something from outside of 2000::/3. I don't view that as >> "less expensive", at least operationally. > > >> Also, if we're talking about your heartburn with a fairly large >> requested prefix (e.g. a /20 or /27 or whatever), that lends >> support to the idea of reusing space that otherwise is likely to >> become the IPv6 version of IPv4 Class E space (e.g. 6bone space, >> or 0200::) - formerly reserved, now reclaimable, but unusable as >> "normal" space on account of currently existing filters (and >> probably some dumb implementation hardcoding of "invalid" >> space). > > Well, that is how we came up with 10.0.0.0/8; that was the > ARPANET's allocation. He could include that in the IANA section of > the 6man draft as another alternative, and come to that conclusion > in 6man. > I couldn't find the reference in RFC1918, Is it documented somewhere else (besides ietf-mailing lists dicussions)? Regards, as From fred@cisco.com Wed Aug 21 14:45:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D56211E8249 for ; Wed, 21 Aug 2013 14:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 itjWVqnUv9+q for ; Wed, 21 Aug 2013 14:45:18 -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 979D211E81C7 for ; Wed, 21 Aug 2013 14:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=927; q=dns/txt; s=iport; t=1377121518; x=1378331118; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HMJbPvl+QrPr8ZvD3Jl8urRCev0xipjw9Se/BPT3Fm4=; b=TYb1uqjbg9+DfrRv6vIf9M8OFLgJgbF5hFVBbd+PytQsc7yJooUlkPGB RrcvixVCO6zaEq4pU7J3q89Hu9CNxKbLf012MKLZ63OkC/pnloRUPX/E8 RRqR6XnjQ0sKMXD0OhqBQwVWL0zJikKe9zjI7gLSl3GoWoicwMzzMtr/i M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAO8zFVKtJXG+/2dsb2JhbABagwU1UYJTvRGBHxZ0giQBAQEDAW4LBQsCAQgOFCQyJQIEDgUIBod8BgyuE5AkMQeDG3kDkBSBLodOkCqDHYIr X-IronPort-AV: E=Sophos;i="4.89,930,1367971200"; d="asc'?scan'208";a="250183114" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 21 Aug 2013 21:45:17 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7LLjHEO019173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Aug 2013 21:45:17 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.28]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 16:45:17 -0500 From: "Fred Baker (fred)" To: Arturo Servin Thread-Topic: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 Thread-Index: AQHOnre5+AdUWVe9d0ma7ksR5mjgvw== Date: Wed, 21 Aug 2013 21:45:16 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9AED6B@xmb-rcd-x09.cisco.com> References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A74@PRVPEXVS15.corp.twcable.com> <8C48B86A895913448548E6D15DA7553B9AE1B1@xmb-rcd-x09.cisco.com> <5214FA74.5030607@lacnic.net> In-Reply-To: <5214FA74.5030607@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_7AE48B41-0739-424A-ADEA-CB370AFC9E0F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 21:45:24 -0000 --Apple-Mail=_7AE48B41-0739-424A-ADEA-CB370AFC9E0F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Aug 21, 2013, at 10:35 AM, Arturo Servin wrote: > I couldn't find the reference in RFC1918, Is it documented somewhere > else (besides ietf-mailing lists dicussions)? RFC 810 (http://tools.ietf.org/html/rfc810), assumption 5. --Apple-Mail=_7AE48B41-0739-424A-ADEA-CB370AFC9E0F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSFTTsbjEdbHIsm0MRAp7FAJ4lhtuUU5KakYMbiSjv0CSpzaQXuQCghXrV RfNGfKqgZh8pvrOzvCM7O7A= =Zijb -----END PGP SIGNATURE----- --Apple-Mail=_7AE48B41-0739-424A-ADEA-CB370AFC9E0F-- From ek@google.com Thu Aug 22 04:22:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EE211E81B0 for ; Thu, 22 Aug 2013 04:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9YHIlf31AqT for ; Thu, 22 Aug 2013 04:22:04 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5468311E817F for ; Thu, 22 Aug 2013 04:22:03 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so3324947obc.31 for ; Thu, 22 Aug 2013 04:22: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=bvc1TOFiJ2nJx4hEUrNwPJxXXfm1lVnMtoMnldBnr90=; b=GGRupLOYPz/u+0gQJ+HXsUPUIYPQG9tbFDiRx0uJz0c6LBSugvZxNdmvuUbKQVeiT7 Q8ecqQBGIIgWHsYRKY8GFh6ARDA62czq5xCBGlag+ogzgM7XwxhG8cdmmBc9tovZp3yP RESDflEmR1J0V17PZzle5L8rysoEZ3BK5AdbIT9gbi1ef5fcD4CiGndJjlqZVfl8X+K7 8mahYrXFPO9I+KbeJEbDPxHeRZ91xlzsmoFJNVeAA88keW/916QkJwCxaviqtiCP/WMt EVnACCPdL9/SlrpI/oMqY5YM/qSy/WCdWmMx+Ni3M662wGpdFrMcooTrFc5RfMCA8Hxa lWOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bvc1TOFiJ2nJx4hEUrNwPJxXXfm1lVnMtoMnldBnr90=; b=FUNpccKz3AorF6k9XGzWXyyB8tF0O44p9xpdWjb9iiNjTHUtVWZPfQKWzyLfKULcXR nD53CqAyx/f/vUEYtIws6khOmdc6YIAEREhS/IgZ+ISoVnwVo1DFxdTxnRUq8KyiXo6J pR285u7lG2TqWAWJrFLu058k2Y9wiXFGWfOe3ny1tPIvZz4Yw6EzgWZDRVZG5A3CU4wI 5EgMAwA6NnPrsU7+8XsTVNlq0EiRTLWCFkkBXCEtHfHtlSb3TLfMxTkhJTV1mOi80Dma QK2pqJA/a61erLWWFRLMttcsI9eYdUM1hjJJxJGAUsd8J7vw2EMKX4gUNC5La74S4+PI 0xhQ== X-Gm-Message-State: ALoCoQlByYIBjRn/KdwlSj5X7Zan0nynb47E42fYDWUyqqNxftLstL0rbXsY2eb+0M46v2GUpAr8tsDkoswm5z5/HnHviH77+6QkyVKIH4TH/f9cEajcbCb/w+SF17nPEtrUYh375VrhJgILMvL7b7pYsl+WGFEiIit2v00FvWJvfl2ZwgIRaXCDDSm7mxfzZosXg6jP/qer X-Received: by 10.60.120.69 with SMTP id la5mr1511908oeb.86.1377170520458; Thu, 22 Aug 2013 04:22:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.56.226 with HTTP; Thu, 22 Aug 2013 04:21:38 -0700 (PDT) In-Reply-To: References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> From: Erik Kline Date: Thu, 22 Aug 2013 20:21:38 +0900 Message-ID: To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Aug 2013 11:22:04 -0000 REQ 1: 6434 5.9.1 is already a MUST. This does not need to be repeated. 6434 5.8 is already a MUST. Unless you want to make multipart ICMP a MUST (why?) as well, this too can be removed. REQ 6: re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so this MUST appears stronger. Bizarre, though, I never noticed that "ND SHOULD" before. REQ 10: this reads kind weird. In REQ 9 you require 6106 support, but in REQ 10 you say "if 6106 is not supported." I think you mean something like "if the network to which the mobile node is attaching does not support 6016". From mohamed.boucadair@orange.com Thu Aug 22 05:06:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A6111E8161; Thu, 22 Aug 2013 05:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYpKh815kKAr; Thu, 22 Aug 2013 05:05:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0E16621F9F40; Thu, 22 Aug 2013 05:05:57 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 961293B49A3; Thu, 22 Aug 2013 14:05:56 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7B80E35C045; Thu, 22 Aug 2013 14:05:56 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 22 Aug 2013 14:05:56 +0200 From: To: Erik Kline Date: Thu, 22 Aug 2013 14:05:54 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6fKfikkRu/iW5IQDuqYqlyPwJbBAAA6mxQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EEEE4E5C7@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.26.63617 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Aug 2013 12:06:03 -0000 Hi Erik, Thank you for the review.=20 Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d= e >Erik Kline >Envoy=E9=A0: jeudi 22 ao=FBt 2013 13:22 >=C0=A0: Owen DeLong >Cc=A0: v6ops@ietf.org; IETF Discussion >Objet=A0: Re: [v6ops] Last Call: 04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile >Devices) to Informational RFC > >REQ 1: > 6434 5.9.1 is already a MUST. This does not need to be repeated. [Med] Because some requirements are stronger in this document than what is = documented in RFC6434, we had two way to implement this in the document: (a) Indicate RFC6434 must be supported with the exceptions in the language = for some requirements listed in this document. (b) Call out explicitly the requirements from RFC6434 that are mandatory + = indicate which requirements are stronger than rfc6434. We decided to go for (b) as it provides a comprehensive list of requirement= s for 3GPP mobile devices grouped in one single document. IMHO, this is jus= t a matter of presentation.=20 This rationale is explained in the introduction. > 6434 5.8 is already a MUST. Unless you want to make multipart >ICMP a MUST (why?) as well, this too can be removed. > >REQ 6: > re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUS= T > frankly even 5.2 reads like MUST for 3GPP, but it does SHOULD so >this MUST appears stronger. Bizarre, though, I never noticed that "ND >SHOULD" before. [Med] The language is stronger compared to the SHOULD in Section 5.2 of RFC= 6434. > >REQ 10: > this reads kind weird. In REQ 9 you require 6106 support, but in >REQ 10 you say "if 6106 is not supported." I think you mean something >like "if the network to which the mobile node is attaching does not >support 6016". [Med] Yes, agree. As mentioned in the document, " Some of the features listed in this profile document require to activate dedicated functions at the network side." This will be fixed. From aservin@lacnic.net Thu Aug 22 08:15: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 004F711E81E9 for ; Thu, 22 Aug 2013 08:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Oj+3ctxjE4w for ; Thu, 22 Aug 2013 08:14:57 -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 5B92A11E81E8 for ; Thu, 22 Aug 2013 08:14:57 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (r190-64-26-200.su-static.adinet.com.uy [190.64.26.200]) by mail.lacnic.net.uy (Postfix) with ESMTP id 2354730847F; Thu, 22 Aug 2013 12:14:28 -0300 (UYT) Message-ID: <52162AEB.2070600@lacnic.net> Date: Thu, 22 Aug 2013 12:14:51 -0300 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B99BA6E@xmb-rcd-x09.cisco.com> <20130819123450.GY65295@Space.Net> <8C48B86A895913448548E6D15DA7553B9A9042@xmb-rcd-x09.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A74@PRVPEXVS15.corp.twcable.com> <8C48B86A895913448548E6D15DA7553B9AE1B1@xmb-rcd-x09.cisco.com> <5214FA74.5030607@lacnic.net> <8C48B86A895913448548E6D15DA7553B9AED6B@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9AED6B@xmb-rcd-x09.cisco.com> X-Enigmail-Version: 1.5.2 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 Cc: "" Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 15:15:06 -0000 Thanks. as On 8/21/13 6:45 PM, Fred Baker (fred) wrote: > > On Aug 21, 2013, at 10:35 AM, Arturo Servin > wrote: > >> I couldn't find the reference in RFC1918, Is it documented >> somewhere else (besides ietf-mailing lists dicussions)? > > RFC 810 (http://tools.ietf.org/html/rfc810), assumption 5. > From tperrine@scea.com Thu Aug 22 11:51: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 DFBE011E81F5 for ; Thu, 22 Aug 2013 11:51:51 -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 OPil2jS2ghfU for ; Thu, 22 Aug 2013 11:51:46 -0700 (PDT) Received: from ironport04a.scea.com (ironport04a.scea.com [160.33.44.78]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9411E81FB for ; Thu, 22 Aug 2013 11:51:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,935,1367996400"; d="scan'208";a="1979120" Received: from inbetweener02.scea.com ([160.33.45.196]) by ironport04a.scea.com with ESMTP; 22 Aug 2013 11:51:44 -0700 Received: from sd-tperrine-mpl.local (unknown [10.56.0.12]) by inbetweener02.scea.com (Postfix) with ESMTP id 563C0B811A for ; Thu, 22 Aug 2013 11:51:44 -0700 (PDT) Message-ID: <52165DC0.7090406@scea.com> Date: Thu, 22 Aug 2013 11:51:44 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF v6ops list X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] IPv6 transition technologies vs MITM (DEFCON) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Aug 2013 18:51:52 -0000 There's been a fair amount of debate on the list about the merits of using the transition technologies vs an aggressive move to native IPv6 (usually dual-stack). We keep coming back to (as we have for 10+ years) to finding business reasons to transition. In parallel, there's been a goodly amount of poking around IPv6, "the real world" and those transition technologies. The MITM attack demonstrated at DEFCON this year was nothing new. While it was widely covered as an "IPv6 security flaw", it was really taking advantage of the well-known "RA problem" and the behavior of an IPv6-capable node on a nominally IPv4-only network. Frankly, while it was a nice "one click" automation of an already-recognized exploit, there wasn't really anything new. But, what I'm seeing is that no one is talking about how the transition strategies will not address this attack at all, at least as far as I can tell. They all seem to seek to leave (allegedly) IPv4-only nodes in place and work at one or more hops away from those nodes. This ignores that so many nodes really aren't IPv4-only. They are really dual-stack nodes that are waiting for the IPv6 configuration to be completed. And you can complete that configuration, or your attacker will! I see two ways to mitigate this attack: turn off IPv6 on all modern OSes, or fully deploy IPv6. Guess which one I don't want to see advocated :-) Am I missing something, or is this one more point to add to the "deploy IPv6 now, deploy native, skip the transition technologies" ? (I'm including dual-stack in the native strategy.) From tjc@ecs.soton.ac.uk Thu Aug 22 13:51: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 B6CA311E8220 for ; Thu, 22 Aug 2013 13:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFjwoRMvLoRx for ; Thu, 22 Aug 2013 13:51:33 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D9DBF11E81CD for ; Thu, 22 Aug 2013 13:51:30 -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 r7MKpNFt013940; Thu, 22 Aug 2013 21:51:23 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r7MKpNFt013940 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1377204684; bh=1oyUKbxKNOit7OXhuS/BqZ4km9E=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=UJEVJG2RCJO80UAPf0iOk2TrWAh2peQQqA93+LTKTwm618hIzeRAGGWYWud3+HXFy QweF9LLoMSoCtPLKyuwT1K89xd5pDYUxoggce//+j5ciU4jzmDRp7mAaZhLEgr5AcJ uR0sTOCCkga5iAnBBbs3oK2MqljayqN5JOHFg7WY= 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 p7LLpN05445349843s ret-id none; Thu, 22 Aug 2013 21:51:24 +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 r7MKpHVT024984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Aug 2013 21:51:18 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4F144E0A-E918-4AAE-BB9A-02630968D953" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <52165DC0.7090406@scea.com> Date: Thu, 22 Aug 2013 21:51:18 +0100 Message-ID: References: <52165DC0.7090406@scea.com> To: Tom Perrine X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p7LLpN054453498400; tid=p7LLpN05445349843s; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r7MKpNFt013940 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IETF v6ops list Subject: Re: [v6ops] IPv6 transition technologies vs MITM (DEFCON) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Aug 2013 20:51:35 -0000 --Apple-Mail=_4F144E0A-E918-4AAE-BB9A-02630968D953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Aug 2013, at 19:51, Tom Perrine wrote: > There's been a fair amount of debate on the list about the merits of = using the transition technologies vs an aggressive > move to native IPv6 (usually dual-stack). We keep coming back to (as = we have for 10+ years) to finding business reasons > to transition. >=20 > In parallel, there's been a goodly amount of poking around IPv6, "the = real world" and those transition technologies. >=20 > The MITM attack demonstrated at DEFCON this year was nothing new. = While it was widely covered as an "IPv6 security > flaw", it was really taking advantage of the well-known "RA problem" = and the behavior of an IPv6-capable node on a > nominally IPv4-only network. >=20 > Frankly, while it was a nice "one click" automation of an = already-recognized exploit, there wasn't really anything new. >=20 > But, what I'm seeing is that no one is talking about how the = transition strategies will not address this attack at all, > at least as far as I can tell. They all seem to seek to leave = (allegedly) IPv4-only nodes in place and work at one or > more hops away from those nodes. This ignores that so many nodes = really aren't IPv4-only. They are really dual-stack > nodes that are waiting for the IPv6 configuration to be completed. And = you can complete that configuration, or your > attacker will! >=20 > I see two ways to mitigate this attack: turn off IPv6 on all modern = OSes, or fully deploy IPv6. Guess which one I > don't want to see advocated :-) >=20 > Am I missing something, or is this one more point to add to the = "deploy IPv6 now, deploy native, skip the transition > technologies" ? (I'm including dual-stack in the native strategy.) There's lots of work within the IETF on this, e.g. take a look at = http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets= -05. The sunset4 WG is also quite interesting. I'm surprised an event like DEFCON presented something that old. Tim= --Apple-Mail=_4F144E0A-E918-4AAE-BB9A-02630968D953 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii tperrine@scea.com> = wrote:

There's been a fair amount of debate on the list about the = merits of using the transition technologies vs an aggressive
move to = native IPv6 (usually dual-stack). We keep coming back to (as we have for = 10+ years) to finding business reasons
to transition.

In = parallel, there's been a goodly amount of poking around IPv6, "the real = world" and those transition technologies.

The MITM attack = demonstrated at DEFCON this year was nothing new. While it was widely = covered as an "IPv6 security
flaw", it was really taking advantage of = the well-known "RA problem" and the behavior of an IPv6-capable node on = a
nominally IPv4-only network.

Frankly, while it was a nice = "one click" automation of an already-recognized exploit, there wasn't = really anything new.

But, what I'm seeing is that no one is = talking about how the transition strategies will not address this attack = at all,
at least as far as I can tell. They all seem to seek to leave = (allegedly) IPv4-only nodes in place and work at one or
more hops = away from those nodes. This ignores that so many nodes really aren't = IPv4-only. They are really dual-stack
nodes that are waiting for the = IPv6 configuration to be completed. And you can complete that = configuration, or your
attacker will!

I see two ways to = mitigate this attack:  turn off IPv6 on all modern OSes, or fully = deploy IPv6.  Guess which one I
don't want to see advocated = :-)

Am I missing something, or is this one more point to add to = the "deploy IPv6 now, deploy native, skip the = transition
technologies" ?  (I'm including dual-stack in the = native strategy.)

There's lots of work = within the IETF on this, e.g. take a look at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications= -on-ipv4-nets-05.

The sunset4 WG is also = quite interesting.

I'm surprised an event like = DEFCON presented something that = old.

Tim
= --Apple-Mail=_4F144E0A-E918-4AAE-BB9A-02630968D953-- From farmer@umn.edu Thu Aug 22 15:59: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 CA9CF11E8169 for ; Thu, 22 Aug 2013 15:59:33 -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 mSf-XtsyvQGp for ; Thu, 22 Aug 2013 15:59:27 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29111E813D for ; Thu, 22 Aug 2013 15:59:27 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 22 Aug 2013 17:59:21 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ob0-f175.google.com [209.85.214.175] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f175.google.com with SMTP id xn12so4885338obc.34 for ; Thu, 22 Aug 2013 15:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tkWKlTQO5bOQFmedPn7BEFBueFjJOmKiYTCHX5xsEfA=; b=OI7BfMAWhjM8p2KoWXw/HKZgzxIsBzYnOcysZd70fEgXiRvt5rRcTyF4H8eppe1wIk srwAQRF8t3tilpvnuxlOq5OWwg6sRCcoZC6NgL5Rzdn5rlxPpL+2QRcXW5jVKgcg9Q2z rjTTO62hcfxS+NqnlgQZawTsoT/uzCLldTEJxXqHmooN1o/l+fQLqLlP3cm9SZhwfTbt rsyz2S6wjiwXxaS2bUu4eHCHxcyby0f/fQRnHwy5pp3+2IR81pBGTUS8t2dgDzS9WRf+ aGBnnC34g6GDkTbvZmd0QbbPWyYn5fAiFW0cYZdL5KyiHPcHiHD7v2yRcT1rA75qU7kD mM1A== X-Gm-Message-State: ALoCoQk9scsMFGbpp5Gq2k7qdecAhPTToOohrI3v1WNQmB9JIeaXUCL4KQ/k9CzgYDeOB/9i3F+wkIjJCg9TEf/KjtszC6Q3+0tmXypDLygXSWQ7j8cEbqI7IyBtIOYwaTikyZREewP8 X-Received: by 10.60.44.193 with SMTP id g1mr17093116oem.47.1377212360996; Thu, 22 Aug 2013 15:59:20 -0700 (PDT) X-Received: by 10.60.44.193 with SMTP id g1mr17093106oem.47.1377212360855; Thu, 22 Aug 2013 15:59:20 -0700 (PDT) Received: from x-134-84-88-90.nts.umn.edu (x-134-84-88-90.nts.umn.edu. [134.84.88.90]) by mx.google.com with ESMTPSA id tz10sm21997856obc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 15:59:19 -0700 (PDT) Message-ID: <521697C6.8080207@umn.edu> Date: Thu, 22 Aug 2013 17:59:18 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Chown References: <52165DC0.7090406@scea.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF v6ops list , Tom Perrine Subject: Re: [v6ops] IPv6 transition technologies vs MITM (DEFCON) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 22:59:33 -0000 On 8/22/13 15:51 , Tim Chown wrote: > > On 22 Aug 2013, at 19:51, Tom Perrine > wrote: > ... >> But, what I'm seeing is that no one is talking about how the >> transition strategies will not address this attack at all, >> at least as far as I can tell. They all seem to seek to leave >> (allegedly) IPv4-only nodes in place and work at one or >> more hops away from those nodes. This ignores that so many nodes >> really aren't IPv4-only. They are really dual-stack >> nodes that are waiting for the IPv6 configuration to be completed. And >> you can complete that configuration, or your >> attacker will! >> >> I see two ways to mitigate this attack: turn off IPv6 on all modern >> OSes, or fully deploy IPv6. Guess which one I >> don't want to see advocated :-) Yes, deploying IPv6 is the best answer in many, if not most cases. BUT; >> Am I missing something, or is this one more point to add to the >> "deploy IPv6 now, deploy native, skip the transition >> technologies" ? (I'm including dual-stack in the native strategy.) I will expand on the references Tim provides below; On all IPv4 only networks you should operationally deploy RA-Guard or filter IPv6 ICMP RAs, and DHCPv6 server responses while you are at it too, on all access ports where you can, and more drastically filter Ether-Type 86dd all together where you don't have RA-Guard or IPv6 filters available. In my view RA-Guard is not only a IPv6 network issue it an issue for all networks because of these MITM attacks. Before World IPv6 day more than two years ago, we had a project to make our entire network quad-A safe. That is we deployed IPv6 every where we could, and deployed IPv6 ICMP RA filters on virtually every wired access port. We deployed IPv6 on our 802.1x authenticated wireless. But we had to deploy 86dd filters on our web portal authenticated wireless, as the web portal didn't support IPv6, still doesn't, and there was no way to properly protect from Rogue RAs, other than to filter all IPv6 traffic. These generally weren't malicious MITM attacks, but were misconfigured hosts with Internet connection sharing turned on, but they still create issues on IPv4 only networks and would break any sites that would dare to use quad-As. So, back to the big BUT above, it is naive to think you can deploy native IPv6 absolutely every where. You may be able to deploy it most places, but you must protect from Rouge RAs every where, even IPv4 only networks. For policy reasons, still today, we still haven't turned on IPv6 in several parts of our network. These are mostly areas that deal with private data, HIPPI, FERPA, PCI and other compliance regimes, but it was extra important that theses areas also got RA-Guard for the very same reasons we haven't turned on IPv6 yet. > There's lots of work within the IETF on this, e.g. take a look at > http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05. > > The sunset4 WG is also quite interesting. > > I'm surprised an event like DEFCON presented something that old. It's an oldie but goodie. :) > Tim -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From philip_matthews@magma.ca Sun Aug 25 07:16: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 48E6C21F9D15 for ; Sun, 25 Aug 2013 07:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-kZERLX5QKp for ; Sun, 25 Aug 2013 07:16:39 -0700 (PDT) Received: from mail-09.primus.ca (smtp1.primus.ca [209.216.129.80]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7B21F9D0E for ; Sun, 25 Aug 2013 07:16:38 -0700 (PDT) Received: from [24.114.86.102] (helo=[172.20.10.4]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VDb7N-0001kL-2F; Sun, 25 Aug 2013 10:16:37 -0400 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Aug 2013 10:15:34 -0400 Message-Id: <71727141-CA1E-4D03-B4DB-94EECD48D43D@magma.ca> To: v6ops list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.86.102] Cc: Victor Kuarsingh Subject: [v6ops] Status of Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Aug 2013 14:16:45 -0000 Hi everyone: Just wanted to let everyone know that, despite the fact that the Design = Choice draft expired a couple of days ago, work has already started on a = new version. Victor Kuarsingh has come on board as a co-author and he has lots of = interesting ideas on content to add to the document. We have already had = two discussions on ideas for a revision. Progress has been a bit slow in = August due to vacations, but should pick up significantly in September. - Philip From fred@cisco.com Sun Aug 25 11:00: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 AE4F221F8E70 for ; Sun, 25 Aug 2013 11:00:30 -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 zyDmMhtqt7UO for ; Sun, 25 Aug 2013 11:00:25 -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 C4D8221F9C6B for ; Sun, 25 Aug 2013 11:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1377453622; x=1378663222; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=YOljrbOEnMHZyVVytST4rD2O44uHVAttFjo21ibIGRCmZaJUMj4HZbI+ i/yKLaQ1+0aVJ1Y7zVtpk8c//sn2znKZkgciAiGOYS7gXvftNw9tFc3Zy RBb/r+EGd40C4CsZ5bB57AkVAMYDEqx9TQdB2RxbhM1CqBSSNE5LDwue1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYJALFFGlKrRDoG/2dsb2JhbABZgwevDQGSDYEaFnSCSFw8NIhhtk6QeB2EAwOJMaAegz4 X-IronPort-AV: E=Sophos;i="4.89,952,1367971200"; d="scan'208";a="86912570" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 25 Aug 2013 18:00:11 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7PI0A7h007061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 18:00:11 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r7PI0AWV011157; Sun, 25 Aug 2013 11:00:10 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r7PI0AaK011152; Sun, 25 Aug 2013 11:00:10 -0700 (PDT) Date: Sun, 25 Aug 2013 11:00:10 -0700 (PDT) From: Fred Baker Message-Id: <201308251800.r7PI0AaK011152@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 18:00:30 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From mohamed.boucadair@orange.com Tue Aug 27 00:03: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 5052A11E828E for ; Tue, 27 Aug 2013 00:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOOj1CAwvhuB for ; Tue, 27 Aug 2013 00:03:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id F01B011E815F for ; Tue, 27 Aug 2013 00:03:21 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id A845EC0C85; Tue, 27 Aug 2013 09:03:20 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 86729C8056; Tue, 27 Aug 2013 09:03:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 27 Aug 2013 09:03:17 +0200 From: To: BINET David IMT/OLN , "Heatley, Nick" Date: Tue, 27 Aug 2013 09:03:15 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to Informational RFC Thread-Index: Ac6c45Y6p86QiVHMRoO9z7P1ON7d3wAmvCAgAAkMfuABVCBBEA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EEEE4EC9E@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <25402_1377003192_521366B8_25402_66_1_1B2E7539FECD9048B261B791B1B24A7C5119A03DF0@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: <25402_1377003192_521366B8_25402_66_1_1B2E7539FECD9048B261B791B1B24A7C5119A03DF0@PUEXCB1A.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.22452 Cc: "v6ops@ietf.org" , "Byrne, Cameron" , "denghui@chinamobile.com" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Aug 2013 07:03:26 -0000 Hi Nick, I added this new text: REQ#19: Because of potential operational deficiencies to be experienced in some roaming situations, the cellular host MUST be able to be configured with a home IP profile and a roaming IP profile. The aim of the roaming profile is to limit the PDP type(s) requested by the cellular host when out of the home network. Note, distinct PDP type(s) can be configured for home and roaming cases. Please let me know if this text solves your concern.=20 Cheers, Med >-----Message d'origine----- >De=A0: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d= e >david.binet@orange.com >Envoy=E9=A0: mardi 20 ao=FBt 2013 14:53 >=C0=A0: Heatley, Nick; v6ops@ietf.org; Byrne, Cameron; phdgang@gmail.com; >Vizdal Ales (TMCZ) >Cc=A0: denghui@chinamobile.com >Objet=A0: Re: [v6ops] Last Call: 04.txt>(Internet Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) >to Informational RFC > >Hi Nick, > >A new version of the draft will be edited at least taking into account >comments received during this last call process. >A requirement to guarantee that the device has some IP connectivity in >roaming context, like the one you mention, is likely to be integrated in >this upcoming version even if the discussions about roaming will continue >and will go beyond device capabilities. > >David > >> -----Message d'origine----- >> De : Heatley, Nick [mailto:Nick.Heatley@ee.co.uk] >> Envoy=E9 : mardi 20 ao=FBt 2013 10:50 >> =C0 : v6ops@ietf.org; BINET David IMT/OLN; Byrne, Cameron; >> phdgang@gmail.com; Vizdal Ales (TMCZ) >> Cc : denghui@chinamobile.com >> Objet : RE: [v6ops] Last Call: >> (Internet >> Protocol Version 6 (IPv6) Profile for 3GPP MobileDevices) to >> Informational RFC >> >> Given we have been discussing 3GPP IPv6 Roaming, I was >> thinking of any mobile terminal requirements that come from roaming. >> There seems to be no specifics regarding roaming in this paper. >> >> One solution appears to be coming into favour to fix one type >> of operational deficiencies in current roaming: that the >> terminal can be configured with a home IP profile and a >> roaming IP profile. This is not so much a compliance >> requirement, as protecting the subscriber against exceptions >> when roaming. Should this be included in this paper? Or would >> this need further debate beyond the scope of this paper? >> What are your thoughts? >> Nick >> >> >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf >> > Of The IESG >> > Sent: 19 August 2013 14:52 >> > To: IETF-Announce >> > Cc: v6ops@ietf.org >> > Subject: [v6ops] Last Call: > > 04.txt>(Internet Protocol Version 6 (IPv6) Profile for 3GPP >> > MobileDevices) to Informational RFC >> > >> > >> > The IESG has received a request from the IPv6 Operations WG >> (v6ops) to >> > consider the following document: >> > - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP >> Mobile Devices' >> > as >> Informational RFC >> > >> > The IESG plans to make a decision in the next few weeks, >> and solicits >> > final comments on this action. Please send substantive >> comments to the >> > ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, >> comments may >> > be sent to iesg@ietf.org instead. In either case, please retain the >> > beginning of the Subject line to allow automated sorting. >> > >> > Abstract >> > >> > >> > 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 file can be obtained via >> > >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile >> > / >> > >> > IESG discussion can be tracked via >> > http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device- >> > profile/ballot/ >> > >> > >> > No IPR declarations have been submitted directly on this I-D. >> > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >__________________________________________________________________________= _ >______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u >ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme ou >falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have been >modified, changed or falsified. >Thank you. > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nalini.elkins@insidethestack.com Tue Aug 27 05:48: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 A4F3D11E8303 for ; Tue, 27 Aug 2013 05:48:47 -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 dUqMr9siqxK7 for ; Tue, 27 Aug 2013 05:48:42 -0700 (PDT) Received: from nm6-vm4.access.bullet.mail.gq1.yahoo.com (nm6-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9C79E11E8302 for ; Tue, 27 Aug 2013 05:48:42 -0700 (PDT) Received: from [216.39.60.170] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Aug 2013 12:48:42 -0000 Received: from [216.39.60.244] by tm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Aug 2013 12:48:42 -0000 Received: from [127.0.0.1] by omp1015.access.mail.gq1.yahoo.com with NNFMP; 27 Aug 2013 12:48:42 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 109851.370.bm@omp1015.access.mail.gq1.yahoo.com Received: (qmail 65956 invoked by uid 60001); 27 Aug 2013 12:48:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377607721; bh=v2mtiTehKLJhaU97Bp4BOH9du37oXzbz4oyXwsAdIz8=; 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=GlFSjvL2XUp7USv6Pr140+JExAv1OKSvqPuMsnI+qi+lqyBD2dRuRJM3kLb1Qt3f0AlSDKu6sgdZqiPUb2A352Hxv1jqh+dzX8jc+XRFvFtqE9gm4u4m2qbNYxHB74EPqqPiTV5mPo4Vb3NTCgGnCr+BoaFD20y2oTarzAvoeHk= X-YMail-OSG: bqvrBR8VM1kCBjvs5y2N8urYTde2mHV9j.WoYfppWXIyTnz WEW0Bdtsc8u5QVLWirdwcFxyA_XIoJGCqECdSSdxOS5AqJ4MzbQWEnoihL3m KF7AK64El9OIl21g.36JL2SvXfiklzcq7j7lczhbbABzrxrWcPY8JcIWdRC8 chqc0GtMLtaQzW0EaDJI.6hXFbdC8.zvm91qw2wZAHhtkGGiyplyutu.sC45 glgiNBVimmN3bR3Rdd9v5SMRdxYAIxA4QPbHXo2yenR_gL.UChdsJrTUM4aW pxO6LgL8KYLeDjMGKArMl8_jBmvLEsXRy6_DOt2aFhQBZ13s._3RFLmeBRWV hYvfd3HBjXz7Xh92wUKQoRA5D6liABRaIZee9a0tr6fWWGw4AtZaPdX580pX GivpRRJkRGOP2.90d83E42RmWkkWZDQwGME5g0kAbogB01g_GKR3tCMaPllY .Ts1f23G7yMLya_uk3BCB9v9wA8y17vk5psGyWKX72i2HiOhAE6.ypTf6WOa tYdPWrU5Th0T3FvtHgvlzktq2aohbdcpzrPR14lcv4AUZ0SaXH5o7ZM4g.bp TheCLPDk.L5nzZTaVAbeko87cST0taNwYPuqJl15BDrCiGcBb1eF9PW2t3A. 40G4h3Wmh9wz4bC7EBg.sLTofoygPPGqKdFaTVnL3N4FZ.vqt.YQAC3dCgV1 rFPgLt0MyBF3XlS87P1YRFL7MZX1UQPwV609QoGYkiQq8g77ko7chz1HOUg1 okweXDx7xJPi9VtmndLnovjYVtgrZC5IQVK2JJ5zyQI0ZpB5Zew-- Received: from [66.51.70.107] by web2806.biz.mail.ne1.yahoo.com via HTTP; Tue, 27 Aug 2013 05:48:41 PDT X-Rocket-MIMEInfo: 002.001, Sm9lbCwKClRoZSBzeW5jaHJvbml6YXRpb24gYW5kIGdyYW51bGFyaXR5IG9mIHRoZSB0aW1lc3RhbXBzIGZvciBvdXIgcHJvcG9zYWwgaXMgb25lIG9mIHRoZSB0d28gb3V0c3RhbmRpbmcgaXNzdWVzLiDCoCBJIHdpbGwgdGFrZSB1cCB0aGUgb3RoZXIgaXNzdWUgKGlzIHRoaXMgcHJvcG9zYWwgdXNlZnVsIGZvciB0aGUgSW50ZXJuZXQ_KSBpbiBhIHNlcGFyYXRlIHRocmVhZC4KCldlIGhhdmUgYWxzbyBoYWQgc29tZSBkaXNjdXNzaW9ucyB3aXRoIHRoZSBmb2xrcyBpbiB0aGUgSVBQTSBncm91cCwgc28gSSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: <51FA6667.4010200@bogus.com> Message-ID: <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Tue, 27 Aug 2013 05:48:41 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , IPv6 Ops WG , "tsv-area@ietf.org" In-Reply-To: <51FA6667.4010200@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "joachim.fabini@tuwien.ac.at" , "ALFRED C \(AL\)" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 12:48:47 -0000 Joel,=0A=0AThe synchronization and granularity of the timestamps for our pr= oposal is one of the two outstanding issues. =C2=A0 I will take up the othe= r issue (is this proposal useful for the Internet?) in a separate thread.= =0A=0AWe have also had some discussions with the folks in the IPPM group, s= o I am copying that working group on this thread.=0A=0ATo restate the issue= s as I understand them (please correct me if I am wrong):=0A=0A1. =C2=A0 Ti= mestamp correlation depends on both ends being synchronized using a standar= d mechanism.=0A2. =C2=A0 This is a question of 'best practices'.=0A3. =C2= =A0 Is the timestamp of sufficient quality or granularity to be useful.=0A= =0AThe answers to 1. and 2. =C2=A0is yes. =C2=A0 Of course. =C2=A0 If peopl= e find this kind of data to be of use, then they will synchronize. =C2=A0It= is my understanding that activities other than those proposed by us requir= e time synchronization. =C2=A0 So, it is quite likely that people may be do= ing this already.=0A=0AThe answer to 3. is an interesting one. =C2=A0 I wil= l cite a paper from Dr. Joachim Fabini. =C2=A0It is available at:=0A=0Ahttp= ://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D6553584=0A=0AThe s= ignificant passage is on page 7:=0A=0A"Mobile client and server are both ac= curately timesynchronized using EM-406A GPS modules with PPS support. =C2= =A0 =C2=A0The RS232 level conversion required for this GPS module=C2=A0is i= mplemented by a SparkFun 8334 GPS evaluation board=0Awhich has been extende= d by the PPS circuit as proposed in [8].=C2=A0The Network Time Protocol Dae= mon (ntp) synchronizes both=C2=A0endpoints accurately with global time usin= g the evaluation=C2=A0board=E2=80=99s level-converted PPS and GPS time sign= als accessed=C2=A0by the kernel using native RS232 serial interfaces. Tests= over=C2=A0several weeks have shown that this setup can synchronize the=C2= =A0system clock accurately down to 5=CE=BCs to global time. Even if=C2=A0de= ployed in nonoptimum conditions (indoor, 1st =EF=AC=82oor, street=C2=A0view= with 6-=EF=AC=82oor opposite building), the clock accuracy is=C2=A0better = than 50=CE=BCs."=C2=A0=0A=0AI believe that 5 - 50 microseconds of accuracy = is sufficient for triage. =C2=A0In our proposal, we want three times: inbou= nd network path, the server processing time, or the outbound network path. = =C2=A0I believe that for accurate triage,=C2=A0we will be able to say that = the problem is in the inbound network path, the server, or the outbound net= work path even if the clocks vary by 50 microseconds. =C2=A0In my experienc= e, the differences between the 3 calculations which we want vary by quite a= bit more than 50 microseconds. =C2=A0=C2=A0I actually have quite a bit of = data available to prove this from running diagnostics with a number of comp= anies and over the Internet in the last few years and I will do a paper (wh= en I get a free weekend!). =C2=A0 I will discuss my findings with the IPPM = group as I believe this to be of interest to them.=0A=0AFor those who may b= e new to this discussion, they may care to look at our proposals:=0A=0Ahttp= ://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-00=0A=0A=0Aht= tp://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed-00=0A= =0A=0Ahttp://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-ne= eded-00=0A=0A=0Ahttp://www.ietf.org/id/draft-elkins-v6ops-ipv6-pdm-recommen= ded-usage-00.txt=0A=0A=0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.= =0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_____________________= ___________=0AFrom: joel jaeggli =0ATo: Nalini Elkins ; IPv6 Ops WG =0ASent: Thur= sday, August 1, 2013 6:45 AM=0ASubject: draft-elkins-v6ops-ipv6-pdm-recomme= nded-usage-00=0A=0A=0ASince I ran into you in the hall and the dicussion tu= rned to ntp...=0A=0AI'll try and be succinct, and as a non-expert in the ti= me field this=0Ashould be taken with a grain of salt.=0A=0AThe generic util= ity of a high-resultion time-stamp is imho dodgey=0Aoutside of situations w= here the clocks are deliberately syncronized and=0Atraceable to a common st= andard whether the protocol used for this is ntp=0Aor ieee 1588 (or since t= his is the ietf PTPV2) . While this is tractable=0Afor devices in a single = span of control, the agruement that ntp might be=0Asuffcient to make this t= imstamp useful generically between two=0Aaribitratry devices where this fun= ctionality may need to be enabled is=0Aimho a hard one to assert.=0A=0AIt i= s a set of operational practice and discipline moreso than the=0Achoice of = technology that allows for a high-resolution timestamp to have=0Asufficient= precision to be useful between hosts.=0A=0Ajoel=C2=A0 From nalini.elkins@insidethestack.com Tue Aug 27 06:56: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 49A4821E80D6 for ; Tue, 27 Aug 2013 06:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WQsQtZFda5c for ; Tue, 27 Aug 2013 06:55:59 -0700 (PDT) Received: from nm4-vm6.access.bullet.mail.bf1.yahoo.com (nm4-vm6.access.bullet.mail.bf1.yahoo.com [216.109.114.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9966A21E80D8 for ; Tue, 27 Aug 2013 06:55:58 -0700 (PDT) Received: from [66.196.81.155] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 13:55:58 -0000 Received: from [66.196.81.145] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 13:55:58 -0000 Received: from [127.0.0.1] by omp1021.access.mail.bf1.yahoo.com with NNFMP; 27 Aug 2013 13:55:58 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 63255.3450.bm@omp1021.access.mail.bf1.yahoo.com Received: (qmail 70441 invoked by uid 60001); 27 Aug 2013 13:55:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377611757; bh=G+ZlJBMl4S1zlwoUCLXPLfl8GGYosgY7IQfoC594Clk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GqOcZSoAfjnSd6NaFGCaefLAoXT5chHJ/JMXkR42c7u7fEGF1wz2US32GGnzwPgNqhrMxWNLYrBuBSgvjaMtz/CHZWpAmjFsXI50WcjedCHxSH0fzRoqhBIpDSHzf6Df7JQ1KXn+/prTaGelxD+dpmlVVBD225Afx7KIwe6IUi4= X-YMail-OSG: 0sNadG4VM1lVMvMBWLKiO_U4QE9nCqLA3T5o_vO0_4gpwua 0c.WBaU1.uzNmpTBNxrt1h9U.dRX1ZDdEUfiLrEl9qSjALQCuNrqP1RQVsCC .ANUoGqjfY09eky5rxSpooUbEb4LnZQw4DPciiuBMLAzbiPFhq12OL5LK7H9 dNL85pz2aO3icFXvMGxv0zZv6FVJLZT_Z.IKW82JNnpbv8jGJWlZAHlx0BcE vbbMz4lbmSaQYtbLzAOyqwHn9IpA3kU.TlCUShdyENiYdOPlrcJ8P2PMMPsy VqRu8UzDDxKHWpPJ2zihTUw7Jk6Ycn8M62EchdGqJTb5RIGP1uF0fA9uLM.s MMj7JQO0HGLZj9qW2oUYKa791vGbgAYqeg0fi4O4dHeppq86KH7dUYiMeBO_ clS4C57Gb9tpyyd8eOM.7fzrP9gAZ5YYeipujAFSH1w_sFI2hjGOupxOggKD KsTXgOxkTqEIGmbxRAm5a3375fsIItPJqTeMyPQhhYAYQFfbMdvWZOMUiH9S wQSF_eTTzvTrQ5.wyIO_5nZ_lvj7JLvo1BTITXpsFFNAquSjKNfZZVrFhngH .U0veo70QjllVDNlOHsAy_VEj4B1t.roLHjag.QbXzj_URplWZQKt1H61tV8 LNq7TbfUCm4FzNht1x4i21Xlfus0TS8292secgBfiYGJSS7PXJ1zmkelF729 xz8BamSjxu7JrQr8l5L6PuNgPMrloBVGD.MiE6ffnREj83bjWsaJnDBN7uw- - Received: from [66.51.70.107] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 27 Aug 2013 06:55:57 PDT X-Rocket-MIMEInfo: 002.001, TG9yZW56bywKCkkgYmVsaWV2ZSB0aGF0IGR1cmluZyB0aGUgcXVlc3Rpb24gcG9ydGlvbiBvZiBvdXIgcHJvcG9zYWwgYXQgSUVURiA4NywgeW91IGhhZCBicm91Z2h0IHVwIHRoZSBwb2ludCB0aGF0IHRoZSBtZWFzdXJlbWVudHMgd2UgcHJvcG9zZSBtYXkgYmUgdmFsaWQgZm9yIGVudGVycHJpc2UgbmV0d29ya3MgYnV0IHdvdWxkIG5vdCBiZSBmb3Igc2l0ZXMgb3ZlciB0aGUgSW50ZXJuZXQuIMKgUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSBub3Qgc3RhdGluZyB5b3VyIGNvbW1lbnRzIGNvcnJlY3RseS4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 Message-ID: <1377611757.70213.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 27 Aug 2013 06:55:57 -0700 (PDT) From: Nalini Elkins To: Lorenzo Colitti , IPv6 Ops WG , "tsv-area@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "joachim.fabini@tuwien.ac.at" , "ALFRED C \(AL\)" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-end-to-end-rt-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:56:04 -0000 Lorenzo,=0A=0AI believe that during the question portion of our proposal at= IETF 87, you had brought up the point that the measurements we propose may= be valid for enterprise networks but would not be for sites over the Inter= net. =A0Please correct me if I am not stating your comments correctly.=0A= =0AI would ask you to look at the activities of two working groups in parti= cular. =A0LMAP and IPPM. =A0 They both are quite interested in measurements= of performance over the Internet. =A0I believe that our proposal can add v= alue to the work of the below groups. =A0=A0=0A=0Ahttp://datatracker.ietf.o= rg/wg/lmap/charter/=0A=0Ahttp://datatracker.ietf.org/wg/ippm/charter/=0A=0A= =0AFor those who may be new to this discussion, they may care to look at ou= r proposals:=0A=0Ahttp://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-des= t-option-00=0A=0Ahttp://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-= end-rt-needed-00=0A=0Ahttp://tools.ietf.org/html/draft-elkins-v6ops-ipv6-pa= cket-sequence-needed-00=0A=0Ahttp://www.ietf.org/id/draft-elkins-v6ops-ipv6= -pdm-recommended-usage-00.txt=0A=0A=0AThanks,=0A=0ANalini Elkins=0AInside P= roducts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A From fgont@si6networks.com Tue Aug 27 23:38:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4910D11E814D for ; Tue, 27 Aug 2013 23:38: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 EAI54FGfKoSy for ; Tue, 27 Aug 2013 23:38:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B962411E8104 for ; Tue, 27 Aug 2013 23:38:28 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.109]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VEZNw-0005Aa-UE; Wed, 28 Aug 2013 08:37:46 +0200 Message-ID: <521D9AB0.4030007@si6networks.com> Date: Wed, 28 Aug 2013 03:37:36 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Farmer References: <52165DC0.7090406@scea.com> <521697C6.8080207@umn.edu> In-Reply-To: <521697C6.8080207@umn.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tom Perrine , IETF v6ops list Subject: Re: [v6ops] IPv6 transition technologies vs MITM (DEFCON) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Aug 2013 06:38:29 -0000 On 08/22/2013 07:59 PM, David Farmer wrote: > > For policy reasons, still today, we still haven't turned on IPv6 in > several parts of our network. These are mostly areas that deal with > private data, HIPPI, FERPA, PCI and other compliance regimes, but it was > extra important that theses areas also got RA-Guard for the very same > reasons we haven't turned on IPv6 yet. Regarding RA-Guard, you're probably aware of . Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Wed Aug 28 03: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 2768611E817B; Wed, 28 Aug 2013 03:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 odFEGFD7bWXI; Wed, 28 Aug 2013 03:17:53 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DD1F511E816F; Wed, 28 Aug 2013 03:17:52 -0700 (PDT) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r7SAHnG6092574 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 28 Aug 2013 10:17:49 GMT (envelope-from joelja@bogus.com) Message-ID: <521DCE46.6030501@bogus.com> Date: Wed, 28 Aug 2013 03:17:42 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Nalini Elkins , IPv6 Ops WG , "tsv-area@ietf.org" References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8 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]); Wed, 28 Aug 2013 10:17:50 +0000 (UTC) Cc: "joachim.fabini@tuwien.ac.at" , "ALFRED C \(AL\)" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 10:17:54 -0000 On 8/27/13 5:48 AM, Nalini Elkins wrote: > Joel, > > The synchronization and granularity of the timestamps for our proposal is one of the two outstanding issues. I will take up the other issue (is this proposal useful for the Internet?) in a separate thread. > > We have also had some discussions with the folks in the IPPM group, so I am copying that working group on this thread. > > To restate the issues as I understand them (please correct me if I am wrong): > > 1. Timestamp correlation depends on both ends being synchronized using a standard mechanism. > 2. This is a question of 'best practices'. > 3. Is the timestamp of sufficient quality or granularity to be useful. > > The answers to 1. and 2. is yes. Of course. If people find this kind of data to be of use, then they will synchronize. It is my understanding that activities other than those proposed by us require time synchronization. So, it is quite likely that people may be doing this already. > > The answer to 3. is an interesting one. I will cite a paper from Dr. Joachim Fabini. It is available at: > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6553584 > > The significant passage is on page 7: > > "Mobile client and server are both accurately timesynchronized using EM-406A GPS modules with PPS support. The RS232 level conversion required for this GPS module is implemented by a SparkFun 8334 GPS evaluation board > which has been extended by the PPS circuit as proposed in [8]. The Network Time Protocol Daemon (ntp) synchronizes both endpoints accurately with global time using the evaluation board’s level-converted PPS and GPS time signals accessed by the kernel using native RS232 serial interfaces. Tests over several weeks have shown that this setup can synchronize the system clock accurately down to 5μs to global time. Even if deployed in nonoptimum conditions (indoor, 1st floor, street view with 6-floor opposite building), the clock accuracy is better than 50μs." network devices are by-in-large not built with embedded GPS. By way of demonstration of the level of measuerment error I expect. Juniper RPM can do asic based timestamping on measurement traffic between two devices. I have a path, the length of which does not vary by much (it's a wave-length between san jose and ashburn virginia). the routers derive time from a clustered of peered stratum 2 servers which in turn are clients of stratum-1 sources that are traceable to NIST. in the following graph: http://i.imgur.com/AkDRs9D.png the top line is the RTT as measured by the sending router. the green line is the difference between the timestamp applied by the reciveing router in ashburn and the timestamp applied by the sending router, and the redline is the differnce between the ashburn router sending timestamp and the timestamp genrated when the packet is recieved again in san jose. the vertical axis is thousands of microseconds. I'm farily comfortable that my NTP and my devices clocks aren't totaly busted. I'm also comfortable with the idea that there's substantially higher variation out there when you get out a of a single admistrative domain. > I believe that 5 - 50 microseconds of accuracy is sufficient for triage. In our proposal, we want three times: inbound network path, the server processing time, or the outbound network path. I believe that for accurate triage, we will be able to say that the problem is in the inbound network path, the server, or the outbound network path even if the clocks vary by 50 microseconds. In my experience, the differences between the 3 calculations which we want vary by quite a bit more than 50 microseconds. I actually have quite a bit of data available to prove this from running diagnostics with a number of companies and over the Internet in the last few years and I will do a paper (when I get a free weekend!). I will discuss my findings with the IPPM group as I believe this to be of interest to them. > > For those who may be new to this discussion, they may care to look at our proposals: > > http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-00 > > > http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed-00 > > > http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00 > > > http://www.ietf.org/id/draft-elkins-v6ops-ipv6-pdm-recommended-usage-00.txt > > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > > ________________________________ > From: joel jaeggli > To: Nalini Elkins ; IPv6 Ops WG > Sent: Thursday, August 1, 2013 6:45 AM > Subject: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 > > > Since I ran into you in the hall and the dicussion turned to ntp... > > I'll try and be succinct, and as a non-expert in the time field this > should be taken with a grain of salt. > > The generic utility of a high-resultion time-stamp is imho dodgey > outside of situations where the clocks are deliberately syncronized and > traceable to a common standard whether the protocol used for this is ntp > or ieee 1588 (or since this is the ietf PTPV2) . While this is tractable > for devices in a single span of control, the agruement that ntp might be > suffcient to make this timstamp useful generically between two > aribitratry devices where this functionality may need to be enabled is > imho a hard one to assert. > > It is a set of operational practice and discipline moreso than the > choice of technology that allows for a high-resolution timestamp to have > sufficient precision to be useful between hosts. > > joel > From nalini.elkins@insidethestack.com Wed Aug 28 03:53: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 6FACE11E81B6 for ; Wed, 28 Aug 2013 03:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuWmqNuc5kMG for ; Wed, 28 Aug 2013 03:53:17 -0700 (PDT) Received: from nm2-vm1.access.bullet.mail.bf1.yahoo.com (nm2-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8712F11E817D for ; Wed, 28 Aug 2013 03:53:12 -0700 (PDT) Received: from [66.196.81.162] by nm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 10:53:11 -0000 Received: from [66.196.81.131] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 10:53:11 -0000 Received: from [127.0.0.1] by omp1007.access.mail.bf1.yahoo.com with NNFMP; 28 Aug 2013 10:53:11 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 737775.22202.bm@omp1007.access.mail.bf1.yahoo.com Received: (qmail 92708 invoked by uid 60001); 28 Aug 2013 10:53:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377687191; bh=pDkUffidHh9Vk1HkClDtWjnNCUXYNIbaNrYo+ISSrk8=; 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=Is/ww4tuadW6pQUsVE0pvFZsZdIm/q2nSYjcN5+jskU+NfPzSNGDq1AXcpHQ4DdYICe9bRu4qo2fnqXfJX0pswCYNuqVcqer1NYOjbqzQnMijSzhO3KVPzgUojROmkhPWTTVvpeUVfx/qNt06hD7SekLoYYR8M2mdF3sZZ2Ek5E= X-YMail-OSG: YZaOUjQVM1np1QQSmbxwgrJjKoq6YF0c0yM4Eo_TR.9j4P3 ifl6uZKw7UW42uSSSf8u6p4aXpxYbar9X17DZtuK39Q72s9lhJe4atsd4KEW l5pcTTR9.eluq4a2FpEZ_lJj0Ye.pcPiAeUWu992LwH6AH_CLxHA7nz.PHZa vZcew0ztdsCp9_CcmD_5OoLtMGm8agB1c8_0jQmpf1Eq8i7ORQAzkCOUhgI. qRF3b..GZsGqK3_qi94sqBiTuM9knMQGStU_EcyvrbQMIqChf6hkMM5Niz60 ebSwwTWVgVGH2lYO3NVVqJAwzI6nmj2cwjqur89CwqPJMlTZ_xUdcBJXMwZq B.AL4oMnSgBma1ruAL3ff3hK2Ze9zGjfGVmJrcAx7MyWkCpA9vHUU4U.eClS amaFjPIbduGovAoBt4NMQCEZaZC_NP1a641C2WIHas9ignDOQ7HEJHs6CzgX rgU8INcNrgJrvdz2JNwKZQZs1st3zI2p4YXW80pL1ilDJz0mH24wgdGi.7MN Hrkczpxvkmpf8TG4S8uSkBiBLsdSGs0po2k_7yY2zzqoAPgse.5OhIHozYDs Q5SrlMHNrdq8.nbPrkDylb21QLIlW3y_6ILFs3zccs0Hlx3jR3Ir9ttNCS0E x5YUyJ4ocSbI_FHIpfcWu.vmbYmpY2jG3iupSnkt6tj7qMT6LCzYHkcxIrB7 O56bP44eWZg3uxvk1P5JxHxo1Ba4bQKYFJgLYK_e8Sq9NjivxIGSzFpNoTT3 KHzA74V9mj6NwCL7mOXLBwjQfCU.77HN1upmhjFkU_BOp.1MTf45KbHxqOkC BbgcrRSJqyW_LTdozTiN0NQPWkdmKwW9YeEO7hX5f5_OPYutDAvCyjI5Ttg- - Received: from [63.68.129.61] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 28 Aug 2013 03:53:11 PDT X-Rocket-MIMEInfo: 002.001, Sm9lbCwKCgo.Pm5ldHdvcmsgZGV2aWNlcyBhcmUgYnktaW4tbGFyZ2Ugbm90IGJ1aWx0IHdpdGggZW1iZWRkZWQgR1BTLgoKV2UgYXJlIG5vdCB0YWxraW5nIGFib3V0IG5ldHdvcmsgZGV2aWNlcy4gwqAgT3VyIGhlYWRlciBpcyBhIERlc3RpbmF0aW9uIE9wdGlvbnMgaGVhZGVyIHdoaWNoIE9OTFkgZW5kIGhvc3RzIG5lZWQgdG8gYmUgY29uY2VybmVkIHdpdGguIMKgIFlvdXIgZGF0YSBpcyB2ZXJ5IGludGVyZXN0aW5nIGJ1dCBpdCBpcyBub3Qgd2hhdCB3ZSBhcmUgdGFsa2luZyBhYm91dC4KCldoYXQgaXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <521DCE46.6030501@bogus.com> Message-ID: <1377687191.85628.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 28 Aug 2013 03:53:11 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , IPv6 Ops WG , "tsv-area@ietf.org" In-Reply-To: <521DCE46.6030501@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "joachim.fabini@tuwien.ac.at" , "ALFRED C \(AL\)" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 10:53:22 -0000 Joel,=0A=0A=0A>>network devices are by-in-large not built with embedded GPS= .=0A=0AWe are not talking about network devices. =C2=A0 Our header is a Des= tination Options header which ONLY end hosts need to be concerned with. =C2= =A0 Your data is very interesting but it is not what we are talking about.= =0A=0AWhat is of concern is what actual end hosts can do. =C2=A0This is a c= onversation that I will be starting with the OS vendors. =C2=A0 =C2=A0That = is why Joachim's paper was of interest.=0A=0A=0AThanks,=0A=0ANalini Elkins= =0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A= ________________________________=0AFrom: joel jaeggli =0A= To: Nalini Elkins ; IPv6 Ops WG ; "tsv-area@ietf.org" =0ACc: ALFRED C (AL) ; "joachim.fabini@tuwien.ac.at" ;= "trammell@tik.ee.ethz.ch" =0ASent: Wednesday, Au= gust 28, 2013 3:17 AM=0ASubject: Re: draft-elkins-v6ops-ipv6-pdm-recommende= d-usage-00=0A=0A=0AOn 8/27/13 5:48 AM, Nalini Elkins wrote:=0A> Joel,=0A>= =0A> The synchronization and granularity of the timestamps for our proposal= is one of the two outstanding issues.=C2=A0=C2=A0=C2=A0I will take up the = other issue (is this proposal useful for the Internet?) in a separate threa= d.=0A>=0A> We have also had some discussions with the folks in the IPPM gro= up, so I am copying that working group on this thread.=0A>=0A> To restate t= he issues as I understand them (please correct me if I am wrong):=0A>=0A> 1= .=C2=A0=C2=A0=C2=A0Timestamp correlation depends on both ends being synchro= nized using a standard mechanism.=0A> 2.=C2=A0=C2=A0=C2=A0This is a questio= n of 'best practices'.=0A> 3.=C2=A0=C2=A0=C2=A0Is the timestamp of sufficie= nt quality or granularity to be useful.=0A>=0A> The answers to 1. and 2.=C2= =A0 is yes.=C2=A0=C2=A0=C2=A0Of course.=C2=A0=C2=A0=C2=A0If people find thi= s kind of data to be of use, then they will synchronize.=C2=A0 It is my und= erstanding that activities other than those proposed by us require time syn= chronization.=C2=A0=C2=A0=C2=A0So, it is quite likely that people may be do= ing this already.=0A>=0A> The answer to 3. is an interesting one.=C2=A0=C2= =A0=C2=A0I will cite a paper from Dr. Joachim Fabini.=C2=A0 It is available= at:=0A>=0A> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D6= 553584=0A>=0A> The significant passage is on page 7:=0A>=0A> "Mobile client= and server are both accurately timesynchronized using EM-406A GPS modules = with PPS support.=C2=A0 =C2=A0 The RS232 level conversion required for this= GPS module is implemented by a SparkFun 8334 GPS evaluation board=0A> whic= h has been extended by the PPS circuit as proposed in [8]. The Network Time= Protocol Daemon (ntp) synchronizes both endpoints accurately with global t= ime using the evaluation board=E2=80=99s level-converted PPS and GPS time s= ignals accessed by the kernel using native RS232 serial interfaces. Tests o= ver several weeks have shown that this setup can synchronize the system clo= ck accurately down to 5=CE=BCs to global time. Even if deployed in nonoptim= um conditions (indoor, 1st =EF=AC=82oor, street view with 6-=EF=AC=82oor op= posite building), the clock accuracy is better than 50=CE=BCs." =0Anetwork = devices are by-in-large not built with embedded GPS.=0A=0ABy way of demonst= ration of the level of measuerment error I expect.=0AJuniper RPM can do asi= c based timestamping on measurement traffic=0Abetween two devices. I have a= path, the length of which does not vary by=0Amuch (it's a wave-length betw= een san jose and ashburn virginia). the=0Arouters derive time from a cluste= red of peered stratum 2 servers which=0Ain turn are clients of stratum-1 so= urces that are traceable to NIST. =0A=0Ain the following graph:=0A=0Ahttp:/= /i.imgur.com/AkDRs9D.png=0A=0Athe top line is the RTT as measured by the se= nding router.=0A=0Athe green line is the difference between the timestamp a= pplied by the=0Areciveing router in ashburn and the timestamp applied by th= e sending=0Arouter, and the redline is the differnce between the ashburn ro= uter=0Asending timestamp and the timestamp genrated when the packet is reci= eved=0Aagain in san jose.=0A=0Athe vertical axis is thousands of microsecon= ds.=0A=0AI'm farily comfortable that my NTP and my devices clocks aren't to= taly=0Abusted. I'm also comfortable with the idea that there's substantiall= y=0Ahigher variation=C2=A0 out there when you get out a of a single admistr= ative=0Adomain.=0A> I believe that 5 - 50 microseconds of accuracy is suffi= cient for triage.=C2=A0 In our proposal, we want three times: inbound netwo= rk path, the server processing time, or the outbound network path.=C2=A0 I = believe that for accurate triage, we will be able to say that the problem i= s in the inbound network path, the server, or the outbound network path eve= n if the clocks vary by 50 microseconds.=C2=A0 In my experience, the differ= ences between the 3 calculations which we want vary by quite a bit more tha= n 50 microseconds.=C2=A0=C2=A0=C2=A0I actually have quite a bit of data ava= ilable to prove this from running diagnostics with a number of companies an= d over the Internet in the last few years and I will do a paper (when I get= a free weekend!).=C2=A0=C2=A0=C2=A0I will discuss my findings with the IPP= M group as I believe this to be of interest to them.=0A>=0A> For those who = may be new to this discussion, they may care to look at our proposals:=0A>= =0A> http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-00= =0A>=0A>=0A> http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-= rt-needed-00=0A>=0A>=0A> http://tools.ietf.org/html/draft-elkins-v6ops-ipv6= -packet-sequence-needed-00=0A>=0A>=0A> http://www.ietf.org/id/draft-elkins-= v6ops-ipv6-pdm-recommended-usage-00.txt=0A>=0A>=0A> Thanks,=0A>=0A> Nalini = Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> www.insidethestack.= com=0A>=0A>=0A>=0A> ________________________________=0A> From: joel jaeggli= =0A> To: Nalini Elkins ; IPv6 Ops WG =0A> Sent: Thursday, August 1, 2013 6:45 AM= =0A> Subject: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00=0A>=0A>=0A> = Since I ran into you in the hall and the dicussion turned to ntp...=0A>=0A>= I'll try and be succinct, and as a non-expert in the time field this=0A> s= hould be taken with a grain of salt.=0A>=0A> The generic utility of a high-= resultion time-stamp is imho dodgey=0A> outside of situations where the clo= cks are deliberately syncronized and=0A> traceable to a common standard whe= ther the protocol used for this is ntp=0A> or ieee 1588 (or since this is t= he ietf PTPV2) . While this is tractable=0A> for devices in a single span o= f control, the agruement that ntp might be=0A> suffcient to make this timst= amp useful generically between two=0A> aribitratry devices where this funct= ionality may need to be enabled is=0A> imho a hard one to assert.=0A>=0A> I= t is a set of operational practice and discipline moreso than the=0A> choic= e of technology that allows for a high-resolution timestamp to have=0A> suf= ficient precision to be useful between hosts.=0A>=0A> joel =0A>=C2=A0 From mackermann@bcbsm.com Wed Aug 28 09:44: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 BAF3A21F9A3B for ; Wed, 28 Aug 2013 09:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, 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 9vt7IYGL48ls for ; Wed, 28 Aug 2013 09:44:39 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id C38C021F9AD2 for ; Wed, 28 Aug 2013 09:44:36 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id AC86E9ADA12 for ; Wed, 28 Aug 2013 11:44:33 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 17F4A9AD9E4; Wed, 28 Aug 2013 11:44:32 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 854C92F0057; Wed, 28 Aug 2013 12:36:24 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 764B92F0045; Wed, 28 Aug 2013 12:36:24 -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; Wed, 28 Aug 2013 12:44:31 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Wed, 28 Aug 2013 12:44:16 -0400 From: "Ackermann, Michael" To: joel jaeggli , Nalini Elkins , IPv6 Ops WG , "tsv-area@ietf.org" Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 Thread-Index: AQHOjwZk4Toj+UMKpk6NXKBhM7GJu5mpbISAgAFoJgCAABaksA== Date: Wed, 28 Aug 2013 16:44:15 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A7FCEDA@PWN401EA160.ent.corp.bcbsm.com> References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <521DCE46.6030501@bogus.com> In-Reply-To: <521DCE46.6030501@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20112.000 x-tm-as-result: No--62.189900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "joachim.fabini@tuwien.ac.at" , "ALFRED C \(AL\)" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 16:44:43 -0000 SGkgSm9lbA0KDQpNeSBmaXJzdCB0aG91Z2h0IGluIHJldmlld2luZyB5b3VycyBhbmQgb3Ro ZXIgY29tbWVudHMgb24gVGltZSBTeW5jaCwgaXMgdGhhdCB3ZSBzaG91bGQgYWxsIHRhbGsg bGl2ZSBhYm91dCB0aGlzIHNvbWUgZGF5LiAgICBUaGlzIGlzIGEgc3ViamVjdCB0aGF0IGhh cyBiZWVuIGltcG9ydGFudCB0byBtYW55IG9mIHVzIGZvciB5ZWFycyBhbmQgd2lsbCBBTFdB WVMgYmUgYSBjcml0aWNhbCBzdWNjZXNzIGZhY3RvciBpbiBpbXBsZW1lbnRpbmcgQU5ZIHJl c3BvbnNlIHRpbWUgbW9uaXRvcmluZyAgYW5kL29yIGRpYWdub3N0aWMgc29sdXRpb24uICAN Cg0KSSBjYW4gc2F5IGZyb20gb3VyIGV4cGVyaWVuY2UsIHdoZXJlIHdlIGhhdmUgMTIwIHNl cGFyYXRlIGVudGVycHJpc2VzLCB1c2luZyB0aGUgc2FtZSByZXNwb25zZSB0aW1lIG1vbml0 b3JpbmcgdG9vbHMgKHllcyBwbHVyYWwpLCB0aGF0IE5UUCwgSUYgYXJjaGl0ZWN0ZWQgcHJv cGVybHksIGNhbiBhbmQgZG9lcyB3b3JrLiAgICBUaGUgZGV2aWwgYXMgeW91IHNheSwgaXMg aW4gdGhlIElGLiAgIA0KDQpJZiwgbGlrZSB5b3Ugc2F5LCB0aGUgZW50aXJlIHJlc3BvbnNl IHRpbWUgbW9uaXRvcmluZyB1bml2ZXJzZSwgY29uc2lzdHMgb2YgT05FIG1hc3RlciByZWZl cmVuY2UgY2xvY2sgYW5kIGEgc2luZ2xlIE5UUCBEb21haW4sIGl0IGlzIHVubGlrZWx5IHRo YXQgdGhlIHRpbWUgc3luY2ggYWNjdXJhY2llcyByZXF1aXJlZCB3aWxsIGJlIGFjaGlldmVk LiAgVGhpcyBpcyBiZWNhdXNlIGVhY2ggY2FzY2FkZWQgTlRQIFJlZmVyZW5jZSwgY3JlYXRl cyBhIGRyb3AgaW4gdGhlIFN0cmF0dW0gSGllcmFyY2h5LiAgICAgSG93ZXZlciwgaWYgeW91 IG1hdGNoIHlvdXIgcmVxdWlyZWQgdGltZSBzeW5jIGFjY3VyYWNpZXMsIHdpdGggdGhlIHBy b3BlciBOVFAgYXJjaGl0ZWN0dXJlLCB3ZSBoYXZlIGZvdW5kIGl0IGlzIFZFUlkgYWNoaWV2 YWJsZS4gICAgSXQgbWF5IHJlcXVpcmUgIG11bHRpcGxlIE1BU1RFUiBDbG9ja3MgZ2VvZ3Jh cGhpY2FsbHkgZGlzcGVyc2VkIGZvciBlaXRoZXIgYWNjdXJhY3kgYW5kL29yIGJhY2t1cC1j b250aW5nZW5jeSBwdXJwb3Nlcy4gICAgVGhpcyB0b28gaXMgdmVyeSB2aWFibGUgYW5kIGFm Zm9yZGFibGUgdG9kYXksIGFuZCBtdWNoIG1vcmUgc28gd2hlbiB3ZSBkaWQgdGhpcyBzZXZl cmFsIHllYXJzIGFnby4gIA0KDQpJIGhhdmUgc2VlbiBzZXZlcmFsIHJlc3BvbnNlcyB3aGVy ZSB0aGUgdGltZSBzeW5jaCByZXF1aXJlbWVudHMgd2VyZSA1IHRvIDUwIG1pY3Jvc2Vjb25k cy4gICBPdXIgcmVxdWlyZW1lbnRzIHdlcmUgbm90IHRoaXMgdGlnaHQuICBJIGRvIGJlbGll dmUgdGhpcyBpcyBhY2hpZXZhYmxlIHRob3VnaCBhbmQgd2UgaGF2ZSBldmVuIGRvbmUgc29t ZSBkZXNpZ24vY29zdCBzY2VuYXJpb3MgZm9yIHdoYXQgaXQgd291bGQgdGFrZSB0byBtYWtl IHRoaXMgaGFwcGVuLiAgICBJIGhhdmUgaGVhcmQgb2Ygb3RoZXJzIGFscmVhZHkgZG9pbmcg dGhpcyB0b2RheS4gIA0KDQpNb3N0IG9mIG91ciBleHBlcmllbmNlIGlzIHdpdGggTlRQLCBi dXQgSSBhbHNvIGhhdmUgYW5kIGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgc2l0dWF0aW9ucyB3 aGVyZSB0aGUgSUVFRSBzb2x1dGlvbnMgYXJlIHRoZSBiZXR0ZXIgYW5zd2VyLiAgICBXaGF0 ZXZlciB3b3JrcyBiZXN0IGZvciBhIHBhcnRpY3VsYXIgc2l0dWF0aW9uLiAgDQoNClNvLCBJ IGJlbGlldmUgdGhhdCBieSBzaGFyaW5nIHBlcnRpbmVudCBpbmZvcm1hdGlvbiwgd2UgY2Fu IGFsbCBoZWxwIGVhY2ggb3RoZXIgYWNoaWV2ZSB0aGUgcmVxdWlyZWQgbGV2ZWxzIG9mIHRp bWUgc3luY2guICAgV2UgaGF2ZSBhIE5UUCBDb29rYm9vayBhbmQgb3RoZXIgb3BlcmF0aW9u YWwgZG9jdW1lbnRzL2V4cGVyaWVuY2VzIHRoYXQgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIHNo YXJlLCBpZiBpbnRlcmVzdCBleGlzdHMuICAgIExpa2UgcHJldmlvdXNseSBzdGF0ZWQsIHRo aXMgaXMgYW4gaXNzdWUgZm9yIHVzIGFsbCBhbmQgSSB3b3VsZCBsb29rIGZvcndhcmQgdG8g cmVzb2x2aW5nIGl0IHRvZ2V0aGVyIGluIGFueSBjYXBhY2l0eSB0aGF0IG1ha2VzIHNlbnNl LiANCg0KVGhhbmtzDQoNCk1pa2UNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygam9lbCBqYWVnZ2xpDQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAyOCwgMjAxMyA2OjE4IEFNDQpUbzogTmFsaW5pIEVsa2luczsgSVB2NiBPcHMg V0c7IHRzdi1hcmVhQGlldGYub3JnDQpDYzogam9hY2hpbS5mYWJpbmlAdHV3aWVuLmFjLmF0 OyBBTEZSRUQgQyAoQUwpOyB0cmFtbWVsbEB0aWsuZWUuZXRoei5jaA0KU3ViamVjdDogUmU6 IFt2Nm9wc10gZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtcGRtLXJlY29tbWVuZGVkLXVzYWdl LTAwDQoNCk9uIDgvMjcvMTMgNTo0OCBBTSwgTmFsaW5pIEVsa2lucyB3cm90ZToNCj4gSm9l bCwNCj4NCj4gVGhlIHN5bmNocm9uaXphdGlvbiBhbmQgZ3JhbnVsYXJpdHkgb2YgdGhlIHRp bWVzdGFtcHMgZm9yIG91ciBwcm9wb3NhbCBpcyBvbmUgb2YgdGhlIHR3byBvdXRzdGFuZGlu ZyBpc3N1ZXMuICAgSSB3aWxsIHRha2UgdXAgdGhlIG90aGVyIGlzc3VlIChpcyB0aGlzIHBy b3Bvc2FsIHVzZWZ1bCBmb3IgdGhlIEludGVybmV0PykgaW4gYSBzZXBhcmF0ZSB0aHJlYWQu DQo+DQo+IFdlIGhhdmUgYWxzbyBoYWQgc29tZSBkaXNjdXNzaW9ucyB3aXRoIHRoZSBmb2xr cyBpbiB0aGUgSVBQTSBncm91cCwgc28gSSBhbSBjb3B5aW5nIHRoYXQgd29ya2luZyBncm91 cCBvbiB0aGlzIHRocmVhZC4NCj4NCj4gVG8gcmVzdGF0ZSB0aGUgaXNzdWVzIGFzIEkgdW5k ZXJzdGFuZCB0aGVtIChwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nKToNCj4NCj4g MS4gICBUaW1lc3RhbXAgY29ycmVsYXRpb24gZGVwZW5kcyBvbiBib3RoIGVuZHMgYmVpbmcg c3luY2hyb25pemVkIHVzaW5nIGEgc3RhbmRhcmQgbWVjaGFuaXNtLg0KPiAyLiAgIFRoaXMg aXMgYSBxdWVzdGlvbiBvZiAnYmVzdCBwcmFjdGljZXMnLg0KPiAzLiAgIElzIHRoZSB0aW1l c3RhbXAgb2Ygc3VmZmljaWVudCBxdWFsaXR5IG9yIGdyYW51bGFyaXR5IHRvIGJlIHVzZWZ1 bC4NCj4NCj4gVGhlIGFuc3dlcnMgdG8gMS4gYW5kIDIuICBpcyB5ZXMuICAgT2YgY291cnNl LiAgIElmIHBlb3BsZSBmaW5kIHRoaXMga2luZCBvZiBkYXRhIHRvIGJlIG9mIHVzZSwgdGhl biB0aGV5IHdpbGwgc3luY2hyb25pemUuICBJdCBpcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQg YWN0aXZpdGllcyBvdGhlciB0aGFuIHRob3NlIHByb3Bvc2VkIGJ5IHVzIHJlcXVpcmUgdGlt ZSBzeW5jaHJvbml6YXRpb24uICAgU28sIGl0IGlzIHF1aXRlIGxpa2VseSB0aGF0IHBlb3Bs ZSBtYXkgYmUgZG9pbmcgdGhpcyBhbHJlYWR5Lg0KPg0KPiBUaGUgYW5zd2VyIHRvIDMuIGlz IGFuIGludGVyZXN0aW5nIG9uZS4gICBJIHdpbGwgY2l0ZSBhIHBhcGVyIGZyb20gRHIuIEpv YWNoaW0gRmFiaW5pLiAgSXQgaXMgYXZhaWxhYmxlIGF0Og0KPg0KPiBodHRwOi8vaWVlZXhw bG9yZS5pZWVlLm9yZy94cGwvYXJ0aWNsZURldGFpbHMuanNwP2FybnVtYmVyPTY1NTM1ODQN Cj4NCj4gVGhlIHNpZ25pZmljYW50IHBhc3NhZ2UgaXMgb24gcGFnZSA3Og0KPg0KPiAiTW9i aWxlIGNsaWVudCBhbmQgc2VydmVyIGFyZSBib3RoIGFjY3VyYXRlbHkgdGltZXN5bmNocm9u aXplZCB1c2luZyBFTS00MDZBIEdQUyBtb2R1bGVzIHdpdGggUFBTIHN1cHBvcnQuICAgIFRo ZSBSUzIzMiBsZXZlbCBjb252ZXJzaW9uIHJlcXVpcmVkIGZvciB0aGlzIEdQUyBtb2R1bGUg aXMgaW1wbGVtZW50ZWQgYnkgYSBTcGFya0Z1biA4MzM0IEdQUyBldmFsdWF0aW9uIGJvYXJk DQo+IHdoaWNoIGhhcyBiZWVuIGV4dGVuZGVkIGJ5IHRoZSBQUFMgY2lyY3VpdCBhcyBwcm9w b3NlZCBpbiBbOF0uIFRoZSBOZXR3b3JrIFRpbWUgUHJvdG9jb2wgRGFlbW9uIChudHApIHN5 bmNocm9uaXplcyBib3RoIGVuZHBvaW50cyBhY2N1cmF0ZWx5IHdpdGggZ2xvYmFsIHRpbWUg dXNpbmcgdGhlIGV2YWx1YXRpb24gYm9hcmTigJlzIGxldmVsLWNvbnZlcnRlZCBQUFMgYW5k IEdQUyB0aW1lIHNpZ25hbHMgYWNjZXNzZWQgYnkgdGhlIGtlcm5lbCB1c2luZyBuYXRpdmUg UlMyMzIgc2VyaWFsIGludGVyZmFjZXMuIFRlc3RzIG92ZXIgc2V2ZXJhbCB3ZWVrcyBoYXZl IHNob3duIHRoYXQgdGhpcyBzZXR1cCBjYW4gc3luY2hyb25pemUgdGhlIHN5c3RlbSBjbG9j ayBhY2N1cmF0ZWx5IGRvd24gdG8gNc68cyB0byBnbG9iYWwgdGltZS4gRXZlbiBpZiBkZXBs b3llZCBpbiBub25vcHRpbXVtIGNvbmRpdGlvbnMgKGluZG9vciwgMXN0IO+sgm9vciwgc3Ry ZWV0IHZpZXcgd2l0aCA2Le+sgm9vciBvcHBvc2l0ZSBidWlsZGluZyksIHRoZSBjbG9jayBh Y2N1cmFjeSBpcyBiZXR0ZXIgdGhhbiA1MM68cy4iIA0KbmV0d29yayBkZXZpY2VzIGFyZSBi eS1pbi1sYXJnZSBub3QgYnVpbHQgd2l0aCBlbWJlZGRlZCBHUFMuDQogDQpCeSB3YXkgb2Yg ZGVtb25zdHJhdGlvbiBvZiB0aGUgbGV2ZWwgb2YgbWVhc3Vlcm1lbnQgZXJyb3IgSSBleHBl Y3QuDQpKdW5pcGVyIFJQTSBjYW4gZG8gYXNpYyBiYXNlZCB0aW1lc3RhbXBpbmcgb24gbWVh c3VyZW1lbnQgdHJhZmZpYyBiZXR3ZWVuIHR3byBkZXZpY2VzLiBJIGhhdmUgYSBwYXRoLCB0 aGUgbGVuZ3RoIG9mIHdoaWNoIGRvZXMgbm90IHZhcnkgYnkgbXVjaCAoaXQncyBhIHdhdmUt bGVuZ3RoIGJldHdlZW4gc2FuIGpvc2UgYW5kIGFzaGJ1cm4gdmlyZ2luaWEpLiB0aGUgcm91 dGVycyBkZXJpdmUgdGltZSBmcm9tIGEgY2x1c3RlcmVkIG9mIHBlZXJlZCBzdHJhdHVtIDIg c2VydmVycyB3aGljaCBpbiB0dXJuIGFyZSBjbGllbnRzIG9mIHN0cmF0dW0tMSBzb3VyY2Vz IHRoYXQgYXJlIHRyYWNlYWJsZSB0byBOSVNULiANCg0KaW4gdGhlIGZvbGxvd2luZyBncmFw aDoNCg0KaHR0cDovL2kuaW1ndXIuY29tL0FrRFJzOUQucG5nDQoNCnRoZSB0b3AgbGluZSBp cyB0aGUgUlRUIGFzIG1lYXN1cmVkIGJ5IHRoZSBzZW5kaW5nIHJvdXRlci4NCg0KdGhlIGdy ZWVuIGxpbmUgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdGltZXN0YW1wIGFwcGxp ZWQgYnkgdGhlIHJlY2l2ZWluZyByb3V0ZXIgaW4gYXNoYnVybiBhbmQgdGhlIHRpbWVzdGFt cCBhcHBsaWVkIGJ5IHRoZSBzZW5kaW5nIHJvdXRlciwgYW5kIHRoZSByZWRsaW5lIGlzIHRo ZSBkaWZmZXJuY2UgYmV0d2VlbiB0aGUgYXNoYnVybiByb3V0ZXIgc2VuZGluZyB0aW1lc3Rh bXAgYW5kIHRoZSB0aW1lc3RhbXAgZ2VucmF0ZWQgd2hlbiB0aGUgcGFja2V0IGlzIHJlY2ll dmVkIGFnYWluIGluIHNhbiBqb3NlLg0KDQp0aGUgdmVydGljYWwgYXhpcyBpcyB0aG91c2Fu ZHMgb2YgbWljcm9zZWNvbmRzLg0KDQpJJ20gZmFyaWx5IGNvbWZvcnRhYmxlIHRoYXQgbXkg TlRQIGFuZCBteSBkZXZpY2VzIGNsb2NrcyBhcmVuJ3QgdG90YWx5IGJ1c3RlZC4gSSdtIGFs c28gY29tZm9ydGFibGUgd2l0aCB0aGUgaWRlYSB0aGF0IHRoZXJlJ3Mgc3Vic3RhbnRpYWxs eSBoaWdoZXIgdmFyaWF0aW9uICBvdXQgdGhlcmUgd2hlbiB5b3UgZ2V0IG91dCBhIG9mIGEg c2luZ2xlIGFkbWlzdHJhdGl2ZSBkb21haW4uDQo+IEkgYmVsaWV2ZSB0aGF0IDUgLSA1MCBt aWNyb3NlY29uZHMgb2YgYWNjdXJhY3kgaXMgc3VmZmljaWVudCBmb3IgdHJpYWdlLiAgSW4g b3VyIHByb3Bvc2FsLCB3ZSB3YW50IHRocmVlIHRpbWVzOiBpbmJvdW5kIG5ldHdvcmsgcGF0 aCwgdGhlIHNlcnZlciBwcm9jZXNzaW5nIHRpbWUsIG9yIHRoZSBvdXRib3VuZCBuZXR3b3Jr IHBhdGguICBJIGJlbGlldmUgdGhhdCBmb3IgYWNjdXJhdGUgdHJpYWdlLCB3ZSB3aWxsIGJl IGFibGUgdG8gc2F5IHRoYXQgdGhlIHByb2JsZW0gaXMgaW4gdGhlIGluYm91bmQgbmV0d29y ayBwYXRoLCB0aGUgc2VydmVyLCBvciB0aGUgb3V0Ym91bmQgbmV0d29yayBwYXRoIGV2ZW4g aWYgdGhlIGNsb2NrcyB2YXJ5IGJ5IDUwIG1pY3Jvc2Vjb25kcy4gIEluIG15IGV4cGVyaWVu Y2UsIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSAzIGNhbGN1bGF0aW9ucyB3aGljaCB3 ZSB3YW50IHZhcnkgYnkgcXVpdGUgYSBiaXQgbW9yZSB0aGFuIDUwIG1pY3Jvc2Vjb25kcy4g ICBJIGFjdHVhbGx5IGhhdmUgcXVpdGUgYSBiaXQgb2YgZGF0YSBhdmFpbGFibGUgdG8gcHJv dmUgdGhpcyBmcm9tIHJ1bm5pbmcgZGlhZ25vc3RpY3Mgd2l0aCBhIG51bWJlciBvZiBjb21w YW5pZXMgYW5kIG92ZXIgdGhlIEludGVybmV0IGluIHRoZSBsYXN0IGZldyB5ZWFycyBhbmQg SSB3aWxsIGRvIGEgcGFwZXIgKHdoZW4gSSBnZXQgYSBmcmVlIHdlZWtlbmQhKS4gICBJIHdp bGwgZGlzY3VzcyBteSBmaW5kaW5ncyB3aXRoIHRoZSBJUFBNIGdyb3VwIGFzIEkgYmVsaWV2 ZSB0aGlzIHRvIGJlIG9mIGludGVyZXN0IHRvIHRoZW0uDQo+DQo+IEZvciB0aG9zZSB3aG8g bWF5IGJlIG5ldyB0byB0aGlzIGRpc2N1c3Npb24sIHRoZXkgbWF5IGNhcmUgdG8gbG9vayBh dCBvdXIgcHJvcG9zYWxzOg0KPg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1lbGtpbnMtNm1hbi1pcHY2LXBkbS1kZXN0LW9wdGlvbi0wMA0KPg0KPg0KPiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1lbmQtdG8tZW5k LXJ0LW5lZWRlDQo+IGQtMDANCj4NCj4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtcGFja2V0LXNlcXVlbmNlLW5lZQ0KPiBkZWQtMDAN Cj4NCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1lbGtpbnMtdjZvcHMtaXB2 Ni1wZG0tcmVjb21tZW5kZWQtdXNhZ2UtMA0KPiAwLnR4dA0KPg0KPg0KPiBUaGFua3MsDQo+ DQo+IE5hbGluaSBFbGtpbnMNCj4gSW5zaWRlIFByb2R1Y3RzLCBJbmMuDQo+ICg4MzEpIDY1 OS04MzYwDQo+IHd3dy5pbnNpZGV0aGVzdGFjay5jb20NCj4NCj4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogam9lbCBqYWVnZ2xpIDxqb2VsamFA Ym9ndXMuY29tPg0KPiBUbzogTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0 aGVzdGFjay5jb20+OyBJUHY2IE9wcyBXRyANCj4gPHY2b3BzQGlldGYub3JnPg0KPiBTZW50 OiBUaHVyc2RheSwgQXVndXN0IDEsIDIwMTMgNjo0NSBBTQ0KPiBTdWJqZWN0OiBkcmFmdC1l bGtpbnMtdjZvcHMtaXB2Ni1wZG0tcmVjb21tZW5kZWQtdXNhZ2UtMDANCj4NCj4NCj4gU2lu Y2UgSSByYW4gaW50byB5b3UgaW4gdGhlIGhhbGwgYW5kIHRoZSBkaWN1c3Npb24gdHVybmVk IHRvIG50cC4uLg0KPg0KPiBJJ2xsIHRyeSBhbmQgYmUgc3VjY2luY3QsIGFuZCBhcyBhIG5v bi1leHBlcnQgaW4gdGhlIHRpbWUgZmllbGQgdGhpcyANCj4gc2hvdWxkIGJlIHRha2VuIHdp dGggYSBncmFpbiBvZiBzYWx0Lg0KPg0KPiBUaGUgZ2VuZXJpYyB1dGlsaXR5IG9mIGEgaGln aC1yZXN1bHRpb24gdGltZS1zdGFtcCBpcyBpbWhvIGRvZGdleSANCj4gb3V0c2lkZSBvZiBz aXR1YXRpb25zIHdoZXJlIHRoZSBjbG9ja3MgYXJlIGRlbGliZXJhdGVseSBzeW5jcm9uaXpl ZCANCj4gYW5kIHRyYWNlYWJsZSB0byBhIGNvbW1vbiBzdGFuZGFyZCB3aGV0aGVyIHRoZSBw cm90b2NvbCB1c2VkIGZvciB0aGlzIA0KPiBpcyBudHAgb3IgaWVlZSAxNTg4IChvciBzaW5j ZSB0aGlzIGlzIHRoZSBpZXRmIFBUUFYyKSAuIFdoaWxlIHRoaXMgaXMgDQo+IHRyYWN0YWJs ZSBmb3IgZGV2aWNlcyBpbiBhIHNpbmdsZSBzcGFuIG9mIGNvbnRyb2wsIHRoZSBhZ3J1ZW1l bnQgdGhhdCANCj4gbnRwIG1pZ2h0IGJlIHN1ZmZjaWVudCB0byBtYWtlIHRoaXMgdGltc3Rh bXAgdXNlZnVsIGdlbmVyaWNhbGx5IA0KPiBiZXR3ZWVuIHR3byBhcmliaXRyYXRyeSBkZXZp Y2VzIHdoZXJlIHRoaXMgZnVuY3Rpb25hbGl0eSBtYXkgbmVlZCB0byANCj4gYmUgZW5hYmxl ZCBpcyBpbWhvIGEgaGFyZCBvbmUgdG8gYXNzZXJ0Lg0KPg0KPiBJdCBpcyBhIHNldCBvZiBv cGVyYXRpb25hbCBwcmFjdGljZSBhbmQgZGlzY2lwbGluZSBtb3Jlc28gdGhhbiB0aGUgDQo+ IGNob2ljZSBvZiB0ZWNobm9sb2d5IHRoYXQgYWxsb3dzIGZvciBhIGhpZ2gtcmVzb2x1dGlv biB0aW1lc3RhbXAgdG8gDQo+IGhhdmUgc3VmZmljaWVudCBwcmVjaXNpb24gdG8gYmUgdXNl ZnVsIGJldHdlZW4gaG9zdHMuDQo+DQo+IGpvZWwNCj4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZv cHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHMNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24g aXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9uIGlz IGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNjbG9z dXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQu IFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRlbGVw aG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3MgQmx1 ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hpZ2Fu IGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNlZXMg b2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo= From joelja@bogus.com Wed Aug 28 11:27: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 50CE621E8054 for ; Wed, 28 Aug 2013 11:27: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 npeLl0rs-hbw for ; Wed, 28 Aug 2013 11:27:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B7F1E21E8050 for ; Wed, 28 Aug 2013 11:27:50 -0700 (PDT) Received: from mb-aye.corp.zynga.com (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 r7SIRmpL098097 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 28 Aug 2013 18:27:49 GMT (envelope-from joelja@bogus.com) Message-ID: <521E411F.9090203@bogus.com> Date: Wed, 28 Aug 2013 11:27:43 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "George, Wes" , "v6ops@ietf.org" References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A39@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A39@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1 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, 28 Aug 2013 18:27:49 +0000 (UTC) Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:27:51 -0000 On 8/21/13 6:19 AM, George, Wes wrote: > As to whether this is ready for IETF LC or should be adopted by the WG, no it's not ready, and I don't know if it should be adopted. Specifically, I think that guidance for implementers about use of fragments is useful, especially in documenting current behavior on the network and the justifications for it. However, we're starting to get a lot of overlap between the drafts dealing with fragmentation, whether it should be deprecated, whether we should simply provide a caveat implementer statement on using fragments but leave the standard alone, etc. It makes matters worse when one considers fragmented packets together with large headers, since at least some of the technical considerations overlap. Imho this is the first of these documents in recent times. As an author I don't see the goal as guidance to implementors, I see it as guidance from operators. > To avoid confusion, I think we need to decide which direction we want to go before advancing drafts on the matter. I agree that the plan should be cohernent. > If indeed we want implementers to read and heed the advice in this draft (or other related drafts), we should make sure we have a cohesive message. Right now we have jus > tifications and operational observations spread across at least this draft and draft-bonica-6man-frag-deprecate (which I'd argue discusses the operational considerations much more robustly than this document), and possibly even draft-generic-6man-tunfrag. long-headers is also in this space for relatively similar reasons. > > > > From marka@isc.org Wed Aug 28 15:08: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 C72C021F9C7E for ; Wed, 28 Aug 2013 15:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 Kgu3cL+HSyGM for ; Wed, 28 Aug 2013 15:08:15 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E8FF011E81CA for ; Wed, 28 Aug 2013 15:08:13 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D6821C94BD; Wed, 28 Aug 2013 22:08:00 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1377727693; bh=XPzNDnDjJy+ecAw7+MD45G66xlz1GKwYrGvt3XYfqG0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ing5/BDl9XyFJ6n6iQE96yDi5gEqKesEETc+D3wbaR3MyyrfQDR33HGvaDsiEaQ06 ezGVYir5fDGFh5VMIKp8ulX/yWCRq88tZgpElAL0mi0EMrKwp7PMDhoWRp9IgRs3/q Hx9jfgeo/pOan0rY8OK2vz3+DyFX0TnKe8Zmi4CE= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 28 Aug 2013 22:08:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4EE1C160459; Wed, 28 Aug 2013 22:08:43 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1ED86160446; Wed, 28 Aug 2013 22:08:43 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id D397938F3E57; Thu, 29 Aug 2013 08:07:55 +1000 (EST) To: joel jaeggli From: Mark Andrews References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A39@PRVPEXVS15.corp.twcable.com> <521E411F.9090203@bogus.com> In-reply-to: Your message of "Wed, 28 Aug 2013 11:27:43 -0700." <521E411F.9090203@bogus.com> Date: Thu, 29 Aug 2013 08:07:55 +1000 Message-Id: <20130828220755.D397938F3E57@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 22:08:20 -0000 Please, please, please. Use line breaks. Use blank lines. I really can't tell without going into a editor and finding the end of lines who said what. In message <521E411F.9090203@bogus.com>, joel jaeggli writes: > On 8/21/13 6:19 AM, George, Wes wrote: > > As to whether this is ready for IETF LC or should be adopted by the WG, no > it's not ready, and I don't know if it should be adopted. Specifically, I thi > nk that guidance for implementers about use of fragments is useful, especiall > y in documenting current behavior on the network and the justifications for i > t. However, we're starting to get a lot of overlap between the drafts dealing > with fragmentation, whether it should be deprecated, whether we should simpl > y provide a caveat implementer statement on using fragments but leave the sta > ndard alone, etc. It makes matters worse when one considers fragmented packet > s together with large headers, since at least some of the technical considera > tions overlap. > Imho this is the first of these documents in recent times. As an author > I don't see the goal as guidance to implementors, I see it as guidance > from operators. > > To avoid confusion, I think we need to decide which direction we want to g > o before advancing drafts on the matter. > I agree that the plan should be cohernent. > > If indeed we want implementers to read and heed the advice in this draft (o > r other related drafts), we should make sure we have a cohesive message. Righ > t now we have jus > > tifications and operational observations spread across at least this draft > and draft-bonica-6man-frag-deprecate (which I'd argue discusses the operatio > nal considerations much more robustly than this document), and possibly even > draft-generic-6man-tunfrag. > long-headers is also in this space for relatively similar reasons. > > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nalini.elkins@insidethestack.com Thu Aug 29 05:47: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 3B1DB11E8108 for ; Thu, 29 Aug 2013 05:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKPocaMCz7T4 for ; Thu, 29 Aug 2013 05:47:37 -0700 (PDT) Received: from nm3-vm3.access.bullet.mail.gq1.yahoo.com (nm3-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDB721F9EF8 for ; Thu, 29 Aug 2013 05:47:37 -0700 (PDT) Received: from [216.39.60.171] by nm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 29 Aug 2013 12:47:36 -0000 Received: from [216.39.60.250] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 29 Aug 2013 12:47:36 -0000 Received: from [127.0.0.1] by omp1021.access.mail.gq1.yahoo.com with NNFMP; 29 Aug 2013 12:47:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 121015.21741.bm@omp1021.access.mail.gq1.yahoo.com Received: (qmail 86216 invoked by uid 60001); 29 Aug 2013 12:47:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377780455; bh=srL6ywz6d0+CCUSmlcFicZzKmk+MISUmk0goAJx1zWI=; 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=FCrD1sPmERmufWACeUEdgfTkFT+rZaoKh97vbjCZLt9ZO/6uq1yjnW4p8QKMdm9+AKzdxDrJ/KpzFOSoI7L4mFycb77KewOV3jKUQbZPRANoX28nMsD5Ech5QzWPNpG4RmqUkz9zechud9+eVs+hu+5ZgoK/5CvKo8AuOO775Cs= X-YMail-OSG: QCDRpxUVM1mvMiAEEEPIHz40LptOmjcoNI2ZcvcY5phaa1j vYw2LdXRCTMdSikE5AFReJG.IxNUGULKXt6jqDRBY.bRilYP7Dbuui4.N88S Tft8XznKJPS.Mti34WDaI6nYiwpqrGJbDnWb301Ae25xi_9AJCM4uEUTMOTq gBBcQri.3ySCekLwiJVwpN5vMXFHPNq.gTSxhysx8FP6e.L2oYCGRjuYJOdf XiuFAQimBrepPV08QJEqOQ6dr1Loaf_wE5deatuiJtmjpXBlCuwNs08KvGjv H.oY4N2XOCQWObm7ygmdS6F8MHB5Z9LPEwNXRMnHxkd3dhJSBatsuQDa_h4Q 9SzKkIrJfFTGJPNOmXy28WpP4Cm9jr8JQ.TZxp82_23JpY9k1dWwI.NVfbhs 6GqIl2yZ9x8bRzLavcBCstMIQ.dMBszOs_nFHi1upzWbqGrtdzz6D7MsuUmP si01mwFhgTnUs3ywOB5pUoSRr8eA60igDjZS1R46kHFSx7C53ZYmSqnj76uv QYfSi_JeCxb_qmz_7u0_EPjp3kxFnrg6lVFWnb6rts4JVY8nEAMYG2MMZYbt psSl9td.37CORuxljH1e4kWQIFAIvPR7VDZudoAyJM9xFSGuQ5HTZA1wwvfr eLX6O0jD0Ph2yoke9nTK3lqn6WImOZiVcwtinCCOZ_mUBJj5wtSLOnHbgkQU NqvV0u2Kf.mHimZqtX1zQgJWMtULb3ScMns3R4IjJlmxVRFD9Uo85NKoJsUB kgnLQYes9o4SfEtE- Received: from [70.192.203.170] by web2805.biz.mail.ne1.yahoo.com via HTTP; Thu, 29 Aug 2013 05:47:35 PDT X-Rocket-MIMEInfo: 002.001, UGxlYXNlIHRha2UgYSBsb29rIGF0OgoKaHR0cDovL3d3dy5yaXBlLm5ldC9kYXRhLXRvb2xzL3N0YXRzL3R0bS90ZXN0LXRyYWZmaWMtbWVhc3VyZW1lbnQtc2VydmljZQoKCk5vdGUgdGhhdCB3aGF0IHRoZXkgcHJvdmlkZSBpczoKCsKgwqDCoMKgKiBOVFAtc2VydmVyLCB0aGUgdGVzdC1ib3hlcyBjYW4gYWN0IGEgc3RyYXR1bSAxIHNlcnZlciBmb3IgdGhlIG1hY2hpbmVzIG9uIHlvdXIgbmV0d29yaywgcHJvdmlkaW5nIHRpbWUtc3RhbXBzIHdpdGggYW4gYWNjdXJhY3kgb2YgMTAgbWljcm9zZWNvbmRzLgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>, <521DCE46.6030501@bogus.com> <2845723087023D4CB5114223779FA9C83BF8C4F1@njfpsrvexg8.research.att.com> <521EB4A2.2060006@bogus.com> Message-ID: <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Thu, 29 Aug 2013 05:47:35 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , "MORTON JR., ALFRED C \(AL\)" , IPv6 Ops WG , "tsv-area@ietf.org" In-Reply-To: <521EB4A2.2060006@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "joachim.fabini@tuwien.ac.at" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 12:47:50 -0000 Please take a look at:=0A=0Ahttp://www.ripe.net/data-tools/stats/ttm/test-t= raffic-measurement-service=0A=0A=0ANote that what they provide is:=0A=0A=A0= =A0=A0=A0* NTP-server, the test-boxes can act a stratum 1 server for the ma= chines on your network, providing time-stamps with an accuracy of 10 micros= econds.=0A=0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659= -8360=0Awww.insidethestack.com=A0 From abdussalambaryun@gmail.com Tue Aug 27 04: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 98AED11E8291; Tue, 27 Aug 2013 04:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 DrN20Lb3xosL; Tue, 27 Aug 2013 04:05:22 -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 3A98511E8184; Tue, 27 Aug 2013 04:05:22 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so4683661pab.41 for ; Tue, 27 Aug 2013 04:05: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=VlByFy4T2cgiuaWQD+JoVqZszIDEHJe42A76L/OYdPI=; b=VBGfehRXiWM0PAMGIg8BmmVN42+R3naAORkRS6S1vacbqQUdVjl04ODYCyXWMhqnee EDCrszL/PUc+E6DdOdiWTq5f4/kOnzICDrvXDhZT9QS5mtWqnqUgsCdBLI8Y4ZE+yKVl tQdifpMogL2HjBaW4qiSAZikGcMPLLC8AIdSZnvPhmSYi7IVaIOZBagC65nb8OLpwnYW ECvoJcri732pQLRu/93WB5VlRdNfI9vZmUC9jBwe+5SbMPmaM7tYJeTQHydI0mY6lH3R /urFuzScE6iD9X3FxjC1mmAvLSn2gujS+Pc41RG45y2RFeVVz7ZH6cH4s8K5uSUM18aJ Zw8g== MIME-Version: 1.0 X-Received: by 10.66.218.166 with SMTP id ph6mr20124296pac.28.1377601521748; Tue, 27 Aug 2013 04:05:21 -0700 (PDT) Received: by 10.68.195.168 with HTTP; Tue, 27 Aug 2013 04:05:21 -0700 (PDT) In-Reply-To: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> Date: Tue, 27 Aug 2013 21:05:21 +1000 Message-ID: From: Abdussalam Baryun To: ietf Content-Type: multipart/alternative; boundary=047d7b5db49a589f3604e4ebd9d6 X-Mailman-Approved-At: Thu, 29 Aug 2013 08:05:21 -0700 Cc: v6ops@ietf.org, "iesg@ietf.org" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Aug 2013 11:05:24 -0000 --047d7b5db49a589f3604e4ebd9d6 Content-Type: text/plain; charset=ISO-8859-1 Reviewer: Abdussalam Baryun Date: 26.08.2013 As per the IESG request for review dated 19.08.2013 ++++++++++++++++++++++++++++++++++++ I support the draft, thanks, below are my comments, Overall> The draft is about 3GPP Mobile Devices but the draft has no normative reference to such device. The title of the draft SHOULD mention that it is general profile or a proposal, where the abstract says *specifies an IPv6 profile* which means not general, so the title SHOULD say *An IPv6 profile*. Also the draft does not consider Mobile IP issues nor RFC5213 into requirements. From the doc the reviewer is not sure does the draft consider MANET issues or not needed for such devices or such connections? Abstract> This document specifies an IPv6 profile for 3GPP mobile devices. AB> suggest> this document defines an IPv6 profile.... The document is missing an applicability statement section, which may be found in one paragraph in section 1.1, but the reviewer would like more details because the document is some how saying it is general requirements. AB On Mon, Aug 19, 2013 at 11:52 PM, The IESG wrote: > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > 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 file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > --047d7b5db49a589f3604e4ebd9d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reviewer: Abdussalam Baryun
Dat= e: 26.08.2013

As per the IESG request = for review dated 19.08.2013
+++++++++++++++++++++++++++++++= +++++

I support the draft, thanks, below are my c= omments,

Overall> The draft is abou= t 3GPP Mobile Devices but the draft has no normative reference to such devi= ce. The title of the draft SHOULD mention that it is general profile or a p= roposal, where the abstract says *specifies an IPv6 profile* which means no= t general, so the title SHOULD say *An IPv6 profile*. Also the draft does n= ot consider Mobile IP issues nor RFC5213 into requirements. From the doc th= e reviewer is not sure does the draft consider MANET issues or not needed f= or such devices or such connections?


Abstract> This document specifies an IPv6 profile for 3GPP mobile device=
s.


AB> suggest> this document defines an IPv6= profile....

The document is missing a= n applicability statement section, which may be found in one paragraph in s= ection 1.1, but the reviewer would like more details because the document i= s some how saying it is general requirements.

AB

On Mon, Aug 19, 2013 at 11:52 PM, The IESG= <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices&#= 39;
=A0 <draft-ietf-v6ops-mobile-device-profile-04.txt> as Informational = RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09= -02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In eith= er case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=A0 =A0This document specifies an IPv6 profile for 3GPP mobile devices. =A0= It
=A0 =A0lists the set of features a 3GPP mobile device is to be compliant =A0 =A0with to connect to an IPv6-only or dual-stack wireless network
=A0 =A0(including 3GPP cellular network and IEEE 802.11 network).

=A0 =A0This document defines a different profile than the one for general =A0 =A0connection to IPv6 cellular networks defined in
=A0 =A0[I-D.ietf-v6ops-rfc3316bis]. =A0In particular, this document identif= ies
=A0 =A0also features to deliver IPv4 connectivity service over an IPv6-only=
=A0 =A0transport.

=A0 =A0Both hosts and devices with capability to share their WAN (Wide Area=
=A0 =A0Network) connectivity are in scope.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops= -mobile-device-profile/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-iet= f-v6ops-mobile-device-profile/ballot/


No IPR declarations have been submitted directly on this I-D.



--047d7b5db49a589f3604e4ebd9d6-- From acmorton@att.com Thu Aug 29 09: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 437E111E812E; Thu, 29 Aug 2013 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 X+vw431xz0s2; Thu, 29 Aug 2013 09:54:12 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6EC11E812C; Thu, 29 Aug 2013 09:54:12 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id EB7F0120AA5; Thu, 29 Aug 2013 12:54:08 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (njfpsrvexg8.research.att.com [135.207.178.36]) by mail-blue.research.att.com (Postfix) with ESMTP id E9F87F019A; Thu, 29 Aug 2013 12:54:11 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::a44a:8177:9a5d:ac00]) by njfpsrvexg8.research.att.com ([fe80::a44a:8177:9a5d:ac00%15]) with mapi; Thu, 29 Aug 2013 12:54:11 -0400 From: "MORTON JR., ALFRED C (AL)" To: Nalini Elkins , joel jaeggli , IPv6 Ops WG , "tsv-area@ietf.org" Date: Thu, 29 Aug 2013 12:54:10 -0400 Thread-Topic: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 Thread-Index: Ac6ktfoFSkXMwQUtR8Csn7GsSPkvSAAIVL6w Message-ID: <2845723087023D4CB5114223779FA9C83C1988F1@njfpsrvexg8.research.att.com> References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>, <521DCE46.6030501@bogus.com> <2845723087023D4CB5114223779FA9C83BF8C4F1@njfpsrvexg8.research.att.com> <521EB4A2.2060006@bogus.com> <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 29 Aug 2013 09:57:44 -0700 Cc: "joachim.fabini@tuwien.ac.at" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:54:17 -0000 Hi Nalini, thanks for the reference. I think there may be additional sources of measurement timestamp error. For example,=20 I think the 10us spec is for the (old?) RIPE TTM device timestamps in NTP m= essages. Another device uses these timestamps and previous info to steer its clock (= +error). The measurement system mechanics of reading time and inserting timestamps=20 in messages (+error). But under the right conditions, 50us still seems do-able to me. Al > -----Original Message----- > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > Sent: Thursday, August 29, 2013 8:48 AM > To: joel jaeggli; MORTON JR., ALFRED C (AL); IPv6 Ops WG; tsv- > area@ietf.org > Cc: joachim.fabini@tuwien.ac.at; trammell@tik.ee.ethz.ch > Subject: Re: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 >=20 > Please take a look at: >=20 > http://www.ripe.net/data-tools/stats/ttm/test-traffic-measurement-service >=20 >=20 > Note that what they provide is: >=20 > =A0=A0=A0=A0* NTP-server, the test-boxes can act a stratum 1 server for t= he > machines on your network, providing time-stamps with an accuracy of 10 > microseconds. >=20 > Thanks, >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com From joelja@bogus.com Thu Aug 29 10:48: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 BE1CE21E809B; Thu, 29 Aug 2013 10:48: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=[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 ooE1AnmBgOfO; Thu, 29 Aug 2013 10:48:36 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CA87F21E80A3; Thu, 29 Aug 2013 10:48:36 -0700 (PDT) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r7THmVfD012506 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 29 Aug 2013 17:48:32 GMT (envelope-from joelja@bogus.com) Message-ID: <521F896A.9090305@bogus.com> Date: Thu, 29 Aug 2013 10:48:26 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Nalini Elkins , "MORTON JR., ALFRED C \(AL\)" , IPv6 Ops WG , "tsv-area@ietf.org" References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>, <521DCE46.6030501@bogus.com> <2845723087023D4CB5114223779FA9C83BF8C4F1@njfpsrvexg8.research.att.com> <521EB4A2.2060006@bogus.com> <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 29 Aug 2013 17:48:34 +0000 (UTC) Cc: "joachim.fabini@tuwien.ac.at" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 17:48:37 -0000 On 8/29/13 5:47 AM, Nalini Elkins wrote: > Please take a look at: > > http://www.ripe.net/data-tools/stats/ttm/test-traffic-measurement-service > > > Note that what they provide is: > > * NTP-server, the test-boxes can act a stratum 1 server for the machines on your network, providing time-stamps with an accuracy of 10 microseconds. With respect to the IETF 87 presentation/discussion I think is is a dicussion of the quality of time and it relationship to the general utility of of pdm optional header, not the availability of specific point solutions. With respect to the design of TTM the claimed timestamp accuracy is associated with packets emitted by the TTM not other devices associated with them which is course subject to the same general constraints other ntp deployments. > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > From nalini.elkins@insidethestack.com Thu Aug 29 18:36: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 B7D3421E8051 for ; Thu, 29 Aug 2013 18:36: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 B-uObBPyFL6o for ; Thu, 29 Aug 2013 18:36:18 -0700 (PDT) Received: from nm9-vm3.access.bullet.mail.gq1.yahoo.com (nm9-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7047D11E8192 for ; Thu, 29 Aug 2013 18:36:16 -0700 (PDT) Received: from [216.39.60.166] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Aug 2013 01:36:15 -0000 Received: from [216.39.60.160] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 Aug 2013 01:36:15 -0000 Received: from [127.0.0.1] by omp1026.access.mail.gq1.yahoo.com with NNFMP; 30 Aug 2013 01:36:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 297799.59358.bm@omp1026.access.mail.gq1.yahoo.com Received: (qmail 16051 invoked by uid 60001); 30 Aug 2013 01:36:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377826574; bh=JyMZVr5TrRe11wAMzSViK9pyRsg5gL52tucqFtwBU3g=; 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=6HSUraSwkSg+6wSs6ped+/YUTN+qErWZlDzSZ/8Cpai4ikWgQ7kNRn3KIvuxDF6vmn6SPDq7MebohjmgXKYldlVWwUEGoG+qagOaOATilZymPxgtrkr0k3mge6mzd0uzHBDWOmyRejZcXIcj7hNZIS/rD+hyxSMcJRjfnLI9Sng= X-YMail-OSG: p6h4xIUVM1mVG7Oc1zn6jfL.KfPlKbx6uQam9lWYVGTreWT aIEzu9HY8gSdCwlox6_dQ8Q09yN2duiFMgOjJw_NRoMaAcBqMGh0hiUnc2Zs fxo8EV1QPBNrbuSKIkdjyGSiNpsm3gESqIMPv_H_Y55jh2WxWZuq_gF4mPps eFIaH6VC8lWFkRKG7tuSUKZY.sINQp4ykInjiFKumSHeiGQEYaSJkOUED8gh i0xOC52EMrOSKQ.w3EucxhJrczvp0dtqXmU.H3lBLVEfFa760Y3BXbZUNCsu gblWS4ojJz1xBxoj_adN7jCAujXgO5P.wNW_ahL06l0av2gzX_ZabmUhDJBa uSqNe8TFprgd5oSLJgMLmE0xE7CMQDbRcfyo3OOZwVZhODspB1Ge0BOV_kXY GabCOmJC3CsF8BnZAP2Rn9eLCkT3wDvcTM3LFotSwBD7FhYwRGXzFZiyD.LU eY_ZAPvI1HxDi9y8UbwdSRUYfpS86DdlP_ZBIZ.KdkeP66iyE2FQQvGXOXDG a6tglkKaJAtVMear2QZ.Fge8y_9vd3ZpIwy.kWEGkGe12lb_TNWD0ALuOGLl zgMbxnBUgQY5YwOMXIR2OQZ9R6Pve6JWm5m2q62UsfY0RBklqGaNgwfzSn2a CuK4oPk1.ZdfknQbzonaIvGP7gIsfquM8bunhWlxsTllmsJv.qNbPj.ToYhx BpavB428- Received: from [70.198.65.73] by web2806.biz.mail.ne1.yahoo.com via HTTP; Thu, 29 Aug 2013 18:36:14 PDT X-Rocket-MIMEInfo: 002.001, CgoKT24gOC8yOS8xMyA1OjQ3IEFNLCBOYWxpbmkgRWxraW5zIHdyb3RlOgo.IFBsZWFzZSB0YWtlIGEgbG9vayBhdDoKPgo.IGh0dHA6Ly93d3cucmlwZS5uZXQvZGF0YS10b29scy9zdGF0cy90dG0vdGVzdC10cmFmZmljLW1lYXN1cmVtZW50LXNlcnZpY2UKPgo.Cj4gTm90ZSB0aGF0IHdoYXQgdGhleSBwcm92aWRlIGlzOgo.Cj7CoCDCoCAgKiBOVFAtc2VydmVyLCB0aGUgdGVzdC1ib3hlcyBjYW4gYWN0IGEgc3RyYXR1bSAxIHNlcnZlciBmb3IgdGhlIG1hY2hpbmVzIG9uIHlvdXIgbmV0d29yaywgcHJvdmkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>, <521DCE46.6030501@bogus.com> <2845723087023D4CB5114223779FA9C83BF8C4F1@njfpsrvexg8.research.att.com> <521EB4A2.2060006@bogus.com> <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <521F896A.9090305@bogus.com> Message-ID: <1377826574.11519.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Thu, 29 Aug 2013 18:36:14 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , "MORTON JR., ALFRED C \(AL\)" , IPv6 Ops WG , "tsv-area@ietf.org" In-Reply-To: <521F896A.9090305@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1504756420-1377826574=:11519" Cc: "joachim.fabini@tuwien.ac.at" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 01:36:23 -0000 --1510626085-1504756420-1377826574=:11519 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0AOn 8/29/13 5:47 AM, Nalini Elkins wrote:=0A> Please take a look at= :=0A>=0A> http://www.ripe.net/data-tools/stats/ttm/test-traffic-measurement= -service=0A>=0A>=0A> Note that what they provide is:=0A>=0A>=A0 =A0 * NTP-= server, the test-boxes can act a stratum 1 server for the machines on your = network, providing time-stamps with an accuracy of 10 microseconds.=0A>With= respect to the IETF 87 presentation/discussion I think is is a=0A>dicussio= n of the quality of time and it relationship to the general=0A>utility of o= f pdm optional header, not the availability of specific=0A>point solutions.= =0A=0ALet me back up and see if I can restate your basic concern in simple = words so that I am sure that I understand you.=0A=0AI believe that you are = concerned that the timestamps provided by NTP will not be accurate enough i= f the timestamps are taken from more than one administrative domain. =A0 Ou= r PDM proposal depends on fairly reliable timestamps. =A0So, if the timesta= mps are not reliable, then the PDM is not very useful.=0A=0APlease let me k= now if I have understood you.=0A=0AThanks,=0ANalini --1510626085-1504756420-1377826574=:11519 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


=0AOn 8/29/13 5:4= 7 AM, Nalini Elkins wrote:
> Please take a look at:
>
> h= ttp://www.ripe.net/data-tools/stats/ttm/test-traffic-measurement-service>
>
> Note that what they provide is:
>
> =   * NTP-server, the test-boxes can act a stratum 1 server for the ma= chines on your network, providing time-stamps with an accuracy of 10 micros= econds.
>With respect to the IETF 87 presentation/discussion I think = is is a
>dicussion of the quality of time and it relationship to the = general
>utility of of pdm optional header, not the availability of s= pecific
>point solutions.

Let me back up and see if I can rest= ate your basic concern in simple words so that I am sure that I understand = you.

I believe that you are concerned that the timestamps provided by NTP= will not be accurate enough if the timestamps are taken from more than one administrative domain.   Our PDM proposal depends = on fairly reliable timestamps.  So, if the timestamps are not reliable= , then the PDM is not very useful.

=
Please let me know if I have understoo= d you.

Thanks,
Nalini



--1510626085-1504756420-1377826574=:11519-- From heard@pobox.com Thu Aug 29 21:56: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 F00D821F8F6D for ; Thu, 29 Aug 2013 21:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW6oB3l6OJ-a for ; Thu, 29 Aug 2013 21:56:46 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EFC11E80E8 for ; Thu, 29 Aug 2013 21:56:45 -0700 (PDT) Received: (qmail 29081 invoked from network); 29 Aug 2013 21:56:41 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Aug 2013 21:56:41 -0700 Date: Thu, 29 Aug 2013 21:56:40 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: v6ops Message-ID: References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <20130819.104704.119047008.he@uninett.no> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A39@PRVPEXVS15.corp.twcable.com> <521E411F.9090203@bogus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 04:56:51 -0000 On Wed, 28 Aug 2013, joel jaeggli wrote: > Imho this is the first of these documents in recent times. As an > author I don't see the goal as guidance to implementors, I see it > as guidance from operators. OK, but that guidance is most helpful if finds its way into atual advice to implementors ("here are some things you need to improve in order to meet our operational needs") and to maintainers of the IPv6 specifications ("here are some places where the protocol, as specified, does not meet our operational needs"). On Mon, 19 Aug 2013, Havard Eidnes wrote: > The entire section 2.1.1. "Stateful inspection" is about problems with > resource exhaustion in middleboxes or end-system firewalls. > Implementations which willingly devote unlimited resources to fragment > reassembly display a severe lack robustness, and IMHO should not be > used as justification for why we can't use fragments. Yes, I'm > suggesting that one can forego the specified 60s fragmentation > reassembly timeout in the case of resource shortage of a fixed pool. This is true, but the other side of the coin (as is mentioned elsewhere in the draft) is that operators often have to deal, at least in the short term, with implementations that do have these sorts of deficiencies. Maybe the points that should be made in this section are: - If fragmented datagrams are allowed in at all, there is no way to prevent a malicious party from sending an incomplete series of fragments to a vctim host (or stateful middlebox). - Such an attach can cause resource exhaustion issues on unsophisticated implementations, owing in part to the 60 sec timeout specified in RFC 2460. It now becomes easy to provide actionable advice to implentors ("you may want to consider doing a better job of managing your resources") and possibly to the 6man wg ("you may want to consider revising the 60 sec timeout, or clarifying that it is an upper bound") In section 2.15 the draft states: The IETF and operators can help this effort by identifying specific classes of fragments that do not represent legitimate use cases and hence should always be dropped. That's good, actionable advice. However, I get great heartburn from this: However, some cases will remain where legitimate fragments are discarded for legitimate reasons. If the fragments are legitimate, it seems to me that the operator who discards them is shooting himself in the foot. May I susggest that a more productive thing to say would be that the IETF can also help by: - identifying applications that can be modified to avoid the use of fragmentation - identifying applications that can't live without it The hope is that this would lead to specification changes or appropriate implementation advice in cases where fragmentation is not really needed, and where it is needed to improved middlebox implementations that provide smore precisely targeted filtering tools than the blunt instrument of indiscriminately discarding all fragments (for instance, a middlebox capable of parsing the entire header chain if it's available and sufficiently short, and having the abiity to discard stuff that does not conform to ietf-6man-oversized-header-chain). On Mon, 19 Aug 2013, Havard Eidnes wrote: > Under section 2.1.2. Stateless ACLs: > > Stateless load balancing schemes may > hash fragmented datagrams from the same flow to different paths > because the 5-tuple may be available on only the initial fragment. > While rehashing has the possibility of reordering packets in ISP > cores it is not disastrous. However, in front of a stateful > inspection device, load balancer tier, or anycast service instance, > where headers other than the L3 header -- for example, the L4 header, > interface index (for traffic already rehashed onto different paths), > DS fields -- are considered as part of the hash, rehashing may result > in the fragments being delivered to different end-systems > > AFAIK the use of a 5-tuple which includes the L4 header to compute a > hash to make a forwarding decisions among otherwise equal paths is an > implementation optimization only, it is not something which is > explicitly prescribed by our standards. Therefore, I'll claim that > applying this logic to fragments, causing packet delivery to different > hosts for initial and subsequent fragments (e.g. in the case of a load > balancer) is an incorrectly applied optimization, also known as a bug. +1 to that last sentence. Note that the problems faced by stateless load balancers are discussed in Section 3 of the flow label specification (RFC 6437). > In section 2.1.4. Other considerations you say: > > It is common practice [RFC6192] to recommend that control-plane > ACLs protecting routers and network devices be configured to drop > all fragments. > > Well, there exists an informational RFC [6192] which contains an > example policy and also some detailed discussion about handling of > fragments. I don't think it in sum says what is said here, though. Agreed, and I think that the document would be improved by leaving out the last sentence in 2.1.4. (The points about disproptionate numbers of software errors in fragment processing are on target, though.) Mike Heard From randy@psg.com Fri Aug 30 04: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 71F4021F9EC8; Fri, 30 Aug 2013 04:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WXyDaSayNpf; Fri, 30 Aug 2013 04:07:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4621F8E85; Fri, 30 Aug 2013 04:07:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VFMXY-0003Ak-1f; Fri, 30 Aug 2013 11:06:56 +0000 Date: Fri, 30 Aug 2013 20:06:53 +0900 Message-ID: From: Randy Bush To: Nalini Elkins In-Reply-To: <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , "MORTON JR., ALFRED C \(AL\)" , "joachim.fabini@tuwien.ac.at" , "tsv-area@ietf.org" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 11:07:04 -0000 > http://www.ripe.net/data-tools/stats/ttm/test-traffic-measurement-service > * NTP-server, the test-boxes can act a stratum 1 server for the > machines on your network, providing time-stamps with an accuracy of 10 > microseconds. every ttm box has hardware reference clock From joelja@bogus.com Fri Aug 30 11:46: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 5321221F9D23; Fri, 30 Aug 2013 11:46:08 -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 brXXwjxWH7Bm; Fri, 30 Aug 2013 11:46:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B96F721F9CC2; Fri, 30 Aug 2013 11:46:06 -0700 (PDT) Received: from mb-aye.corp.zynga.com (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 r7UIk0n8027622 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 30 Aug 2013 18:46:01 GMT (envelope-from joelja@bogus.com) Message-ID: <5220E863.1020700@bogus.com> Date: Fri, 30 Aug 2013 11:45:55 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Nalini Elkins , "MORTON JR., ALFRED C \(AL\)" , IPv6 Ops WG , "tsv-area@ietf.org" References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>, <521DCE46.6030501@bogus.com> <2845723087023D4CB5114223779FA9C83BF8C4F1@njfpsrvexg8.research.att.com> <521EB4A2.2060006@bogus.com> <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <521F896A.9090305@bogus.com> <1377826574.11519.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1377826574.11519.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 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, 30 Aug 2013 18:46:02 +0000 (UTC) Cc: "joachim.fabini@tuwien.ac.at" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:46:11 -0000 On 8/29/13 6:36 PM, Nalini Elkins wrote: > > > On 8/29/13 5:47 AM, Nalini Elkins wrote: > > Please take a look at: > > > > > http://www.ripe.net/data-tools/stats/ttm/test-traffic-measurement-service > > > > > > Note that what they provide is: > > > > * NTP-server, the test-boxes can act a stratum 1 server for the > machines on your network, providing time-stamps with an accuracy of 10 > microseconds. > >With respect to the IETF 87 presentation/discussion I think is is a > >dicussion of the quality of time and it relationship to the general > >utility of of pdm optional header, not the availability of specific > >point solutions. > > Let me back up and see if I can restate your basic concern in simple > words so that I am sure that I understand you. > > I believe that you are concerned that the timestamps provided by NTP > will not be accurate enough if the timestamps are taken from more than > one administrative domain. The clock in the computer is providing the timestamp, ntp is syncronizing the clock in the computer to another clock. > Our PDM proposal depends on fairly reliable timestamps. It depends on the accuracy of clocks generating the timestamps with respect to each other. > So, if the timestamps are not reliable, then the PDM is not very useful. If a diagnostic result is dependant on low number of ms or usec level timestamp level accuracy and you don't have that, then yes. A related question is how do you know when you do or don't? if you have long timeseries data for two devices you may have evidence of the magnitude of the eror. If packets arrive from the future with respect to your clock that's a nice and gross indicator. Looking at a packet trace in the past, the information availble to reconstruct the state of the clocks is only the timestamps, baring external sources of that information. > > Please let me know if I have understood you. > > Thanks, > Nalini > > > From randy@psg.com Sat Aug 31 04:13:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D66611E8137; Sat, 31 Aug 2013 04:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhgfCXX6ZnBh; Sat, 31 Aug 2013 04:13:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id D2AD111E8136; Sat, 31 Aug 2013 04:13:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VFj73-0005Lk-6T; Sat, 31 Aug 2013 11:13:05 +0000 Date: Sat, 31 Aug 2013 20:13:03 +0900 Message-ID: From: Randy Bush To: joel jaeggli In-Reply-To: <521E411F.9090203@bogus.com> References: <201308181800.r7II06mv003294@irp-view13.cisco.com> <2671C6CDFBB59E47B64C10B3E0BD59230439DF7A39@PRVPEXVS15.corp.twcable.com> <521E411F.9090203@bogus.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: V6 Ops List , IPv6 Deployment Prevention Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 11:13:22 -0000 http://mailman.nanog.org/pipermail/nanog/2013-August/060709.html From nalini.elkins@insidethestack.com Sat Aug 31 05:19: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 9948821E80B6 for ; Sat, 31 Aug 2013 05:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jsQcRxwNW4T for ; Sat, 31 Aug 2013 05:19:21 -0700 (PDT) Received: from nm21-vm9.access.bullet.mail.gq1.yahoo.com (nm21-vm9.access.bullet.mail.gq1.yahoo.com [216.39.62.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0D34711E80F3 for ; Sat, 31 Aug 2013 05:19:20 -0700 (PDT) Received: from [216.39.60.167] by nm21.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Aug 2013 12:19:19 -0000 Received: from [216.39.60.231] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 31 Aug 2013 12:19:19 -0000 Received: from [127.0.0.1] by omp1002.access.mail.gq1.yahoo.com with NNFMP; 31 Aug 2013 12:19:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 656349.51624.bm@omp1002.access.mail.gq1.yahoo.com Received: (qmail 97732 invoked by uid 60001); 31 Aug 2013 12:19:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377951559; bh=nHULu/9UYfjop2xdfTTfqGg9XQSGwXQjxLa9eRoFsDo=; 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=E8c9ox6lT83coAfw0nqvytRyNuqSb1TjqkeYTjBfYDpl+S4J8ReeOqs7gSbaaN1h0q3KbcPOkJo56MhYPFTWOw9NaG48To+NBh/TCeq0ocRUh7ozyJFc3Sz+i4FfSx7x13N7zzVKtEGQbNpej4iXJ2eW4Cg/0DTpLtkDdcKbdgk= X-YMail-OSG: rWruHOkVM1kJlRSNm7FdGZQ4e2mtucnfa0.NySQtS_ucoJ9 dyIEEeT9dE9GHX6kyeWIALhfXF1upTkeAUi7FT1CyB.UJQqJ9Tl2uilSWmdv BuKk93pVd_Q7c07y9X_ENoNg_X0FgGnPxpO4f6i6s.Py9nwiZAa_uJe.Fv8N dCYvo3mOtFe3UUzGSJkHBxwzCCVOp3v7Sy__d.BEbKIH3r7CrM_20Nl697.k KDMpeLQzJtWsYyT2IPGsoCdVyGslsC2wHfFJS_w3fjuXTSB09pr8A0sVI2Jz MjKzg.gyVqhXjxi5c3LxTqTwVv_wJpQLrTMtrqTvfencByYxyUISlN3WoQJd nC6pb.LjmBpUQLLj8OtnR4otNLlw5qjZrmmnHW5WCkvlkmHzTid7G1w2Oqfv u7qQcQAh8D4fQMewMgxi8xLDKCQtu3dtSvgBsYQyIELe2eGCLlZEulZE1WtD x9rltWSeAjSFvVTWRNdLmNSA4tdzgs2UgqAXGSB203m6GKOnc.wS1EQE7vM_ gYZgmQ82t0dYO.mNf9_gN1yngtkQ85fG7T13qKOG7PAsinVIZjJkmUKLqUwl 6OKH.fbSB3PlzEa_1Tb0Xuj18jnVO4I8yNvDJ3oFLdQdhh_kykda3wqRlCar TSsWor98KPIDWgGOqp4Go1vIoHDcvi2UBN5SfZLPjktYlV8mFIRRkZYGEzht Qh2Hb_uFBpzzX6K3HWmRohQNtv_AWBPhrnSbKTxO_qaUlq_H1UzcWmTWl9Ta tPCgeSRX15rdrk4dTTCvFm92XyISegZltSQN_YQK0f_it Received: from [70.198.65.78] by web2806.biz.mail.ne1.yahoo.com via HTTP; Sat, 31 Aug 2013 05:19:18 PDT X-Rocket-MIMEInfo: 002.001, RnJvbTogam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPgpUbzogTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20.OyAiTU9SVE9OIEpSLiwgQUxGUkVEIEMgKEFMKSIgPGFjbW9ydG9uQGF0dC5jb20.OyBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc.OyAidHN2LWFyZWFAaWV0Zi5vcmciIDx0c3YtYXJlYUBpZXRmLm9yZz4gCkNjOiAiam9hY2hpbS5mYWJpbmlAdHV3aWVuLmFjLmF0IiA8am9hY2hpbS5mYWJpbmlAdHV3aWVuLmFjLmF0PjsgInRyYW1tZWxsQHRpay4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>, <521DCE46.6030501@bogus.com> <2845723087023D4CB5114223779FA9C83BF8C4F1@njfpsrvexg8.research.att.com> <521EB4A2.2060006@bogus.com> <1377780455.80051.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <521F896A.9090305@bogus.com> <1377826574.11519.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <5220E863.1020700@bogus.com> Message-ID: <1377951558.94995.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Sat, 31 Aug 2013 05:19:18 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , "MORTON JR., ALFRED C \(AL\)" , IPv6 Ops WG , "tsv-area@ietf.org" In-Reply-To: <5220E863.1020700@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "joachim.fabini@tuwien.ac.at" , "trammell@tik.ee.ethz.ch" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 12:19:26 -0000 From: joel jaeggli =0ATo: Nalini Elkins ; "MORTON JR., ALFRED C (AL)" ; IPv6 Ops= WG ; "tsv-area@ietf.org" =0ACc: "joach= im.fabini@tuwien.ac.at" ; "trammell@tik.ee.eth= z.ch" =0ASent: Friday, August 30, 2013 11:45 AM= =0ASubject: Re: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00=0A=0A=0AOn= 8/29/13 6:36 PM, Nalini Elkins wrote:=0A>=0A>=0A> On 8/29/13 5:47 AM, Nali= ni Elkins wrote:=0A> > Please take a look at:=0A> >=0A> >=0A> http://www.ri= pe.net/data-tools/stats/ttm/test-traffic-measurement-service=0A> >=0A> >=0A= > > Note that what they provide is:=0A> >=0A> >=A0 =A0 * NTP-server, the te= st-boxes can act a stratum 1 server for the=0A> machines on your network, p= roviding time-stamps with an accuracy of 10=0A> microseconds.=0A> >With res= pect to the IETF 87 presentation/discussion I think is is a=0A> >dicussion = of the quality of time and it relationship to the general=0A> >utility of o= f pdm optional header, not the availability of specific=0A> >point solution= s.=0A>=0A> Let me back up and see if I can restate your basic concern in si= mple=0A> words so that I am sure that I understand you.=0A>=0A> I believe t= hat you are concerned that the timestamps provided by NTP=0A> will not be a= ccurate enough if the timestamps are taken from more than=0A> one administr= ative domain.=0AThe clock in the computer is providing the timestamp, ntp i= s=0Asyncronizing the clock in the computer to another clock.=0A>=A0=A0=A0Ou= r PDM proposal depends on fairly reliable timestamps.=0AIt depends on the a= ccuracy of clocks generating the timestamps with=0Arespect to each other.= =0A>=A0 So, if the timestamps are not reliable, then the PDM is not very us= eful.=0A=0A>If a diagnostic result is dependant on low number of ms or usec= level=0A>timestamp level accuracy and you don't have that, then yes. A rel= ated=0A>question is how do you know when you do or don't? if you have long= =0A>timeseries data for two devices you may have evidence of the magnitude= =0A>of the eror. If packets arrive from the future with respect to your=0A>= clock that's a nice and gross indicator. Looking at a packet trace in=0A>th= e past, the information availble to reconstruct the state of the=0A>clocks = is only the timestamps, baring external sources of that information.=0A=0AT= he basic issue here goes far beyond our PDM header. =A0 Accurate time synch= ronization is necessary for much data processing today. =A0 Let me quote fr= om an IBM Redbook:=0A=0A"In the information technology world, time synchron= ization has become a critical component for managing the correct order of t= he events in distributed applications (transaction processing, message logg= ing), especially for audit and legal purposes."=A0http://www.redbooks.ibm.c= om/redbooks/pdfs/sg247280.pdf=A0(section 1.1)=0A=0AIf you are arguing that = time synchronization cannot be done to the millisecond or microsecond level= , then a great deal of data processing would flat out not work. =A0 Let me = point you to something called 'parallel sysplex' which is a way of putting = together very large computer systems=A0http://www-03.ibm.com/systems/z/adva= ntages/pso/bsvsps.html=A0 These kind of extremely expensive systems are in = most large data centers today. =A0They require synchronization to the micro= second level. =A0They do it using NTP.=0A=0AOne of the members of my team h= as implemented NTP with a consortium of 120 separate organizations (all DIF= FERENT administrative domains) and they have synched up to 20 - 50 millisec= onds. =A0If anyone would like, they can contact us offline and we can share= the implementation documentation. =A0If you would like, I can get from the= m the sources for timing that they use. =A0 Multiple MASTER Clocks geograph= ically dispersed for either accuracy and/or backup-contingency purposes may= be needed. =A0 By the way, this was done several years ago.=0A=0AAs far as= our PDM header is concerned, what we are looking for MOST is to do triage.= =A0 That is to say which of the three: inbound network time, server proces= sing time, and outbound network time is consistently quite large. =A0 What = happens in real life is that problems happen with response time to a major = region or bank branch, and we need to quickly (hopefully VERY quickly) get = the right team to work solving the problem. =A0 So, what is required is tha= t the differences in those times be consistently greater than any problems = with time synchronization. =A0 To give an example:=0A=0AAssume: time synchr= onization varies at 50 milliseconds.=0A=0AInbound network time =3D 100 mill= iseconds=0AServer time =3D 500 milliseconds=0AOutbound network time =3D 200= milliseconds=0A=0AThe point of this game is to say which is the failing co= mponent. =A0If you add or subtract 50 milliseconds from the above numbers, = it won't matter. =A0It will still be the server time.=0A=0AIf you think tha= t we will have problems if all times are close together, (ex. all times =3D= 40 milliseconds), then yes. =A0And, it doesn't matter. =A0What we are look= ing for in doing diagnostics and triage are, basically, the outliers (or th= ose at the 95% to be a bit more precise). I am looking for which response t= imes are among the worst. =A0That is where the problems are likely to be. = =A0 In those transactions, in my experience, I have NEVER found transaction= s where all numbers are close together. =A0=A0=0A=0A=0ADefinitely for trend= ing and capacity planning purposes, we want to look at all response times. = =A0But, I believe that time synchronization to the level that is required c= an be achieved today. =A0 I have cited numerous examples of organizations d= oing so.=0A=0A=0AIf our PDM proposal is accepted, it will still be 5-6 year= s before it is in use because operating systems need to be changed to use i= t. =A0 I expect that time synchronization will become even better over time= . =A0 Notice how much more prevalent GPS is from even a few years ago. From randy@psg.com Sat Aug 31 06:01: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 2E08011E80FE for ; Sat, 31 Aug 2013 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXjAtTiVNbI5 for ; Sat, 31 Aug 2013 06:01:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6921F9C38 for ; Sat, 31 Aug 2013 06:01:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VFko6-0005TE-OY; Sat, 31 Aug 2013 13:01:39 +0000 Date: Sat, 31 Aug 2013 22:01:37 +0900 Message-ID: From: Randy Bush To: Nalini Elkins In-Reply-To: <1377951558.94995.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , Al Morton Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 13:01:48 -0000 > If you are arguing that time synchronization cannot be done to the > millisecond or microsecond level not arguing. just trying to explain to you that a lot of engineering and research have shown that ntp, pee cees running unix or linux with gps, ... do not have millisecond accuracy on stamping packets over the net. folk are trying to save you wasted effort. randy From nalini.elkins@insidethestack.com Sat Aug 31 09:39: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 C6D5611E814F for ; Sat, 31 Aug 2013 09:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtvplAvX5OF9 for ; Sat, 31 Aug 2013 09:39:02 -0700 (PDT) Received: from nm8-vm4.access.bullet.mail.bf1.yahoo.com (nm8-vm4.access.bullet.mail.bf1.yahoo.com [216.109.114.179]) by ietfa.amsl.com (Postfix) with ESMTP id ECDDA11E812D for ; Sat, 31 Aug 2013 09:39:01 -0700 (PDT) Received: from [66.196.81.158] by nm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2013 16:39:00 -0000 Received: from [66.196.81.154] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2013 16:39:00 -0000 Received: from [127.0.0.1] by omp1030.access.mail.bf1.yahoo.com with NNFMP; 31 Aug 2013 16:39:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 463347.60968.bm@omp1030.access.mail.bf1.yahoo.com Received: (qmail 31554 invoked by uid 60001); 31 Aug 2013 16:38:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377967139; bh=6pBGlSCvJUXFnSFvaZjUDAy0czksL0dDagwyxDFpjUI=; 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=z5vnh6QlvErtSsXPFoV6fQVPs85THMdzHneDUwzvDihW6NR7Hz5spYq91dDWlJMKe1fJhqiFrP3ZoitVjQz0PEh1PeYqVkzUv/Fy0OKFoILcwJCz0eKNJ6SkOSQzvpU8zhlxkvqCQCr8n+nuayYtIRy8WvBVlHjMSbeofGLiujw= X-YMail-OSG: YLif7fMVM1le_G2zyWo5ZyPdMmUKzUUH_xjXtN5jAItZMJZ tQUf5cPzUX3qnBKsmI9NwbuyELWz7c.RohmWXUTjCzDnMfYGZINZRMoxksg_ 2Eynd1j34vhTIDwrNDixDVA7.4Umdd5bMGCcDVukWnsbxwoN6c6VXu.TIH1u eOlKZzEaiEfAT4xz4QQUC6CCF6xiOYx4ic0vC8.6.m_5dZXMOwfHwaKIH_oP W4QjtF25lfD5QLXA3KE.a7EKCvOjDp0W9DwywdVJMQ81Gky1H3fwL7u.CSQz XF9G3aV4K8j.ER2NPm3XeePrvW3n44WE94w7I7hfMJvZBu398Ay0DtTg9GTH 0VK56KLF1tLjBhMnTmfLedpCS0CihcvRlDfU8_aDmya1R0au_uwTapDIt4xE eObLIR3Bq_INJcyIAXDAU0CYJYSIhv0qhRkZU4QfWc59sGeqFOAdZwaBO5io xitTj.vHc0xV1zUOPuNnHnVqclP7cpbiRMX7xNvU7sXpobQFXVAFW4PJ8NFR tuYg_Ta3M_I1UhmHkQWrySRUss5kqP2IHvMzE7m02RSJjDpKZESRyxQa8xZa GWEZea.fw44JFf6lqdG6yXPwJSo4R0Q_B_rZz637WKph42MKkDvoYoQs- Received: from [70.198.66.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Sat, 31 Aug 2013 09:38:59 PDT X-Rocket-MIMEInfo: 002.001, Cgo.IElmIHlvdSBhcmUgYXJndWluZyB0aGF0IHRpbWUgc3luY2hyb25pemF0aW9uIGNhbm5vdCBiZSBkb25lIHRvIHRoZQo.IG1pbGxpc2Vjb25kIG9yIG1pY3Jvc2Vjb25kIGxldmVsCgo.IG5vdCBhcmd1aW5nLsKgIGp1c3QgdHJ5aW5nIHRvIGV4cGxhaW4gdG8geW91IHRoYXQgYSBsb3Qgb2YgZW5naW5lZXJpbmcKPiBhbmQgcmVzZWFyY2ggaGF2ZSBzaG93biB0aGF0IG50cCwgcGVlIGNlZXMgcnVubmluZyB1bml4IG9yIGxpbnV4IHdpdGgKPiBncHMsIC4uLiBkbyBub3QgaGF2ZSBtaWxsaXNlY29uZCBhY2MBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Message-ID: <1377967139.13163.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sat, 31 Aug 2013 09:38:59 -0700 (PDT) From: Nalini Elkins To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , Al Morton Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 16:39:09 -0000 =0A=0A> If you are arguing that time synchronization cannot be done to the= =0A> millisecond or microsecond level=0A=0A> not arguing.=A0 just trying to= explain to you that a lot of engineering=0A> and research have shown that = ntp, pee cees running unix or linux with=0A> gps, ... do not have milliseco= nd accuracy on stamping packets over the=0A> net.=A0 folk are trying to sav= e you wasted effort.=A0 =0A=0A> randy=0A=0A=0AAppreciate the concern.=0A=0A= I would be quite interested to see this research. =A0 Can you point me to s= ome?=0A=0AWhen you say "=A0ntp, pee cees running unix or linux do not have = millisecond accuracy on stamping packets" =A0 do you mean that linux cannot= timestamp a packet at microsecond level or that linux servers cannot synch= ronize to NTP at some level of milliseconds or something else entirely?=0A= =0ABTW, I remember at least one side conversation when I was at SharkFest (= the WireShark conference) in June about the need for nano-second accuracy i= n WireShark packet captures. =A0 Presumably, this is for non-Linux based sy= stems.=0A=0ANalini From bill.jouris@insidethestack.com Sat Aug 31 09:48:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE8411E815B for ; Sat, 31 Aug 2013 09:48:10 -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 BL7D-kW8wcvo for ; Sat, 31 Aug 2013 09:48:05 -0700 (PDT) Received: from nm2-vm4.access.bullet.mail.bf1.yahoo.com (nm2-vm4.access.bullet.mail.bf1.yahoo.com [216.109.114.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA3611E812D for ; Sat, 31 Aug 2013 09:48:05 -0700 (PDT) Received: from [66.196.81.165] by nm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2013 16:48:04 -0000 Received: from [66.196.81.127] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2013 16:48:04 -0000 Received: from [127.0.0.1] by omp1003.access.mail.bf1.yahoo.com with NNFMP; 31 Aug 2013 16:48:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 688530.50769.bm@omp1003.access.mail.bf1.yahoo.com Received: (qmail 35568 invoked by uid 60001); 31 Aug 2013 16:48:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377967684; bh=nTr9Grleh6cX66LKQPAZjPJjB9u/6h4FTtgrAWO5Ti8=; 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=QE8WqQ2lucOjeI8mMZauT03egwqW//UqWokSA70sVnU9tcKvfLKhbRMHO7pWdDsGyuG/Ms8nUnCEJzjp60YtZB1ttJgU+Lns9+yKJdKiASUW5c2qGqLzUJHa5NcV0rpE+FDm6BFV9YTGA9VHXgFYBMM5Y9KhkjGkDYqDgs+6JRY= X-YMail-OSG: guwNyAAVM1miirSCx.f0OQATiETm0LypJQv7hN0J3YKnnrJ HePiBVskJCD5NlwIQ0dKFlyF_WVe57f_idjKeKf4DEPXNmM.Ev_huyq5XbLa 21d9glP3hG6G.vSVTnwgJBU1xeH3q7TC9rVMP_KuCOhvmlayC30gOg5AaSag w4XZ4k38Ka_Y.Ux9jpeZf_Tw67_ZfLrZryh4SEegLANSoHitRbJ5UcdQE5w9 O2xed2ZinFpOJ9h8fL2g8g6LL4d5jEA8nxmi.6tmX63D730xahEihZDMmZp7 5duMEO5mEA2DCI88gxYpsYGhQLpcssZ_cxhuMm0CoqDw.10xHaEBWWdqv5Vr pIGADRZRIdNe_89lzoevIbJfPoqrP2MQkIl2cZl9EViu04YeR1rmuPgSCytD fogfzsQyp0ThK9TIFP_p7hUAliQcJugun_uW8VaftJVDdl2lZIvpMPP6I_kl axWEoSr23iedtrxUcbJZ.3MM__PoCQaRwrAMYhcXo.sQ.1BsHkKGpmnz8_K2 HCJaD6KqtjCQe3Xy6mnPcjPya8hXUU673KEZXY26_toNrU7Ga5ljcCeJ_sHt VVl3xd3PGWSr05Els8.q2r77avlKP1cptn0vBr4vqnhOwKd.zIsT36DfeefW oDC7Seu0cyyTD0ei8xj_XB.XXXU8qD339hP7VSDdPcMm.2tsDC8vY_FHhkFa m Received: from [50.143.174.186] by web2803.biz.mail.ne1.yahoo.com via HTTP; Sat, 31 Aug 2013 09:48:04 PDT X-Rocket-MIMEInfo: 002.001, Tm8gcXVlc3Rpb24gdGhhdCB0aGVyZSBhcmUgbG90cyBvZiBzeXN0ZW1zIHdoaWNoIGRvIG5vdCBoYXZlIHRoZWlyIGNsb2NrcyBzeW5jaHJvbml6ZWQuwqAgSW5kZWVkLCBhIGxvdCBvZiBQQ3MgYXJlbid0IGV2ZW4gc3luY2hyb25pemVkIHRvIHRoZSBuZWFyZXN0IDEwIHNlY29uZHMsIGxldCBhbG9uZSBhbnl0aGluZyBmaW5lci4KCkJ1dCB0aGVuLCBhIGxvdCBvZiBQQ3MgYXJlbid0IGluIG5lZWQgb2Ygc3luY2hyb25pemF0aW9uLsKgIE5vYm9keSAoZXhjZXB0IG1heWJlIHRoZSBpbmRpdmlkdWFsIHVzZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Message-ID: <1377967684.21896.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sat, 31 Aug 2013 09:48:04 -0700 (PDT) From: Bill Jouris To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-940131799-1377967684=:21896" Cc: IPv6 Ops WG , Al Morton Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 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: Sat, 31 Aug 2013 16:48:10 -0000 ---1551098171-940131799-1377967684=:21896 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable No question that there are lots of systems which do not have their clocks s= ynchronized.=A0 Indeed, a lot of PCs aren't even synchronized to the neares= t 10 seconds, let alone anything finer.=0A=0ABut then, a lot of PCs aren't = in need of synchronization.=A0 Nobody (except maybe the individual user) is= concerned about response time for them -- or going to consider doing anyth= ing about response times that aren't a matter of tens of minutes, and on an= on-going basis. =A0 =0A=0A=0AThe issue is all of the systems where respons= e times DOmatter.=A0 Those clocks do get synchronized already, because ther= e is a need that justifies the effort required to do so.=A0 The challenge t= hen becomes, How do we measure transmission times between those systems onc= e they convert to IPv6?=A0 When there is no way in IPv6 to record those tim= es, that is a problem.=A0 =0A=0A=0AAnd this isn't the only approach that is= being considered -- just the only one (that I am aware of) which doesn't i= nvolve adding extra hardware at the end-points.=A0 (Hardware which will als= o require some kind of clock synchronization.)=0A=0A=A0=0ABill Jouris=0AIns= ide Products, Inc.=0Awww.insidethestack.com=0A831-659-8360=0A925-855-9512 (= direct)=0A=0A=0A=0A=0A________________________________=0A From: Randy Bush = =0ATo: Nalini Elkins =0AC= c: IPv6 Ops WG ; Al Morton =0ASent: Satu= rday, August 31, 2013 6:01 AM=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv= 6-pdm-recommended-usage-00=0A =0A=0A> If you are arguing that time synchron= ization cannot be done to the=0A> millisecond or microsecond level=0A=0Anot= arguing.=A0 just trying to explain to you that a lot of engineering=0Aand = research have shown that ntp, pee cees running unix or linux with=0Agps, ..= . do not have millisecond accuracy on stamping packets over the=0Anet.=A0 f= olk are trying to save you wasted effort.=A0 =0A=0Arandy=0A________________= _______________________________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/v6ops ---1551098171-940131799-1377967684=:21896 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
No question that ther= e are lots of systems which do not have their clocks synchronized.  In= deed, a lot of PCs aren't even synchronized to the nearest 10 seconds, let = alone anything finer.

But then, a lot of PCs= aren't in need of synchronization.  Nobody (except maybe the individu= al user) is concerned about response time for them -- or going to consider = doing anything about response times that aren't a matter of tens of minutes, and on an on-going basis.  

The issue is all of the = systems where response times DO matter.  Those clocks do get synchroni= zed already, because there is a need that justifies the effort required to = do so.  The challenge then becomes, How do we measure transmission tim= es between those systems once they convert to IPv6?  When there is no = way in IPv6 to record those times, that is a problem. 

And this isn't the only approach that is being con= sidered -- just the only one (that I am aware of) which doesn't involve add= ing extra hardware at the end-points.  (Hardware which will also requi= re some kind of clock synchronization.)
 
Bill Jouris
Inside Products,= Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)


From: Randy Bush <randy@psg.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com&= gt;
Cc: IPv6 Ops WG <v= 6ops@ietf.org>; Al Morton <acmorton@att.com>
Sent: Saturday, August 31, 2013 6:01 AM<= br> Subject: Re: [v6ops] d= raft-elkins-v6ops-ipv6-pdm-recommended-usage-00

=0A> If you are arguing that time synchroniza= tion cannot be done to the
> millisecond or microsecond level

= not arguing.  just trying to explain to you that a lot of engineering<= br>and research have shown that ntp, pee cees running unix or linux withgps, ... do not have millisecond accuracy on stamping packets over the
= net.  folk are trying to save you wasted effort. 

randy_______________________________________________
v6ops mailing list
= v6ops@i= etf.org
https://www.ietf.org/mailman/listinfo/v6ops


---1551098171-940131799-1377967684=:21896-- From markzzzsmith@yahoo.com.au Sat Aug 31 21:09: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 656DA11E811F for ; Sat, 31 Aug 2013 21:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=1.021, 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 B9GSN1FCMJQY for ; Sat, 31 Aug 2013 21:09:33 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 81DC311E80C5 for ; Sat, 31 Aug 2013 21:09:33 -0700 (PDT) Received: from [66.196.81.170] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 01 Sep 2013 04:09:32 -0000 Received: from [98.139.212.196] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 01 Sep 2013 04:09:31 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 01 Sep 2013 04:09:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 972795.52742.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 35197 invoked by uid 60001); 1 Sep 2013 04:09:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1378008571; bh=m9u25BQcHVAcyWPO2EliL2sH1IS8VDpf7FU0KaZBaxY=; 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=Je7EwDMUYmO0DybQa2MJ7yglujM8h82vlGxJG+L/asED3axP1rP+hHgoSjT9U16J8PwvOXeXM3zJi6aFpGL9D1Wui445ho/hnEAZjVsmBwgAT4tw6n6m8U4OiD/bHTY65WlKJOABVRtXI4qnXygEOfQ7wuE9lIDveh/68daX5Ss= 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=Cd6c/iwE/ZtFiFSUumedByTuKPPNolsFhXqHwYUjTIARYHcRmmRy1hvoaRP7di7SZ6jsJJB2s4tr9LuE7FtCX6/d8iujO2plE+V8/c79UeSL22nBbfyL6wOHpSbvgWDlJC0ixQet9VS53toqt3Zv+qUPP9v+TuIrCLJ/1qVpgKk=; X-YMail-OSG: 4RDgTqUVM1mOiAvWlXdhsfmpsc4tga.Dsvzlr9khU78dEfR 4s2cYfG4S_JZyRocH_TVADWfkEioFIuFGVI6XQCG7Q57uKuDhsx1Z3ziIqE1 XcpHeG.gg4CxCoyRZjiq1wr.Zd55al_HjsMM92tiYMTlGe9lJz_YRAndMTqf je77u.lZ7vi14EsPotLCmr1PQWQ4ER7xdhrkV9hzD174WKJNII.EkSKmBDKi mjsy6fKmKn8cTsZu.qPKknjOJHlyz8w5SaOHsnv69BchTNwS3mLwqZf1Phd5 sNLR86pwbOsChTmSFmQQvpFtURl5.boWN7K14kh22jZDT2Ucw_EG5l_tG1zy UYT4QSP2ilwSU54.pBfIOzKyWB9126pvretqAr6vMaukODKlLZfZsjcOD.M5 jtZfz09GR9oXRB90WvUhxa4FPXKFLqJqfzPr6golHtnE4_QEgJo0iBELfHaE L.SzyIGZCaakg6rN9lDsBB4HDdo_..lWNP.nWIJihEWUSRFc300viFdBXiwt CzPvM87Y_mb1OsLiGsjTF1IN5_gP9SN.DhQAl58BqSY4IhktVfDIMkakBRK2 jQmJgDuG2mlh6Uu28PrB4mdheFfe0ddFjbUrH_pMD.H1ROvEoS0YfNEvw23b ZK4Rh7xjWTSdvzke9I_7dW7d.GEFZ_TlKpvONFOsVbYVaeW_REwR.IDTJ3D5 .9d5U.jISoGBPUCX_KeeCOnrZp2r.R4w4o7pZ Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Sat, 31 Aug 2013 21:09:31 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBCaWxsIEpvdXJpcyA8YmlsbC5qb3VyaXNAaW5zaWRldGhlc3RhY2suY29tPgo.VG86IFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb20.IAo.Q2M6IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz47IEFsIE1vcnRvbiA8YWNtb3J0b25AYXR0LmNvbT4gCj5TZW50OiBTdW5kYXksIDEgU2VwdGVtYmVyIDIwMTMgMjo0OCBBTQo.U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtcGRtLXJlY29tbWVuZGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1377967684.21896.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Message-ID: <1378008571.34695.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Sat, 31 Aug 2013 21:09:31 -0700 (PDT) From: Mark ZZZ Smith To: Bill Jouris , Randy Bush In-Reply-To: <1377967684.21896.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , Al Morton Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 04:09:38 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Bill Jouris =0A>To: Randy Bush =0A>Cc: IPv6= Ops WG ; Al Morton =0A>Sent: Sunday, 1 = September 2013 2:48 AM=0A>Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-= recommended-usage-00=0A> =0A>=0A>=0A>No question that there are lots of sys= tems which do not have their clocks synchronized.=A0 Indeed, a lot of PCs a= ren't even synchronized to the nearest 10 seconds, let alone anything finer= .=0A>=0A>=0A>But then, a lot of PCs aren't in need of synchronization.=A0 N= obody (except maybe the individual user) is concerned about response time f= or them -- or going to consider doing anything about response times that ar= en't a matter of tens of minutes, and on an on-going basis. =A0 =0A>=0A>=0A= >=0A>The issue is all of the systems where response times DO matter.=A0 Tho= se clocks do get synchronized already, because there is a need that justifi= es the effort required to do so.=A0 The challenge then becomes, How do we m= easure transmission times between those systems once they convert to IPv6?= =A0 When there is no way in IPv6 to record those times, that is a problem.= =A0 =0A>=0A=0AAs far as I'm aware there is no way to record those times spe= cifically in IPv4. So how is it being done now in IPv4, "before IPv6"?=0A= =0AI don't think the answer isn't NTP, because NTP runs over UDP, and there= fore can and does run over both IPv4 and IPv6.=0A=0AI don't think the answe= r is =A0PTP/IEEE 1588 because that's both a fairly recent development and i= s only single LAN rather than Internet scale.=0A=0A=0A>=0A>=0A>And this isn= 't the only approach that is being considered -- just the only one (that I = am aware of) which doesn't involve adding extra hardware at the end-points.= =A0 (Hardware which will also require some kind of clock synchronization.)= =0A>=0A>=A0=0A>Bill Jouris=0A>Inside Products, Inc.=0A>www.insidethestack.c= om=0A>831-659-8360=0A>925-855-9512 (direct)=0A>=0A>=0A>=0A>=0A>____________= ____________________=0A> From: Randy Bush =0A>To: Nalini Elk= ins =0A>Cc: IPv6 Ops WG = ; Al Morton =0A>Sent: Saturday, August 31, 2013 6:01 AM= =0A>Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00= =0A> =0A>=0A>> If you are arguing that time synchronization cannot be done = to the=0A>> millisecond or microsecond level=0A>=0A>not arguing.=A0 just tr= ying to explain to you that a lot of engineering=0A>and research have shown= that ntp, pee cees running unix or linux with=0A>gps, ... do not have mill= isecond accuracy on stamping packets over the=0A>net.=A0 folk are trying to= save you wasted effort.=A0 =0A>=0A>randy=0A>______________________________= _________________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ie= tf.org/mailman/listinfo/v6ops=0A>=0A>=0A>=0A>______________________________= _________________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ie= tf.org/mailman/listinfo/v6ops=0A>=0A>=0A>