From brian.e.carpenter@gmail.com Fri Feb 1 00:07: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 9AE4721F8840 for ; Fri, 1 Feb 2013 00:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.49 X-Spam-Level: X-Spam-Status: No, score=-98.49 tagged_above=-999 required=5 tests=[AWL=-2.479, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os2qVLMGlhcI for ; Fri, 1 Feb 2013 00:07:57 -0800 (PST) Received: from mail-we0-x22a.google.com (we-in-x022a.1e100.net [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 686DE21F8828 for ; Fri, 1 Feb 2013 00:07:57 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so2873201wey.1 for ; Fri, 01 Feb 2013 00:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6PunxhLZuZ1f6D+8VaO/W3vGM1U1KjDcvsd0Gr8RLPI=; b=dCHheM9k8WcZqWPhuL3Ly4CmXJHMh+NWE3N8OCYT9tkzPJnSBqUgto0Buq9lx5wGNE UigfiqlJi9PG2NE3iwWqYNEow95v1IVi/f3JAdPAo3HjHxh8MBGMFI9ewQ7d6wizk9UX iU9U+C4nBLTJWt+qv8Nt+X/8gBnf/GSyj7zFAmM8Z20n3KdZdyOk5UHqDXLDwQKJHIBV wF+Ds3V8Mg/zav6VHJcYZ+e1zTPCFhTcDuhuTJQeJGztbGtDiNUknKxkC4XU1oF4xhS7 NRk/HG3Z/S0gnY5FFGt7ftacDqrdWvUsHfwirOrYtNZWB2Aae7+ovhhdF4BzJAHQ9U02 PBUA== X-Received: by 10.194.174.234 with SMTP id bv10mr20009877wjc.47.1359706076380; Fri, 01 Feb 2013 00:07:56 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-71.as13285.net. [2.102.219.71]) by mx.google.com with ESMTPS id be1sm1724475wib.10.2013.02.01.00.07.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 00:07:55 -0800 (PST) Message-ID: <510B77E4.2060001@gmail.com> Date: Fri, 01 Feb 2013 08:08:04 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> In-Reply-To: <510B4EC6.5050308@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 08:07:58 -0000 Joel, you're missing the point. The draft has been finally approved by the IESG when some of us thought it was on hold until somebody called consensus on the IPR question. I'm not one for appeals but this is very close to an appealable move. IMHO a WG Chair needs to make a formal call on the IPR question PDQ, and if necessary, urgently request the IESG to rescind its approval. I hope it isn't necessary, but it isn't my place to make the call. Regards Brian Carpenter On 01/02/2013 05:12, joel jaeggli wrote: > On 1/31/13 5:47 PM, Ted Lemon wrote: >> On Jan 31, 2013, at 6:26 PM, joel jaeggli wrote: >>> Given an intended status of BCP, the next big step is IETF last call, >>> which should not be construed as a reason to stop this discussion, >>> quite the contrary. >> Someone, I can't remember who (sorry!), pointed out that this >> statement is true of Informational, but perhaps not of BCP. > I think you mean vice-versa. if I'm wrong about it's current state then > I missed something. version 9 and 8 still request the status of bcp as > the wglc validated as well. > > we have hypothetically discussed whether the ipr is more palatable with > an informational document. >> That is, if the document is merely intended to document the >> existing practice that some vendor follows, that is a good thing which >> we should publish; however, it shouldn't be a BCP if the IPR terms are >> not found to be acceptable. >> >> I haven't looked at it in depth, but a brief skim of the updated IPR >> report that went by yesterday looked like it was a bit outside of the >> norm for IETF standards, since it mentions charging royalties. > Definition of what is RAND is somewhat fungible. It clearly is not in > the style of non-assert clause which I would have no problems at all with. >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From mohamed.boucadair@orange.com Fri Feb 1 00:52: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 633F221F871E for ; Fri, 1 Feb 2013 00:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MANGLED_AVOID=2.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy-qPbJdjI05 for ; Fri, 1 Feb 2013 00:52:03 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6E521F8716 for ; Fri, 1 Feb 2013 00:52:03 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id AC22622C764; Fri, 1 Feb 2013 09:52:01 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8C09B4C066; Fri, 1 Feb 2013 09:52:01 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 1 Feb 2013 09:52:00 +0100 From: To: Warren Kumari , Cameron Byrne Date: Fri, 1 Feb 2013 09:52:00 +0100 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac3/+mCJw8XilQiYR/uweh2GSsvmAgAWCIyA Message-ID: <94C682931C08B048B7A8645303FDC9F36EA9C841B4@PUEXCB1B.nanterre.francetelecom.fr> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> In-Reply-To: <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> 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.2.1.70316 Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 08:52:09 -0000 Dear Warren, If the document is adopted, then we will update the document to record what= the wg want to see in it (some requirements will be removed, others added,= justification for some requirements worked better, etc.). The current situation is: there are few mobile devices which support IPv6 f= eatures, some of them are broken (see http://www.ietf.org/mail-archive/web/= v6ops/current/msg14732.html or what we reported in http://tools.ietf.org/ht= ml/draft-boucadair-pcp-nat64-experiments-00#section-3.2), deploying IPv6 in= mobile networks depends on the availability of IPv6-compliant devices, etc= .=20 We edited this document to fill a void: have a comprehensive list of IPv6 r= equirements for mobile device.=20 Cheers, Med=20 >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de Warren Kumari >Envoy=E9 : jeudi 31 janvier 2013 22:31 >=C0 : Cameron Byrne >Cc : IPv6 Ops WG >Objet : Re: [v6ops] Test for adoption as a working group=20 >document - Re: I-D Action:=20 >draft-binet-v6ops-cellular-host-requirements-02.txt > > >On Jan 31, 2013, at 2:05 PM, Cameron Byrne wrote: > >> On Thu, Jan 31, 2013 at 10:54 AM, james woodyatt=20 > wrote: >>> On Jan 30, 2013, at 11:19 , joel jaeggli wrote: >>>>=20 >>>> This kicks of a request for adoption as a working group=20 >document on draft-binet-v6ops-cellular-host-requirements-02.txt >>>=20 >>>=20 >>> I'm going to echo the sentiments of others by questioning=20 >whether 3GPP would be a better venue than IETF for defining=20 >this sort of device profile. >>>=20 >>> As a supporting argument, I would point out that this draft=20 >uses RFC 2119 normative keywords while asserting that it is=20 >Informational category. That makes it a bit peculiar in the=20 >same way that an early draft of what became RFC 6092 was=20 >peculiar, which entailed adding section 1.2 during working=20 >group deliberations. >>>=20 >>>>> 1.2. Use of Normative Keywords >>>>>=20 >>>>> NOTE WELL: This document is not a standard, and=20 >conformance with >>>>> it is not required in order to claim conformance with IETF >>>>> standards for IPv6. It uses the normative keywords=20 >defined in the >>>>> previous section only for precision. >>>=20 >>> We added that language because there were several different=20 >standards bodies that were interested in having a baseline of=20 >IETF consensus defined about what sorts of requirements are a=20 >reasonable starting point, and we were hoping to facilitate=20 >all those external organizations at once in setting=20 >requirements standards that could reference an IETF document=20 >in common with specific amendments applicable in their own domains. >>>=20 >>> The way I see it, there is no need for IETF to do that in=20 >this case. There is only one standards body with an ambit that=20 >covers the topic of this draft, i.e. 3GPP, and it would be a=20 >much better fit for this work to be done there. >>>=20 >>=20 >> So, i cannot speak for others, but i will not be doing this=20 >work in 3GPP. >>=20 >> Keep in mind, 3GPP is not an open standards group. > >Hmm.. Ok, good point. > >When I wrote that I though that this should be done somewhere=20 >else, I didn't actually stop and figure out *where* else. > >If the choice is between it being adopted by v6ops or just not=20 >being published, then I (somewhat reluctantly) support adoption. >I still think that it will need some more fleshing out, but=20 >that can be done by the WG (if it chooses to adopt, etc blah=20 >blah blah.) > >W > > > >>=20 >> CB >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > >--=20 >No man is an island, But if you take a bunch of dead guys and=20 >tie them together, they make a pretty good raft. > --Anon. > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From otroan@employees.org Fri Feb 1 01:29: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 DA48721F8464 for ; Fri, 1 Feb 2013 01:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPv8ENbkbdTc for ; Fri, 1 Feb 2013 01:29:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A82AD21F8472 for ; Fri, 1 Feb 2013 01:29:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHyJC1GQ/khR/2dsb2JhbABBBL8kFnOCHgEBAQMBAQEBNxEBAiAQCxwDAQIBDBsHJwoVBwIIBgoFBAEIFAEDh2oGDLQsAY4LjSERgnlhA5cxjzGCfIFu X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="150021708" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2013 09:29:22 +0000 Received: from dhcp-lys01-vla250-10-147-112-125.cisco.com (dhcp-lys01-vla250-10-147-112-125.cisco.com [10.147.112.125]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r119TLck018392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 Feb 2013 09:29:22 GMT From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Feb 2013 10:29:21 +0100 References: <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> To: "v6ops@ietf.org WG" Message-Id: <55A6626B-2247-462D-8D7B-2FA54F9B55B4@employees.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [v6ops] Fwd: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 09:29:32 -0000 if anyone cares about the document fixing the issues with RFC3315 and = RFC3633 that was identified from RFC6204 implementations, please chime in over at DHC. cheers, Ole Begin forwarded message: > From: Ted Lemon > Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Date: January 14, 2013 20:34:23 GMT+01:00 > To: dhc WG > Return-Path: > X-Original-To: otroan@employees.org > X-Original-To: dhcwg@ietfa.amsl.com > Delivered-To: otroan@employees.org > Delivered-To: dhcwg@ietfa.amsl.com > Received: from mail.employees.org by = dhcp-lys02-vla252-10-147-116-45.cisco.com with POP3 (fetchmail-6.3.20) = for (single-drop); Mon, 14 Jan 2013 20:35:26 +0100 = (CET) > Received: from ironport2.layer42.net (ironport2.layer42.net = [69.36.224.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No = client certificate requested) by banjo.employees.org (Postfix) with = ESMTPS id DD83B5EDD for ; Mon, 14 Jan 2013 = 11:34:27 -0800 (PST) > Received: from mail.ietf.org ([IPv6:2001:1890:126c::1:1e]) by = ironport2.layer42.net with ESMTP; 14 Jan 2013 11:34:27 -0800 > Received: from ietfa.amsl.com (localhost [127.0.0.1]) by = ietfa.amsl.com (Postfix) with ESMTP id A407221F8B0A; Mon, 14 Jan 2013 = 11:34:26 -0800 (PST) > Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com = (Postfix) with ESMTP id A125621F8B0A for ; Mon, 14 = Jan 2013 11:34:24 -0800 (PST) > Received: from mail.ietf.org ([64.170.98.30]) by localhost = (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id = KZzoF6+FgtX6 for ; Mon, 14 Jan 2013 11:34:24 -0800 = (PST) > Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com = [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 21EC021F8835 for = ; Mon, 14 Jan 2013 11:34:24 -0800 (PST) > Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) = by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID = DSNKUPRdv9HyXDLONIs9rc1+EpHEa/GH84BU@postini.com; Mon, 14 Jan 2013 = 11:34:24 PST > Received: from archivist.nominum.com (archivist.nominum.com = [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 = bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification = Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP = id 8BD501B8206 for ; Mon, 14 Jan 2013 11:34:23 -0800 = (PST) > Received: from webmail.nominum.com (cas-01.win.nominum.com = [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) = (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification = Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS = id 829D5190052 for ; Mon, 14 Jan 2013 11:34:23 -0800 = (PST) (envelope-from Ted.Lemon@nominum.com) > Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by = CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; = Mon, 14 Jan 2013 11:34:23 -0800 > X-Cloudmark-Sp-Filtered: true > X-Cloudmark-Sp-Result: v=3D1.1 = cv=3DU4htmO7/4sz3yOR16BijurcNL+01Djw9h1JA4FArFPI=3D c=3D1 sm=3D1 = a=3DolelEfMTs3wA:10 a=3DkxW20L_ify8A:10 a=3DVSTLsr1XqWgA:10 = a=3DwPDyFdB5xvgA:10 a=3Dkj9zAlcOel0A:10 a=3DxqWC_Br6kY4A:10 = a=3DDicYa/0wwzYB8wgUeFDfZw=3D=3D:17 a=3DAUd_NHdVAAAA:8 a=3D48vgC7mUAAAA:8 = a=3D7xfA-TlN0T-YXiNNWBQA:9 a=3DCjuIK1q_8ugA:10 a=3DJfD0Fch1gWkA:10 = a=3DlZB815dzVvQA:10 a=3DHpAAvcLHHh0Zw7uRqdWCyQ=3D=3D:117 > X-Ironport-Anti-Spam-Filtered: true > X-Ironport-Anti-Spam-Result: = A8C7BgDWXPRQ/5AYASCBk7CAAACEgB5EgmuDCLRRgzYWc4IeAQEBAQMBAQEMASoGAQEECgMbDA= IDAQIGAQEBASAKFAgIAwEjCyUBAQQTBQOIEQELmReKcwGEOgEFjDYCBJBNYaZXgnWCJA > X-Ipas-Result: = A8C7BgDWXPRQ/5AYASCBk7CAAACEgB5EgmuDCLRRgzYWc4IeAQEBAQMBAQEMASoGAQEECgMbDA= IDAQIGAQEBASAKFAgIAwEjCyUBAQQTBQOIEQELmReKcwGEOgEFjDYCBJBNYaZXgnWCJA > X-Ironport-Av: E=3DSophos;i=3D"4.84,468,1355126400"; = d=3D"scan'208";a=3D"24788762" > Dkim-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org;= s=3Dietf1; t=3D1358192066; = bh=3DMKJbZ4aIwwpLwTInEH/iSbN2JkXpvC4EdRf269wIxCs=3D; = h=3DFrom:To:Date:Message-ID:References:In-Reply-To:Content-ID: = MIME-Version:Subject:List-Id:List-Unsubscribe:List-Archive: = List-Post:List-Help:List-Subscribe:Content-Type: = Content-Transfer-Encoding:Sender; = b=3DgIDk/Dd0H95b8mt5RylOSZ2VBHSQKdhLg4jYGXgP56a/HZf3+sm+2R68hJgUnu+kf = 4X1fidq/VtlOqyiQtWQZzH91YsUmNlED6tC+OWVXAWh0RFhD39r7NjMtw5QHU6nuoo = p5HOtsvoUhaajAPNJEtoUX3PX+JLwgaZ+RJ8eims=3D > X-Virus-Scanned: amavisd-new at amsl.com > X-Spam-Flag: NO > X-Spam-Score: -106.599 > X-Spam-Status: No, score=3D-106.599 tagged_above=3D-999 required=3D5 = tests=3D[BAYES_00=3D-2.599, RCVD_IN_DNSWL_MED=3D-4, = USER_IN_WHITELIST=3D-100] > Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soA=3D > Message-Id: = <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> > References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> = <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> > In-Reply-To: = <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> > Accept-Language: en-US > Content-Language: en-US > X-Originating-Ip: [192.168.1.10] > Content-Id: <2686CBF77EAD0340A29B68782358E5BF@nominum.com> > Mime-Version: 1.0 > X-Beenthere: dhcwg@ietf.org > X-Mailman-Version: 2.1.12 > Precedence: list > List-Id: > List-Unsubscribe: , = > List-Archive: > List-Post: > List-Help: > List-Subscribe: , = > Content-Type: text/plain; charset=3D"us-ascii" > Content-Transfer-Encoding: 7bit > Sender: dhcwg-bounces@ietf.org > Errors-To: dhcwg-bounces@ietf.org >=20 > On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) = wrote: >> A 2nd Query regarding this as I heard nothing since the first. >=20 > Oops, sorry about that, Bernie. >=20 > Folks, the authors of this draft feel it's ready for a WGLC. There's = been substantial discussion and comment already. This is pretty = important IPv6 deployment work, so more eyes are better. Please review = the draft and indicate whether or not you feel it is ready to be = published. We have been getting very anemic responses to working group = messages recently. Your response matters, so please do respond. >=20 > We will evaluate consensus after January 28. Thanks! >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From lorenzo@google.com Fri Feb 1 02:36: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 393E421F87E7 for ; Fri, 1 Feb 2013 02:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o92+oW+7jzuy for ; Fri, 1 Feb 2013 02:36:33 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id B2B1B21F879D for ; Fri, 1 Feb 2013 02:36:33 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id l10so4064934oag.16 for ; Fri, 01 Feb 2013 02:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Vcy5ZF+C1WjYph5kf76hNrArPAwMlWLVwQIbxhN6L+I=; b=gim0vAAOqen9R25HABp/s1mZTCXbwqHL3YfJ7LliZyY25QRqFRHD2H2Z9dewkh7PJo izv5tv9uX2Znca5/5jFY2loLBRBOHcKEqY7qbxo/vmPK4eRzBgbFbPwmSaEsHJOuFAJW AjCJkpcmtSTFVXWG8YRc/dW/FgwvNsj77lnmwWkPHvaZqhdm7ViNaam1kawzEEf/xxyM KuScCccAuA5Nsvk0anT+6dPPpJC1En6xF+RnA0L660ki9K1YuAuLAupnKHHQY06QMZt0 K7Tl8HJDndsGWz6NJ5YlJijUW9/3U5l9iHgszl60PrkQi5KSHg9n3+exFsWw+4ph4jRG xaNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Vcy5ZF+C1WjYph5kf76hNrArPAwMlWLVwQIbxhN6L+I=; b=YRxsfJiRcdzd3keO6a2ENmE/FvzWGY69y7RTPY90NaVlSNGSajEiDxZDCMA4PsQzGx UMQW7bWfcRgxzQHv/wP8/l647iTth0x6ymNq675YbHOxKGK6NfBsu4JjlEi0mMPtkrqJ XBbRuPKX9sw2IXqSoiM5u3G5T6tSpmNXAqWZwjNVuvnHilL7GBkg5VZIOoF+oIHbiWXQ FkNq2jcUEWbnNSlI06ZvzsxjKMNj4MXEXRNNPCMgzVA91wcb33/ofcKjbbYPOSkEo38s b7c777UlmH+g4TEqY6vk4F8uSSdQWfBRjOZy9yNJ8uSs9l4fS5f3z0jWEN5VARp1Xer5 Azeg== X-Received: by 10.182.226.103 with SMTP id rr7mr8860499obc.76.1359714993102; Fri, 01 Feb 2013 02:36:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.144.169 with HTTP; Fri, 1 Feb 2013 02:36:12 -0800 (PST) In-Reply-To: <20130131115726.GA387@spike.0x539.de> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <20130131115726.GA387@spike.0x539.de> From: Lorenzo Colitti Date: Fri, 1 Feb 2013 19:36:12 +0900 Message-ID: To: Philipp Kern Content-Type: multipart/alternative; boundary=f46d0447961728de2004d4a751b0 X-Gm-Message-State: ALoCoQm09I1b8pvG81pDJjYAaBwyLvG+RvmKAOYYEC4+laK7MGe5naZj8rv0RLoeURId40NP4gCHxCrtP8ACr92Bs9gXSO8gRMFGIM8lZBKEXmTGF2KBLgVEWx9uJ5fp5fAQkoNCuoRoN1ChttfKqIP/pauj7wsm89KIriBB3/eytWMCDqiS+FdgHYSsPjVe8ZwYkdrpMVtN Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 10:36:34 -0000 --f46d0447961728de2004d4a751b0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 31, 2013 at 8:57 PM, Philipp Kern wrote: > > The way I see it, the document's goal is not to define operational > > practices, but to define a device profile ("you must support features X, > Y, > > and Z"). I think this sort of thing does not belong in the IETF: the IETF > > should define the technology, not how it's integrated. I think this sort > of > > thing is best left to cellular standards bodies like 3GPP. > > *cough* RFC 6540. ;-) > Which, of course, is so successful that vendors all over are scrambling to implement IPv6 in all their products, just because the IETF told them to. Not. --f46d0447961728de2004d4a751b0 Content-Type: text/html; charset=ISO-8859-1
On Thu, Jan 31, 2013 at 8:57 PM, Philipp Kern <phil@philkern.de> wrote:
> The way I see it, the document's goal is not to define operational
> practices, but to define a device profile ("you must support features X, Y,
> and Z"). I think this sort of thing does not belong in the IETF: the IETF
> should define the technology, not how it's integrated. I think this sort of
> thing is best left to cellular standards bodies like 3GPP.

*cough* RFC 6540. ;-)

Which, of course, is so successful that vendors all over are scrambling to implement IPv6 in all their products, just because the IETF told them to. Not.
--f46d0447961728de2004d4a751b0-- From lorenzo@google.com Fri Feb 1 02:43: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 C289321F880E for ; Fri, 1 Feb 2013 02:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtiVgcjgQBFd for ; Fri, 1 Feb 2013 02:43:25 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7AD21F879B for ; Fri, 1 Feb 2013 02:43:25 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i18so3788535oag.1 for ; Fri, 01 Feb 2013 02:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cVLq3n6+HS2NYqfm0G5MK7xF2PTm3DRcX62MqSC+pO8=; b=l8Ymb75WOzFhRKhn1q5fYYYxEThHmax3JwurEXSpmCuCD0GcTazfb5Te+w6TjmkoS4 3ob4wKWVxlpLphroOQJy0BatH1hzvLMoL+kq9Aw2OOuYk45jnrHHnIN5G0CyTQ8cKRex lSuAmJWuIZfqx0WGtdbN81OQeiM4npGSUzpjZ/g5nVmibyDqJ0NV1WkFqGFES/vhOQmA fyTw9G3ohGH8wGzjnIZ2sKwmU0oBn2DvQMmTcf5gdvxNv2Spypo0+DCIkp3LFSjtodSi pXxfkqLutPcyaX9clAcPpSttZTZSMipmC01oZC4Rke/HKxYdDbt1su+IJKyOETQfFYk+ E1sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=cVLq3n6+HS2NYqfm0G5MK7xF2PTm3DRcX62MqSC+pO8=; b=Lkv4IDiVTsHueklzLg91NuOAxWvkWXspZGDlRftINnq2v8uxLIGyv7dh6nB4A5jmKI K5S8mVXGSOFuIDzEl99PwJMf+Yg3u7GN5hC3PFfAyUbbp/dUFsMZYY/gVspGsjg7K1s5 unO7uPfUcjgJ4T15WWPuI4PS7Ax3GJOTkOQqgjlE6q1cjDP3StTJ9kiRcDDEF8PjVkf1 3rfzC12ezWkz5r9W6hz6POC9i/3YdZLMh2PCOW1n2SRZpYeGlYrTJ3fOJFysbnUcvQ1y Ww9N+r/j2My7yNDbSFEcXuHWbN3rzfilP7Clt8UlBt2aS54rdgzhPLbCOoMGQZUsVC0g 0esw== X-Received: by 10.60.6.199 with SMTP id d7mr8934440oea.137.1359715404765; Fri, 01 Feb 2013 02:43:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.144.169 with HTTP; Fri, 1 Feb 2013 02:43:04 -0800 (PST) In-Reply-To: <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> From: Lorenzo Colitti Date: Fri, 1 Feb 2013 19:43:04 +0900 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=e89a8fb1fd74b259c504d4a769b4 X-Gm-Message-State: ALoCoQlIdZOGWtWAMmt7U9VfXJKOpZIQKKvR4jQgLyys6PgKHQFcYp064S4mSU/vT7z1pwMLwOc7zLOVUnBLiE4qqnLGViOfkUBKU5nCVRlkFTo9hpWCExsWonqRFBW+R0zgrTcnmhSglOerGfTAsL/X58DeEBJlRw9+eKKMFpEKkxnGTTyyLjxxuvZ6p6pp/UDZDBjC0Fa9 Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 10:43:25 -0000 --e89a8fb1fd74b259c504d4a769b4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Feb 1, 2013 at 6:31 AM, Warren Kumari wrote: > When I wrote that I though that this should be done somewhere else, I > didn't actually stop and figure out *where* else=85 > The way I see it, it doesn't matter where else. The IETF has no authority to mandate what vendors do and do not implement, only how they implement it. And since the IETF has no authority over this, it follows that the document will have a similar level of effect whether it's published as an IETF RFC or as a text file in my home directory: in both cases, approximately none. If a collection of operators got together and drew up a certification profile accompanied by a conformance test, and agreed to hold vendors to it, then that would be more useful. But the IETF is not the place to do that. --e89a8fb1fd74b259c504d4a769b4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 1, 2013 at 6:31 AM, Warren Kumari <warren@kum= ari.net> wrote:
When I wrote that I though that this should= be done somewhere else, I didn't actually stop and figure out *where* = else=85

The way I see it, it doesn'= ;t matter where else. The IETF has no authority to mandate what vendors do = and do not implement, only how they implement it. And since the IETF has no= authority over this, it follows that the document will have a similar leve= l of effect whether it's published as an IETF RFC or as a text file in = my home directory: in both cases, approximately none.

If a collection of operators got together a= nd drew up a certification profile accompanied by a conformance test, and a= greed to hold vendors to it, then that would be more useful. But the IETF i= s not the place to do that.
--e89a8fb1fd74b259c504d4a769b4-- From ales.vizdal@t-mobile.cz Fri Feb 1 03:06: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 20B8121F86A6 for ; Fri, 1 Feb 2013 03:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeiCWlaN+r3q for ; Fri, 1 Feb 2013 03:06:26 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 644C221F8692 for ; Fri, 1 Feb 2013 03:06:24 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 1DECE28582B; Fri, 1 Feb 2013 12:06:23 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Fri, 1 Feb 2013 12:06:22 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Fri, 1 Feb 2013 12:07:23 +0100 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac3/uZVkCNLhYJtwScK6JslPs4DuGgAsLn3Q Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA33B6E@SRVHKE02.rdm.cz> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <510A75DA.60305@gmail.com> In-Reply-To: <510A75DA.60305@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 11:06:27 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Thursday, January 31, 2013 2:47 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] Test for adoption as a working group document - Re: = I-D Action: > draft-binet-v6ops-cellular-host-requirements-02.txt >=20 > HEllo, >=20 > This draft had a competitor in the same space IIRC? What was the name > of that draft? You're talking about draft-ietf-v6ops-rfc3316bis-00. These drafts are not competing as each of them has a different goal. =20 > In this draft, there is a section about which I have high interest - > "4. Cellular Devices with LAN Capabilities". This approaches very much > to what an IPv6 Mobile Router is, whose one particular interface is > cellular and others are LAN. >=20 > In this respect, implementing an IPv6 Mobile Router there are several > possibilities and each may have an impact on that cellular interface. >=20 > For example, the use of Prefix Delegation has an impact on the cellular > interface - and that is already said as REQ#27. > But there are others. For example, the use of IPv6 Network Prefix > Translation, or, not least, the use of Mobile IPv6 (with NEMO extensions > if possible). This latter is all the more important since it is > mentioned in the IPv6 Node Requirements document, and this draft also > mentions that in addition to the cellular interface there is a WiFi > interface - only Mobile IPv6 is able to make handovers between the two > interfaces. It's a scope question. Can you please review the draft and provide us with your comments? > Regards, >=20 > Alex Ales From pete@systemnet.no Fri Feb 1 03:21: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 C122A21F871F for ; Fri, 1 Feb 2013 03:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy8RdcnTt-g3 for ; Fri, 1 Feb 2013 03:21:20 -0800 (PST) Received: from hk18-1.systemnet.no (hk18-1.systemnet.no [195.214.201.42]) by ietfa.amsl.com (Postfix) with ESMTP id E3EF121F8658 for ; Fri, 1 Feb 2013 03:21:19 -0800 (PST) Received: from [127.0.0.1] (pete@localhost.systemnet.no [127.0.0.1]) by hk18-1.systemnet.no (8.13.6/8.13.6) with ESMTP id r11BLFjd017580 for ; Fri, 1 Feb 2013 12:21:15 +0100 (CET) From: Pete Vickers Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Feb 2013 12:21:16 +0100 References: <7CC3086C-67FB-4E0D-9DB5-864D7EE23498@gmail.com> To: "v6ops@ietf.org" Message-Id: <67D53A24-64FF-4E57-9E32-958F1F91BC00@systemnet.no> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [v6ops] Fwd: v6ops Digest, Vol 30, Issue 1 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Feb 2013 11:21:20 -0000 >=20 > ------------------------------ >=20 > Message: 5 > Date: Fri, 1 Feb 2013 19:43:04 +0900 > From: Lorenzo Colitti > To: Warren Kumari > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Test for adoption as a working group document - > Re: I-D Action: = draft-binet-v6ops-cellular-host-requirements-02.txt > Message-ID: > = > Content-Type: text/plain; charset=3D"windows-1252" >=20 > On Fri, Feb 1, 2013 at 6:31 AM, Warren Kumari = wrote: >=20 >> When I wrote that I though that this should be done somewhere else, I >> didn't actually stop and figure out *where* else? >>=20 >=20 > The way I see it, it doesn't matter where else. The IETF has no = authority > to mandate what vendors do and do not implement, only how they = implement > it. And since the IETF has no authority over this, it follows that the > document will have a similar level of effect whether it's published as = an > IETF RFC or as a text file in my home directory: in both cases, > approximately none. I don't see why authority is necessary to provide a document that will = be useful to many purposes. e.g.: - companies could point to it to pressure vendors to adhere. =E0 la DoD = and IPv6. - Autoritive bodies (e.g. 3GPP etc) can take it as input to drastically = reduce the timescales to ratify their own standards. - analysis, debugging and development environments could use it as an = aide-m=E9moire to ensure that relevant ground is covered in a consistent = way. >=20 > If a collection of operators got together and drew up a certification > profile accompanied by a conformance test, and agreed to hold vendors = to > it, then that would be more useful. But the IETF is not the place to = do > that. Indeed, and they could refer to a relevant RFC in that process. /Pete From ales.vizdal@t-mobile.cz Fri Feb 1 03:43: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 408CD21F86A8 for ; Fri, 1 Feb 2013 03:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drBLKXPJuhiP for ; Fri, 1 Feb 2013 03:43:34 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72C21F869E for ; Fri, 1 Feb 2013 03:43:33 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id C8957285801 for ; Fri, 1 Feb 2013 12:43:26 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Fri, 1 Feb 2013 12:43:26 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Fri, 1 Feb 2013 12:43:59 +0100 Thread-Topic: Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac3/Hr/hhpm94phNTmizV++52lYshABTZtXQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> In-Reply-To: <5109723D.4090905@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 11:43:35 -0000 Hi, speaking as an Operator (not as a co-author) working on IPv6 introduction i= n Mobile. I see this document useful as it * defines a cellular IPv6 profile not yet specified anywhere else * goes behind the 3GPP architecture using NAT64, 464xlat, etc. features th= at are not part of the 3GPP architecture * can serve as basis for testing / validation later on As IPv6 has been 'invented' by the IETF, it seems to me to be the right pla= ce to look into=20 what IPv6 means for these devices (as has already been done for CPEs in 620= 4, IPv6 Nodes=20 in 6434). Secondly, this group has the right skill set required for such a work. Ales > -----Original Message----- > From: joel jaeggli [mailto:joelja@bogus.com] > Sent: Wednesday, January 30, 2013 8:19 PM > To: IPv6 Ops WG; draft-binet-v6ops-cellular-host-requirements@tools.ietf.= org > Subject: Test for adoption as a working group document - Re: I-D Action: = draft-binet- > v6ops-cellular-host-requirements-02.txt >=20 > Greetings, >=20 > This kicks of a request for adoption as a working group document on > draft-binet-v6ops-cellular-host-requirements-02.txt >=20 > This document and a similar one were discussed during IETF 85 and were > updated accordingly. Support was far from unanimous at the time and > we're interested in seeing how far it has progressed. >=20 > The deadline for this discussion phase is two weeks from today, 2/13. >=20 > thanks > joelja >=20 > On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : Internet Protocol Version 6 (IPv6) Requirements for = Cellular Hosts > > Author(s) : David Binet > > Mohamed Boucadair > > Ales Vizdal > > Cameron Byrne > > Gang Chen > > Filename : draft-binet-v6ops-cellular-host-requirements-02.txt > > Pages : 17 > > Date : 2013-01-30 > > > > Abstract: > > This document lists a set of IPv6-related requirements to be > > supported by cellular hosts. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requir= ements > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements= -02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-requ= irements-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From diego@tid.es Fri Feb 1 04:18: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 2CA6221F8653 for ; Fri, 1 Feb 2013 04:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSsHPTNPHZL2 for ; Fri, 1 Feb 2013 04:18:07 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66A1E21F8432 for ; Fri, 1 Feb 2013 04:18:06 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MHJ00E68JI0TL@tid.hi.inet> for v6ops@ietf.org; Fri, 01 Feb 2013 13:18:05 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 79.A9.03184.C72BB015; Fri, 01 Feb 2013 13:18:04 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MHJ00E6HJI4TL@tid.hi.inet> for v6ops@ietf.org; Fri, 01 Feb 2013 13:18:04 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([fe80::e1e3:e2fc:beda:deb9%15]) with mapi id 14.02.0318.004; Fri, 01 Feb 2013 13:18:04 +0100 Date: Fri, 01 Feb 2013 12:18:04 +0000 From: "Diego R. Lopez" In-reply-to: <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> X-Originating-IP: [10.95.64.115] To: =?Windows-1252?Q?V=EDzdal_Ale=9A?= Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-index: Ac3/Hr/h7dSlfpZADUKyUvpzKaEL9wBTZtXQAABcSAA= X-AuditID: 0a5f4068-b7fc06d000000c70-48-510bb27c25b5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLKsWRmVeSWpSXmKPExsXCFe/ApVuziTvQ4Norc4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY//LSewFMxQrPt3axtzA2C/VxcjJISFgIvF3/18WCFtM4sK9 9WxdjFwcQgIbGCV2HFjNAuH8YJTY8+UkO4SziVHi++8pYC0sAqoSffOPsIHYbED2o+bfYEXC Al2MEtsWvWMFSXAKeEqcu3aWFWKHgsSfc4/BmkUEHCQefe4AizMDNc9bdwoszivgLdH26hUb RNxMYsGquUwQcUGJH5PvsUDE9SQ+/rnNCGGLSzS33oSKa0s8eXcBbCajgKzEu/nzWUEOEhHo ZpSY1vQVarGVxM6Fb6GeFpBYsuc8M4QtKvHy8T9WiDfnM0o8nb2JaQKjxCwkh8xCcsgsJIfM QnLILCSHLGBkXcUoVpxUlJmeUZKbmJmTbmCol5Gpl5mXWrKJERJ/GTsYl+9UOcQowMGoxMNr wMUdKMSaWFZcmXuIUZKDSUmUN2ANUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr20tUI43JbGy KrUoHyYlw8GhJMHLsxEoJViUmp5akZaZA0wyMGkmDk6Qdh6gdiOQGt7igsTc4sx0iPwpRlWO GRN7njMKseTl56VKifMGgBQJgBRllObBzXnFKA50sDCvCUiWB5gm4Sa8AhrOBDS8rRJseEki QkqqgdHwligHR/tB2QA93fZ5IXErJUvC5ojLfDD2vqmvde3+7AvejLHzRPK3Tw3TOnli4amL 2xOPnd+lsDXrtQH3nu1rEpeVHblauSD/ANdVJctDJ/KYJ/Yd3+4bw279Ufqpj8QvvyPRHZdb mFecN5A96OF6ky3q8XKbD/v3lKlv/NLEyLdWOveNcrcSS3FGoqEWc1FxIgCEAABQUAMAAA== References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 12:18:08 -0000 Hi, Speaking as another operator (and not co-author at all) I fully support Ale= s' view on this. When it comes to IPv6, IETF has much more influence than Lorenzo's home dir= (or any other source) in operator decisions. I do believe having this docu= ment will be helpful. Be goode, On 1 Feb 2013, at 12:43 , V=EDzdal Ale=9A wrote: > Hi, > > speaking as an Operator (not as a co-author) working on IPv6 introduction= in Mobile. > > I see this document useful as it > > * defines a cellular IPv6 profile not yet specified anywhere else > * goes behind the 3GPP architecture using NAT64, 464xlat, etc. feat= ures that are not part of the 3GPP architecture > * can serve as basis for testing / validation later on > > As IPv6 has been 'invented' by the IETF, it seems to me to be the right p= lace to look into > what IPv6 means for these devices (as has already been done for CPEs in 6= 204, IPv6 Nodes > in 6434). > > Secondly, this group has the right skill set required for such a work. > > Ales > >> -----Original Message----- >> From: joel jaeggli [mailto:joelja@bogus.com] >> Sent: Wednesday, January 30, 2013 8:19 PM >> To: IPv6 Ops WG; draft-binet-v6ops-cellular-host-requirements@tools.ietf= .org >> Subject: Test for adoption as a working group document - Re: I-D Action:= draft-binet- >> v6ops-cellular-host-requirements-02.txt >> >> Greetings, >> >> This kicks of a request for adoption as a working group document on >> draft-binet-v6ops-cellular-host-requirements-02.txt >> >> This document and a similar one were discussed during IETF 85 and were >> updated accordingly. Support was far from unanimous at the time and >> we're interested in seeing how far it has progressed. >> >> The deadline for this discussion phase is two weeks from today, 2/13. >> >> thanks >> joelja >> >> On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> >>> >>> Title : Internet Protocol Version 6 (IPv6) Requirements f= or Cellular Hosts >>> Author(s) : David Binet >>> Mohamed Boucadair >>> Ales Vizdal >>> Cameron Byrne >>> Gang Chen >>> Filename : draft-binet-v6ops-cellular-host-requirements-02.t= xt >>> Pages : 17 >>> Date : 2013-01-30 >>> >>> Abstract: >>> This document lists a set of IPv6-related requirements to be >>> supported by cellular hosts. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requir= ements >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements= -02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-requ= irements-02 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From Ted.Lemon@nominum.com Fri Feb 1 05:12: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 B1FA521F874A for ; Fri, 1 Feb 2013 05:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1ufjdkF1-QM for ; Fri, 1 Feb 2013 05:12:59 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id EFC7F21F8840 for ; Fri, 1 Feb 2013 05:12:58 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUQu/WnJsYq2VA3U9ApLcQrF0XcxVHPlZ@postini.com; Fri, 01 Feb 2013 05:12:59 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7DBC6108046 for ; Fri, 1 Feb 2013 05:12:58 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6DBAC190043; Fri, 1 Feb 2013 05:12:58 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 05:12:52 -0800 From: Ted Lemon To: " " Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: AQHOAFlzVvP8JTIPmUGgdBNqQEm9PZhlgRaA Date: Fri, 1 Feb 2013 13:12:51 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747478D80@mbx-01.win.nominum.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> <94C682931C08B048B7A8645303FDC9F36EA9C841B4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA9C841B4@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 13:12:59 -0000 On Feb 1, 2013, at 3:52 AM, wrote: > We edited this document to fill a void: have a comprehensive list of IPv6= requirements for mobile device.=20 I'm in favor of adopting this document. It's worth noting that if the wor= k is done here, it makes life really easy for 3GPP=97they can just referenc= e this document, or plagiarize it. Either produces the right outcome=97th= e document is defined by an open process, and it's adopted by a standards b= ody that cell phone providers are tuned in to. If 3GPP ignores it, it sti= ll serves as a standard for which support can be claimed as a differentiati= ng factor if other devices don't follow the standard, so I think even in th= at case it's still worth doing. From wesley.george@twcable.com Fri Feb 1 06:51: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 8CDFC11E8099 for ; Fri, 1 Feb 2013 06:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqWrjzcJ5O1s for ; Fri, 1 Feb 2013 06:51:41 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4874B11E8097 for ; Fri, 1 Feb 2013 06:51:41 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,579,1355115600"; d="scan'208,217";a="20576443" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Feb 2013 09:50:09 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 1 Feb 2013 09:51:40 -0500 From: "George, Wes" To: Lorenzo Colitti , Warren Kumari Date: Fri, 1 Feb 2013 09:51:40 -0500 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac4AaPsJPPbjGyHaRk2+oKws/wa0ggAIRfYA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033DAE6F66@PRVPEXVS15.corp.twcable.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> 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_2671C6CDFBB59E47B64C10B3E0BD5923033DAE6F66PRVPEXVS15cor_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 14:51:43 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD5923033DAE6F66PRVPEXVS15cor_ 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 L= orenzo Colitti The IETF has no authority to mandate what vendors do and do not implement, = only how they implement it. And since the IETF has no authority over this, = it follows that the document will have a similar level of effect whether it= 's published as an IETF RFC or as a text file in my home directory: in both= cases, approximately none. If a collection of operators got together and drew up a certification profi= le accompanied by a conformance test, and agreed to hold vendors to it, the= n that would be more useful. But the IETF is not the place to do that. [WEG] I agree that IETF has no authority to do anything more than publish a= standard and hope that it's useful enough that more than one vendor implem= ents it per our guidance such that it's interoperable. That said, you appea= r to be missing the point of both this document and 6540. In cases like the= se, the IETF provides an easily referenced document (unlike, say, a text fi= le in your home directory), and then the collection of operators uses that = document in things like RFPs and their own certification testing to make it= clear to vendors exactly what they expect. It may even form the basis of a= standard from another SDO that has more enforcement teeth. Specifically in= the case of documents like these, we've found (and I assume that you have = too) that you have to be significantly more specific than "must support IPv= 6" when it comes to asking vendors to implement it *properly*. This documen= t helps address that need. Keep in mind that a lot of the other potential SDOs in this space like to d= o things like require membership and or payment to even ACCESS their standa= rds documents, making it a bit difficult to use them as a useful shorthand = for conveying requirements to vendors. And as noted by previous folks, acce= ss to build a standard is similarly controlled, unlike IETF's open particip= ation. I think this document is useful as a WG doc, but I agree that it would be h= elpful to expand on the requirements with additional technical justificatio= n on why they are MUST, SHOULD, MAY. Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD5923033DAE6F66PRVPEXVS15cor_ 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 Lorenzo Colitti

The IETF has no authority to mandate what vendors do= and do not implement, only how they implement it. And since the IETF has n= o authority over this, it follows that the document will have a similar lev= el of effect whether it's published as an IETF RFC or as a text file in my home directory: in both cases, appr= oximately none.

 

If a collection of operators got together and drew u= p a certification profile accompanied by a conformance test, and agreed to = hold vendors to it, then that would be more useful. But the IETF is not the= place to do that.

 <= /p>

[WEG] I agree that IETF h= as no authority to do anything more than publish a standard and hope that i= t’s useful enough that more than one vendor implements it per our guidance such that it’s interoperable. That said, you appear= to be missing the point of both this document and 6540. In cases like thes= e, the IETF provides an easily referenced document (unlike, say, a text fil= e in your home directory), and then the collection of operators uses that document in things like RFPs and their o= wn certification testing to make it clear to vendors exactly what they expe= ct. It may even form the basis of a standard from another SDO that has more= enforcement teeth. Specifically in the case of documents like these, we’ve found (and I assume that = you have too) that you have to be significantly more specific than “m= ust support IPv6” when it comes to asking vendors to implement it *pr= operly*. This document helps address that need.

Keep in mind that a lot o= f the other potential SDOs in this space like to do things like require mem= bership and or payment to even ACCESS their standards documents, making it a bit difficult to use them as a useful shorthand for conveying = requirements to vendors. And as noted by previous folks, access to build a = standard is similarly controlled, unlike IETF’s open participation.

 <= /p>

I think this document is = useful as a WG doc, but I agree that it would be helpful to expand on the r= equirements with additional technical justification on why they are MUST, SHOULD, MAY.

 <= /p>

Wes George


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_2671C6CDFBB59E47B64C10B3E0BD5923033DAE6F66PRVPEXVS15cor_-- From sm@resistor.net Fri Feb 1 08:01: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 4644221E808A for ; Fri, 1 Feb 2013 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtNKj9njn8mk for ; Fri, 1 Feb 2013 08:01:33 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7821E8064 for ; Fri, 1 Feb 2013 08:01:30 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r11G1MqG021138; Fri, 1 Feb 2013 08:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359734487; bh=kGV7EpH9orbRWsgQmqYwh2SoqlQpeJjbp7J8zUT8SJY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GjSo4c5KspRp4gDLj1QzHmrWs+g7ypNcLGV6AWVsDSq+FawKzv+JPjrgNvB5gX4ZS E6lPglE07NpqGMKfAZ874RrxqSFHitbuuUuw1T+0XC7GU/mpSdAJ2VY/KRk936s43b pXbAFi6ts9XlXKMTzXakJ1Hj/3HYXFxCHCNyE9sw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359734487; i=@resistor.net; bh=kGV7EpH9orbRWsgQmqYwh2SoqlQpeJjbp7J8zUT8SJY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bCocfd94MDizBJx+tuO4WAo+St+nsuiqMgiphA6T+w/H/WHIbgccVBuO94XTDpL2x EYgCRwpBeldTY9AURGxYUnxCwFSo0Z+GM9dpTQvKYqumwcVmBxrmd1vRPkHfOtnsf3 cK/0pmQWjCEDhc/WNjKw7G6I5YiT9J5IrP91JSgk= Message-Id: <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 07:51:24 -0800 To: Brian E Carpenter From: SM In-Reply-To: <510B77E4.2060001@gmail.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 16:01:34 -0000 Hi Brian, At 00:08 01-02-2013, Brian E Carpenter wrote: >The draft has been finally approved by the IESG when some of us thought >it was on hold until somebody called consensus on the IPR question. > >I'm not one for appeals but this is very close to an appealable move. Yes. Regards, -sm From Nick.Heatley@ee.co.uk Fri Feb 1 04:35: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 C6BDF21F86A6 for ; Fri, 1 Feb 2013 04:35:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aO-MXSYwhsO for ; Fri, 1 Feb 2013 04:35:29 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6341821F842B for ; Fri, 1 Feb 2013 04:35:28 -0800 (PST) Received: from [85.158.136.35:58447] by server-11.bemta-5.messagelabs.com id 86/43-19159-F86BB015; Fri, 01 Feb 2013 12:35:27 +0000 X-Env-Sender: Nick.Heatley@ee.co.uk X-Msg-Ref: server-16.tower-125.messagelabs.com!1359722127!33845735!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17230 invoked from network); 1 Feb 2013 12:35:27 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-16.tower-125.messagelabs.com with SMTP; 1 Feb 2013 12:35:27 -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 ; Fri, 01 Feb 2013 12:38:49 +0000 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 ; Fri, 01 Feb 2013 12:35:26 +0000 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); Fri, 1 Feb 2013 12:35:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Feb 2013 12:35:25 -0000 Message-ID: In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac3/Hr/hhpm94phNTmizV++52lYshABTZtXQAAJdhVA= References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com><5109723D.4090905@bogus.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> From: "Heatley, Nick" To: "Vizdal Ales (TMCZ)" , X-OriginalArrivalTime: 01 Feb 2013 12:35:26.0196 (UTC) FILETIME=[9C7EE340:01CE0078] X-Mailman-Approved-At: Fri, 01 Feb 2013 08:16:33 -0800 Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 12:36:47 -0000 +1 Speaking as an operator I see a document ratified by the IETF as extremel= y useful. I would immediately use it in RFQ discussions, testing and ratification. I need a requirements document (very soon) that carries the weight of con= sensus. I wish for an IPv6 cellular profile document which sits above and is inde= pendent from the general release 8,9,10 approach of 3GPP. I fully agree 3= GPP do standards for mobile bearer interoperability, as per their release= s. But I think I require standards on internet interoperability, who does th= is if not the IETF? Best regards, Nick Heatley Senior Architect EE > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of V=EDzdal Ale=B9 > Sent: 01 February 2013 11:44 > To: v6ops@ietf.org > Subject: Re: [v6ops] Test for adoption as a working group document - > Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt >=20 > Hi, >=20 > speaking as an Operator (not as a co-author) working on IPv6 > introduction in Mobile. >=20 > I see this document useful as it >=20 > * defines a cellular IPv6 profile not yet specified anywhere else > * goes behind the 3GPP architecture using NAT64, 464xlat, etc. > features that are not part of the 3GPP architecture > * can serve as basis for testing / validation later on >=20 > As IPv6 has been 'invented' by the IETF, it seems to me to be the right= > place to look into what IPv6 means for these devices (as has already > been done for CPEs in 6204, IPv6 Nodes in 6434). >=20 > Secondly, this group has the right skill set required for such a work. >=20 > Ales >=20 > > -----Original Message----- > > From: joel jaeggli [mailto:joelja@bogus.com] > > Sent: Wednesday, January 30, 2013 8:19 PM > > To: IPv6 Ops WG; > > draft-binet-v6ops-cellular-host-requirements@tools.ietf.org > > Subject: Test for adoption as a working group document - Re: I-D > > Action: draft-binet- v6ops-cellular-host-requirements-02.txt > > > > Greetings, > > > > This kicks of a request for adoption as a working group document on > > draft-binet-v6ops-cellular-host-requirements-02.txt > > > > This document and a similar one were discussed during IETF 85 and > were > > updated accordingly. Support was far from unanimous at the time and > > we're interested in seeing how far it has progressed. > > > > The deadline for this discussion phase is two weeks from today, 2/13.= > > > > thanks > > joelja > > > > On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > > > > Title : Internet Protocol Version 6 (IPv6) Requirements > for Cellular Hosts > > > Author(s) : David Binet > > > Mohamed Boucadair > > > Ales Vizdal > > > Cameron Byrne > > > Gang Chen > > > Filename : draft-binet-v6ops-cellular-host-requirements- > 02.txt > > > Pages : 17 > > > Date : 2013-01-30 > > > > > > Abstract: > > > This document lists a set of IPv6-related requirements to be > > > supported by cellular hosts. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host- > req > > > uirements > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host- > requireme > > > nts-02 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-= > req > > > uirements-02 > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 Everything Everywhere Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshir= e, AL10 9BW From christian.jacquenet@orange.com Fri Feb 1 08:19: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 5410B21E8030 for ; Fri, 1 Feb 2013 08:19:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mKZuzoM6SR3 for ; Fri, 1 Feb 2013 08:19:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 68A9621E8044 for ; Fri, 1 Feb 2013 08:19:51 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A94AA26418E for ; Fri, 1 Feb 2013 17:19:50 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7769F4C06C for ; Fri, 1 Feb 2013 17:19:50 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 1 Feb 2013 17:19:50 +0100 From: To: "v6ops@ietf.org" Date: Fri, 1 Feb 2013 17:19:48 +0100 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac3/Hr/hhpm94phNTmizV++52lYshABTZtXQAAJdhVAACHxZkA== Message-ID: <28652_1359735590_510BEB26_28652_1540_10_983A1D8DA0DA5F4EB747BF34CBEE5CD15A6B275CE2@PUEXCB1C.nanterre.francetelecom.fr> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com><5109723D.4090905@bogus.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 16:19:52 -0000 Hi, I support the adoption of draft-binet-v6ops-cellular-host-requirements as a= v6ops WG document. Cheers, Christian. > > -----Original Message----- > > From: joel jaeggli [mailto:joelja@bogus.com] > > Sent: Wednesday, January 30, 2013 8:19 PM > > To: IPv6 Ops WG; > > draft-binet-v6ops-cellular-host-requirements@tools.ietf.org > > Subject: Test for adoption as a working group document - Re: I-D > > Action: draft-binet- v6ops-cellular-host-requirements-02.txt > > > > Greetings, > > > > This kicks of a request for adoption as a working group document on=20 > > draft-binet-v6ops-cellular-host-requirements-02.txt > > > > This document and a similar one were discussed during IETF 85 and > were > > updated accordingly. Support was far from unanimous at the time and=20 > > we're interested in seeing how far it has progressed. > > > > The deadline for this discussion phase is two weeks from today, 2/13. > > > > thanks > > joelja > > > > On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > > > > Title : Internet Protocol Version 6 (IPv6) Requirements > for Cellular Hosts > > > Author(s) : David Binet > > > Mohamed Boucadair > > > Ales Vizdal > > > Cameron Byrne > > > Gang Chen > > > Filename : draft-binet-v6ops-cellular-host-requirements- > 02.txt > > > Pages : 17 > > > Date : 2013-01-30 > > > > > > Abstract: > > > This document lists a set of IPv6-related requirements to be > > > supported by cellular hosts. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host- > req > > > uirements > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host- > requireme > > > nts-02 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host- > req > > > uirements-02 > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named per= son(s). If you are not the intended recipient, notify the sender immediate= ly, delete this email from your system and do not disclose or use for any p= urpose.=20=20 =20 We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you.=20 Everything Everywhere Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire,= AL10 9BW _______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Olaf.Bonness@telekom.de Fri Feb 1 08:26: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 3C3B521E8039 for ; Fri, 1 Feb 2013 08:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBlsifNi0-iE for ; Fri, 1 Feb 2013 08:26:26 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id B340421E8030 for ; Fri, 1 Feb 2013 08:26:25 -0800 (PST) Received: from he113599.emea1.cds.t-internal.com ([10.125.65.118]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 01 Feb 2013 17:26:23 +0100 Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.119]) by HE113599.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 1 Feb 2013 17:26:22 +0100 From: To: Date: Fri, 1 Feb 2013 17:26:21 +0100 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac4AmNivPmqAEYuWSS+evDDigiAuKQ== Message-ID: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 16:26:27 -0000 +1 Olaf > > -----Original Message----- > > From: joel jaeggli [mailto:joelja@bogus.com] > > Sent: Wednesday, January 30, 2013 8:19 PM > > To: IPv6 Ops WG; > > draft-binet-v6ops-cellular-host-requirements@tools.ietf.org > > Subject: Test for adoption as a working group document - Re: I-D > > Action: draft-binet- v6ops-cellular-host-requirements-02.txt > > > > Greetings, > > > > This kicks of a request for adoption as a working group document on=20 > > draft-binet-v6ops-cellular-host-requirements-02.txt > > > > This document and a similar one were discussed during IETF 85 and > were > > updated accordingly. Support was far from unanimous at the time and=20 > > we're interested in seeing how far it has progressed. > > > > The deadline for this discussion phase is two weeks from today, 2/13. > > > > thanks > > joelja > > > > On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > > > > Title : Internet Protocol Version 6 (IPv6) Requirements > for Cellular Hosts > > > Author(s) : David Binet > > > Mohamed Boucadair > > > Ales Vizdal > > > Cameron Byrne > > > Gang Chen > > > Filename : draft-binet-v6ops-cellular-host-requirements- > 02.txt > > > Pages : 17 > > > Date : 2013-01-30 > > > > > > Abstract: > > > This document lists a set of IPv6-related requirements to be > > > supported by cellular hosts. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host- > req > > > uirements > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host- > requireme > > > nts-02 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host- > req > > > uirements-02 > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named per= son(s). If you are not the intended recipient, notify the sender immediate= ly, delete this email from your system and do not disclose or use for any p= urpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legisl= ation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruse= s do not adversely affect you.=20 Everything Everywhere Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire,= AL10 9BW _______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From ales.vizdal@t-mobile.cz Fri Feb 1 09:00: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 B93C121E80B5 for ; Fri, 1 Feb 2013 09:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx8dm1TcrPHk for ; Fri, 1 Feb 2013 09:00:43 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26D21E80A3 for ; Fri, 1 Feb 2013 09:00:43 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id EE22E28582E; Fri, 1 Feb 2013 18:00:41 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Fri, 1 Feb 2013 18:00:41 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Lorenzo Colitti , Warren Kumari Date: Fri, 1 Feb 2013 17:59:50 +0100 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac4AaQfDDU6FrUHwRKaROemHWC6tvwALSuWg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA33CFC@SRVHKE02.rdm.cz> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> 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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 17:00:43 -0000 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= orenzo Colitti Sent: Friday, February 01, 2013 11:43 AM To: Warren Kumari Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-= D Action: draft-binet-v6ops-cellular-host-requirements-02.txt > If a collection of operators got together and drew up a certification pro= file accompanied by a conformance test, and agreed to hold vendors to it, t= hen that would be more useful. But the IETF is not the place to do that. Operators got together to work on this draft to align their requirements. C= onformance tests are happening internally ... further cooperation may follow. Let's set this as a basis. Ales From Tina.Tsou.Zouting@huawei.com Fri Feb 1 09:07:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F54F21E80A9 for ; Fri, 1 Feb 2013 09:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgLHQ5LZYe-3 for ; Fri, 1 Feb 2013 09:07:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3250421E80A4 for ; Fri, 1 Feb 2013 09:07:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id API52731; Fri, 01 Feb 2013 17:07:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 17:07:10 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 17:07:50 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.4]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Fri, 1 Feb 2013 09:07:45 -0800 From: Tina TSOU To: =?Windows-1252?Q?V=EDzdal_Ale=9A?= Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: AQHOAGkF7vXEUsLEMk6ZJiO1b7QNPZhlwGIA//98Gpw= Date: Fri, 1 Feb 2013 17:07:45 +0000 Message-ID: <3A300CE5-D664-4B01-9C07-A22F48564324@huawei.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <5F277A22-EBFF-4484-A4C0-D1FDC150EC9F@apple.com> <72D0ADC6-0E13-4B08-A502-1FE25A887B29@kumari.net> , <1808340F7EC362469DDFFB112B37E2FCC6CFA33CFC@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA33CFC@SRVHKE02.rdm.cz> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 17:07:56 -0000 Dear all, I support the adoption. Thank you, Tina On Feb 1, 2013, at 9:01 AM, "V=EDzdal Ale=9A" wro= te: > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Lorenzo Colitti > Sent: Friday, February 01, 2013 11:43 AM > To: Warren Kumari > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Test for adoption as a working group document - Re: = I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt >=20 >> If a collection of operators got together and drew up a certification pr= ofile accompanied by a conformance test, and agreed to hold vendors to it, = then that would be more useful. But the IETF is not the place to do that. >=20 > Operators got together to work on this draft to align their requirements.= Conformance tests are happening internally ... further cooperation > may follow. Let's set this as a basis. >=20 > Ales > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ietfc@btconnect.com Fri Feb 1 09:31:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D647E21E808F for ; Fri, 1 Feb 2013 09:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.737 X-Spam-Level: X-Spam-Status: No, score=-3.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzHyCaqdHKZh for ; Fri, 1 Feb 2013 09:31:42 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 32F8D21E8040 for ; Fri, 1 Feb 2013 09:31:42 -0800 (PST) Received: from mail33-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Feb 2013 17:31:41 +0000 Received: from mail33-ch1 (localhost [127.0.0.1]) by mail33-ch1-R.bigfish.com (Postfix) with ESMTP id 4EAB0C0225; Fri, 1 Feb 2013 17:31:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371I936eI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h304l1155h) Received: from mail33-ch1 (localhost.localdomain [127.0.0.1]) by mail33-ch1 (MessageSwitch) id 1359739899403474_7754; Fri, 1 Feb 2013 17:31:39 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail33-ch1.bigfish.com (Postfix) with ESMTP id 5E2381C0049; Fri, 1 Feb 2013 17:31:39 +0000 (UTC) Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Feb 2013 17:31:37 +0000 Received: from DB3PRD0210HT001.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 1 Feb 2013 17:31:30 +0000 Message-ID: <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> From: t.petch To: Brian E Carpenter , SM References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> Date: Fri, 1 Feb 2013 17:28:26 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-OriginatorOrg: btconnect.com Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 17:31:43 -0000 ----- Original Message ----- From: "SM" To: "Brian E Carpenter" Cc: "IPv6 Operations" ; Sent: Friday, February 01, 2013 3:51 PM > Hi Brian, > At 00:08 01-02-2013, Brian E Carpenter wrote: > >The draft has been finally approved by the IESG when some of us thought > >it was on hold until somebody called consensus on the IPR question. > > > >I'm not one for appeals but this is very close to an appealable move. > > Yes. Looking at the History on the tracker, on 30th January, Ron changed his position from Discuss to Yes, and Approved Publication, so out it went. Earlier on that day, China Mobile made a statement on IPR to which Cameron responded with a query, seeking clarification. I just observe. Tom Petch > Regards, > -sm From alexandru.petrescu@gmail.com Fri Feb 1 09: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 AD10F21E8049 for ; Fri, 1 Feb 2013 09:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THO7Fp40go4M for ; Fri, 1 Feb 2013 09:35:04 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACA721E8040 for ; Fri, 1 Feb 2013 09:35:03 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r11HYxYi003629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Feb 2013 18:34:59 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r11HYwuO002771; Fri, 1 Feb 2013 18:34:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r11HYotU008966; Fri, 1 Feb 2013 18:34:58 +0100 Message-ID: <510BFCBA.6060100@gmail.com> Date: Fri, 01 Feb 2013 18:34:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <510A75DA.60305@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33B6E@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA33B6E@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 17:35:07 -0000 Le 01/02/2013 12:07, Vízdal Ale¹ a écrit : >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Thursday, January 31, 2013 2:47 PM To: v6ops@ietf.org >> Subject: Re: [v6ops] Test for adoption as a working group document >> - Re: I-D Action: >> draft-binet-v6ops-cellular-host-requirements-02.txt >> >> HEllo, >> >> This draft had a competitor in the same space IIRC? What was the >> name of that draft? > > You're talking about draft-ietf-v6ops-rfc3316bis-00. These drafts are > not competing as each of them has a different goal. I don't understand? The abstract of one says: "This document lists a set of IPv6-related requirements to be supported by cellular hosts." and the abstract of the other includes: "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)." As an example which makes me think they compete, in the running text one draft says 'should' Prefix Exclude Option (of PD) and the other says MUST for the same. Both these recommendations are for cellular-enabled Hosts, right? >> In this draft, there is a section about which I have high interest >> - "4. Cellular Devices with LAN Capabilities". This approaches >> very much to what an IPv6 Mobile Router is, whose one particular >> interface is cellular and others are LAN. >> >> In this respect, implementing an IPv6 Mobile Router there are >> several possibilities and each may have an impact on that cellular >> interface. >> >> For example, the use of Prefix Delegation has an impact on the >> cellular interface - and that is already said as REQ#27. > >> But there are others. For example, the use of IPv6 Network Prefix >> Translation, or, not least, the use of Mobile IPv6 (with NEMO >> extensions if possible). This latter is all the more important >> since it is mentioned in the IPv6 Node Requirements document, and >> this draft also mentions that in addition to the cellular interface >> there is a WiFi interface - only Mobile IPv6 is able to make >> handovers between the two interfaces. > > It's a scope question. Can you please review the draft and provide > us with your comments? Yes, in section "4. Cellular Devices with LAN Capabilities" lists a number of requirements for Cellular Devices with LAN Capabilities. Some of these requirements request that that cellular-enabled device uses DHCP Prefix Delegation in order to obtain a Prefix for the LAN. But there exist other methods to achieve the same effect as assigning a Prefix on the LAN from DHCP-PD: Network Prefix Translation, and Prefix Delegation with Network Mobility. My comment is - why aren't these mentioned in the list of requirements? Regards, Alex > >> Regards, >> >> Alex > > Ales > From joelja@bogus.com Fri Feb 1 10:25: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 6853F21E8041 for ; Fri, 1 Feb 2013 10:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.344 X-Spam-Level: X-Spam-Status: No, score=-101.344 tagged_above=-999 required=5 tests=[AWL=-1.655, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9jg7AkPD-55 for ; Fri, 1 Feb 2013 10:25:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A524E21E8039 for ; Fri, 1 Feb 2013 10:25:37 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r11IPTGu013293 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 1 Feb 2013 18:25:30 GMT (envelope-from joelja@bogus.com) Message-ID: <510C0894.2020405@bogus.com> Date: Fri, 01 Feb 2013 10:25:24 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> In-Reply-To: <510B77E4.2060001@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 01 Feb 2013 18:25:32 +0000 (UTC) Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 18:25:38 -0000 On 2/1/13 12:08 AM, Brian E Carpenter wrote: > Joel, you're missing the point. I'm also wrong. Since the IETF last call commenced on december 7th. > > The draft has been finally approved by the IESG when some of us thought > it was on hold until somebody called consensus on the IPR question. the dicussion point that kicked this off was. Folks, Draft-ietf-v6ops-464xlat is nearly ready for IESG approval. However, several IESG members, including me, are concerned that the WG has not yet considered the IPR declaration attached to this document. So, I will wait one more week before approving this document. If you are concerned about the IPR declaration, please post a message describing your concerns to the list. If no such concerns are posted, I will approve the draft on January 17. The crucial point here is the working was aware at time of wglc of the IPR , there was however at the time, limited commentary on it (which is noted in the shepherds report). there was consensus to advance the document. > I'm not one for appeals but this is very close to an appealable move. It may well be. > IMHO a WG Chair needs to make a formal call on the IPR question PDQ, > and if necessary, urgently request the IESG to rescind its approval. > I hope it isn't necessary, but it isn't my place to make the call. My solicitation of additional input did not yield additional insight, there are a limited number of people staking out positions, I'm not sure what to conclude from that. There are certainly some people that belive that documents ipr claims associated with them that carry these terms should not be published under any circumstances or least with serious reservations, I'm fine with that as a position but it doesn't square with the WGLC. > Regards > Brian Carpenter > > On 01/02/2013 05:12, joel jaeggli wrote: >> On 1/31/13 5:47 PM, Ted Lemon wrote: >>> On Jan 31, 2013, at 6:26 PM, joel jaeggli wrote: >>>> Given an intended status of BCP, the next big step is IETF last call, >>>> which should not be construed as a reason to stop this discussion, >>>> quite the contrary. >>> Someone, I can't remember who (sorry!), pointed out that this >>> statement is true of Informational, but perhaps not of BCP. >> I think you mean vice-versa. if I'm wrong about it's current state then >> I missed something. version 9 and 8 still request the status of bcp as >> the wglc validated as well. >> >> we have hypothetically discussed whether the ipr is more palatable with >> an informational document. >>> That is, if the document is merely intended to document the >>> existing practice that some vendor follows, that is a good thing which >>> we should publish; however, it shouldn't be a BCP if the IPR terms are >>> not found to be acceptable. >>> >>> I haven't looked at it in depth, but a brief skim of the updated IPR >>> report that went by yesterday looked like it was a bit outside of the >>> norm for IETF standards, since it mentions charging royalties. >> Definition of what is RAND is somewhat fungible. It clearly is not in >> the style of non-assert clause which I would have no problems at all with. >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From joelja@bogus.com Fri Feb 1 10:31: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 BB56921F8D20 for ; Fri, 1 Feb 2013 10:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JBTV4aao7CX for ; Fri, 1 Feb 2013 10:31:24 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 649F221F8D09 for ; Fri, 1 Feb 2013 10:31:24 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r11IVFf2013381 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 1 Feb 2013 18:31:18 GMT (envelope-from joelja@bogus.com) Message-ID: <510C09EE.2000407@bogus.com> Date: Fri, 01 Feb 2013 10:31:10 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "t.petch" , Brian E Carpenter , SM References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> In-Reply-To: <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 01 Feb 2013 18:31:18 +0000 (UTC) Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 18:31:24 -0000 On 2/1/13 9:28 AM, t.petch wrote: > Earlier on that day, China Mobile made a statement on IPR to which > Cameron responded with a query, seeking clarification. I just observe. > Tom Petch It seems unlikely that a future response on their part will resolve the issue to the satisfaction of everyone. From rpaulo@apple.com Fri Feb 1 10: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 3525921F8C57 for ; Fri, 1 Feb 2013 10:33:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSPpM9QwL9ES for ; Fri, 1 Feb 2013 10:33:16 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5135521E805A for ; Fri, 1 Feb 2013 10:33:16 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MHK0076B0S3IED3@mail-out.apple.com> for v6ops@ietf.org; Fri, 01 Feb 2013 10:33:15 -0800 (PST) X-AuditID: 1180711d-b7f676d000004e79-3b-510c0a6bc978 Received: from rui-macbook-pro.apple.com (rui-macbook-pro.apple.com [17.193.13.39]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 76.C4.20089.B6A0C015; Fri, 01 Feb 2013 10:33:15 -0800 (PST) From: Rui Paulo In-reply-to: <5109723D.4090905@bogus.com> Date: Fri, 01 Feb 2013 10:33:14 -0800 Message-id: <988DC72B-F6C4-4277-8150-C19DC92DF8AD@apple.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1668) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUieJBXXTebiyfQ4HOrrsXn5c9ZLF6dWsNo cfrYXmYHZo+zRxYweixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGZuvChesZ644v/gTewPj NaYuRk4OCQETiYZfP1ggbDGJC/fWs3UxcnEICaxkkpi/oJEVJMEsoCVx499LsAZeAT2JLce7 GUGKhAU6GCU6F85iBkmwCShJPOs7wQ5icwpoSixu2grWwCKgIrFg1nuwqcwC8xklmg88gZqq LbFs4WtmiKk2Er8ndIDZQgJxEj3zdzGC2CICyhJ/Nl5ghjhPVmLj4ZdMExj5ZyE5ahaSo2Yh GbuAkXkVo2BRak5ipaGxXmJBQU6qXnJ+7iZGUDA2FMruYNz/k/8QowAHoxIPr99P7kAh1sSy 4srcQ4wSHMxKIry2tUAh3pTEyqrUovz4otKc1OJDjNIcLErivK8bOQKFBNITS1KzU1MLUotg skwcnFINjNFmP7dmrr/x++Y8n/v1eWoiP+WWGDhfMNl8+i/HqzThaptLW1uuLVldO+/HhnXs DefD+V2/nDG7/3S+5ruwgsBLXXLTRR9LGf858vGfU3D8ZutDM5JyPY8cCMzPE5bOCjn04rr1 2YWdOk7CM/tmaAdsWTnrsL3Kj/z3WT9ZWmdMrD9yfMFG1y4lluKMREMt5qLiRACQobOAQgIA AA== Cc: IPv6 Ops WG , "draft-binet-v6ops-cellular-host-requirements@tools.ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 18:33:17 -0000 On 30 Jan 2013, at 11:19, joel jaeggli wrote: > Greetings, > > This kicks of a request for adoption as a working group document on draft-binet-v6ops-cellular-host-requirements-02.txt Like others, I also don't think this should be an IETF document. If it ends up going forward, I would like it to mimic RFC 6092 in the use of normative keywords, like James pointed out. -- Rui Paulo From ales.vizdal@t-mobile.cz Fri Feb 1 11:26: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 F08BF21E8044 for ; Fri, 1 Feb 2013 11:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9xA+usscqsV for ; Fri, 1 Feb 2013 11:26:53 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2C13721E8050 for ; Fri, 1 Feb 2013 11:26:52 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 53A82285815; Fri, 1 Feb 2013 20:26:51 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Fri, 1 Feb 2013 20:26:51 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Fri, 1 Feb 2013 20:26:00 +0100 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: Ac4AonjV+clptMolQ3SOWQceLtrG3AADamEw Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA33D0C@SRVHKE02.rdm.cz> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <510A75DA.60305@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33B6E@SRVHKE02.rdm.cz> <510BFCBA.6060100@gmail.com> In-Reply-To: <510BFCBA.6060100@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Fri, 01 Feb 2013 19:26:54 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, February 01, 2013 6:35 PM > To: V=EDzdal Ale=B9 > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Test for adoption as a working group document - Re: = I-D Action: > draft-binet-v6ops-cellular-host-requirements-02.txt >=20 > Le 01/02/2013 12:07, V=EDzdal Ale=B9 a =E9crit : > >> -----Original Message----- From: v6ops-bounces@ietf.org > >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu > >> Sent: Thursday, January 31, 2013 2:47 PM To: v6ops@ietf.org > >> Subject: Re: [v6ops] Test for adoption as a working group document > >> - Re: I-D Action: > >> draft-binet-v6ops-cellular-host-requirements-02.txt > >> > >> HEllo, > >> > >> This draft had a competitor in the same space IIRC? What was the > >> name of that draft? > > > > You're talking about draft-ietf-v6ops-rfc3316bis-00. These drafts are > > not competing as each of them has a different goal. >=20 > I don't understand? >=20 > The abstract of one says: > "This document lists a set of IPv6-related requirements to be > supported by cellular hosts." >=20 > and the abstract of the other includes: > "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)." Section 1.1 provides the following explanation This document lists the required features while [I-D.ietf-v6ops-rfc3316bis] is doing a good job in identifying issues and explaining how to implement basic IPv6 features in a mobile context. Some of the features discussed in [I-D.ietf-v6ops-rfc3316bis] are also listed in this document as a requirement: the main reason is to collect in one single document a comprehensive list of requirements with the required language. =20 > As an example which makes me think they compete, in the running text one > draft says 'should' Prefix Exclude Option (of PD) and the other says > MUST for the same. Both these recommendations are for cellular-enabled > Hosts, right? >=20 > >> In this draft, there is a section about which I have high interest > >> - "4. Cellular Devices with LAN Capabilities". This approaches > >> very much to what an IPv6 Mobile Router is, whose one particular > >> interface is cellular and others are LAN. > >> > >> In this respect, implementing an IPv6 Mobile Router there are > >> several possibilities and each may have an impact on that cellular > >> interface. > >> > >> For example, the use of Prefix Delegation has an impact on the > >> cellular interface - and that is already said as REQ#27. > > > >> But there are others. For example, the use of IPv6 Network Prefix > >> Translation, or, not least, the use of Mobile IPv6 (with NEMO > >> extensions if possible). This latter is all the more important > >> since it is mentioned in the IPv6 Node Requirements document, and > >> this draft also mentions that in addition to the cellular interface > >> there is a WiFi interface - only Mobile IPv6 is able to make > >> handovers between the two interfaces. > > > > It's a scope question. Can you please review the draft and provide > > us with your comments? >=20 > Yes, in section "4. Cellular Devices with LAN Capabilities" lists a > number of requirements for Cellular Devices with LAN Capabilities. Some > of these requirements request that that cellular-enabled device uses > DHCP Prefix Delegation in order to obtain a Prefix for the LAN. >=20 > But there exist other methods to achieve the same effect as assigning a > Prefix on the LAN from DHCP-PD: Network Prefix Translation, and Prefix > Delegation with Network Mobility. >=20 > My comment is - why aren't these mentioned in the list of requirements? There has been no demand for anything else than DHCP-PD so far. =20 > Regards, >=20 > Alex >=20 > > > >> Regards, > >> > >> Alex > > > > Ales Ales From fred@cisco.com Fri Feb 1 13:25: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 49AEB21E8044 for ; Fri, 1 Feb 2013 13:25:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcpMMZI8DqyL for ; Fri, 1 Feb 2013 13:25:51 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68B11E80A3 for ; Fri, 1 Feb 2013 13:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2179; q=dns/txt; s=iport; t=1359753951; x=1360963551; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=M6u/PhGU7Beq29gMZua/klkcxzN0NSSV/zR8j9QjFvU=; b=E9kGHxMZ8gIXs2vOUWTGpixajlq8RQhc1pAYUhHiRLVb88PfH8E55mpZ VIL0mJSwvRXSGdKD9A/9lGJlw9mEr8T21T8+G3BA7DTYPzvHJmb1VwRTE othj6CV1Yb74cEWw+twcvuM8ouq3kUWiAmQzCco/rof96PTK1vEN78Yam k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABYyDFGtJV2a/2dsb2JhbABFvy8Wc4IgAQRlCQsSASpWJwQODYgJwwqQbWEDpmeCfIIk X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="172008172" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 01 Feb 2013 21:25:50 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r11LPopg024347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 21:25:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 15:25:50 -0600 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: State of the Union in v6ops Thread-Index: AQHOAMK0fxAl927+50emhvUk4XsVUw== Date: Fri, 1 Feb 2013 21:25:49 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B765D4D@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="Windows-1252" Content-ID: <1640CD73DCA54A429B58B9CC89347B56@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joel Jaeggli , Ron Bonica Subject: [v6ops] State of the Union in v6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Feb 2013 21:25:52 -0000 Per my notes and the data tracker: RFC Editor: Feb 21 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt Oct 30 draft-ietf-v6ops-6204bis-12.txt Nov 14 draft-ietf-v6ops-ra-guard-implementation-07.txt Jan 11 draft-ietf-v6ops-icp-guidance-05.txt IESG: Jan 21 draft-ietf-v6ops-464xlat-09.txt WGLC: Jan 31 draft-ietf-v6ops-nat64-experience-01.txt In discussion regarding WG status: Jan 30 draft-binet-v6ops-cellular-host-requirements-02.txt NEEDS UPDATE: Sep 15 draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt CURRENT: Nov 12 draft-ietf-v6ops-rfc3316bis-00.txt=20 Nov 13 draft-generic-v6ops-tunmtu-12.txt=20 Dec 15 draft-ietf-v6ops-64share-00.txt=20 Jan 14 draft-smith-v6ops-larger-ipv6-loopback-prefix-02.txt=20 Jan 15 draft-liu-v6ops-ula-usage-analysis-04.txt=20 Jan 24 draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt=20 Jan 25 draft-v6ops-vyncke-balanced-ipv6-security-00.txt=20 Jan 29 draft-ietf-v6ops-64share-01.txt Jan 30 draft-jiang-v6ops-semantic-prefix-02.txt Feb 1 draft-elkins-v6ops-ipv6-ipid-needed-00.txt I'm expecting an update to draft-ietf-v6ops-enterprise-incremental-ipv6, af= ter which I believe it is ready for WGLC. This per my notes from the Atlant= a meeting. I will open a WGLC of draft-ietf-v6ops-nat64-experience Monday m= orning NZ time. Chinese New Year is 10 February, and is probably a distraction to some of o= ur participants much as the Christmas/Hanukkah season is a distraction in t= he west. =95 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) = submission by UTC 24:00, upload using IETF ID Submission Tool. =95 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC 24:= 00, upload using IETF ID Submission Tool. We may, therefore, have more "current" drafts on Feb 18 than we have now. The agenda for Orlando should be a subset of the "Current" drafts, specific= ally that subset which has had supporting commentary on the WG mailing list= . Drafts that don't see discussion from folks other than the authors don't = make that cut. That's our usual process.= From ales.vizdal@t-mobile.cz Fri Feb 1 13:47:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0A21F8CE2 for ; Fri, 1 Feb 2013 13:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsxFVN2c1a2X for ; Fri, 1 Feb 2013 13:47:13 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6D49021F8BD4 for ; Fri, 1 Feb 2013 13:47:12 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id CCB8C285822; Fri, 1 Feb 2013 22:47:10 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Fri, 1 Feb 2013 22:47:10 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Fri, 1 Feb 2013 22:47:09 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt Thread-Index: Ac3+UxrojE/H61nbT5Sk6yc/b1Oz4gCbldXA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA33D1C@SRVHKE02.rdm.cz> References: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> In-Reply-To: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.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: Fri, 01 Feb 2013 21:47:14 -0000 Hi, thanks for the update. Please find some comments below. 3.1 Scenario 1: No Global Address on the UE After the initial configuration using RS/RA the 3GPP network still may be=20 sending the RAs as the 3GPP TS 29.061, 11.2.1.3.4 says that=20 "MaxRtrAdvInterval shall have a default value of 21 600 s (6 h) and MinRtrAdvInterval shall have a default value of 0,75 =D7 MaxRtrAdvInterval= =20 i.e.16 200 s (4,5 h)."=20 So, it shall be mentioned that the SLAAC feature shall be disabled on the 3= GPP=20 interface to avoid this interface to be self auto configured with a GUA res= ulting in the same /64 bound to both 3GPP and LAN interfaces. 3.2 Scenario 2: Global Address Only Assigned to LAN In case of Privacy Extensions will be enabled on the 3GPP interface, shall = it be mentioned that each address from a given prefix shall be moved or is it obvious? 4. Security Considerations Since Scenario 3 does not allow for Privacy Extension to run the 3GPP inte= rface,=20 UEs that require this functionality must find an alternative method. Given that the Privacy Extensions will be disabled on the 3GPP interface, can we propose to use Privacy Extensions on LAN interface to fix the issue = above? Cheers, Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= internet- > drafts@ietf.org > Sent: Tuesday, January 29, 2013 8:01 PM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the IE= TF. >=20 > Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interf= ace to a > LAN > Author(s) : Cameron Byrne > Dan Drown > Filename : draft-ietf-v6ops-64share-01.txt > Pages : 8 > Date : 2013-01-29 >=20 > Abstract: > This document describes three methods for extending an IPv6 /64 > prefix from a User Equipment 3GPP radio interface to a LAN. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rbonica@juniper.net Fri Feb 1 14:42: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 1A50021E8049 for ; Fri, 1 Feb 2013 14:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz7lC4rjNIpW for ; Fri, 1 Feb 2013 14:42:58 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAC021E8041 for ; Fri, 1 Feb 2013 14:42:58 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUQxE8jQNozwuO663M69fdpxTy/77fr9n@postini.com; Fri, 01 Feb 2013 14:42:58 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 1 Feb 2013 14:41:56 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 1 Feb 2013 14:41:55 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 1 Feb 2013 14:44:05 -0800 Received: from mail115-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Feb 2013 22:41:55 +0000 Received: from mail115-tx2 (localhost [127.0.0.1]) by mail115-tx2-R.bigfish.com (Postfix) with ESMTP id C069D400272 for ; Fri, 1 Feb 2013 22:41:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail115-tx2 (localhost.localdomain [127.0.0.1]) by mail115-tx2 (MessageSwitch) id 1359758465105780_3027; Fri, 1 Feb 2013 22:41:05 +0000 (UTC) Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.246]) by mail115-tx2.bigfish.com (Postfix) with ESMTP id 13A6D34004D; Fri, 1 Feb 2013 22:41:05 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Feb 2013 22:41:04 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.250]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0263.000; Fri, 1 Feb 2013 22:40:54 +0000 From: Ronald Bonica To: t.petch , Brian E Carpenter , SM Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOAKJ8wwESq8A8JkqupkfdVf0Cb5hllBMA Date: Fri, 1 Feb 2013 22:40:53 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> In-Reply-To: <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.238.5$btconnect.com%0%1%juniper.net%False%False%0$ X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BTCONNECT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RESISTOR.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 22:42:59 -0000 Folks, It appears that we have a procedural problem. So, let's do the following: - I ask the chairs to initiate a one week WG last call. The last call will = be restricted to a discussion of whether this document should be published = considering its IPR. - If the WG concludes that the document should not be published, I will ask= the IESG to rescind its approval of the draft - If the draft reaches AUTH48 before the one week last call terminates, I w= ill delay publication until the last call has yielded a formal conclusion Now, for a little background regarding how we got to this point. As Joel po= ints out, the IPR was disclosed well before the WG Last Call. It was also m= entioned in the shepherd's write-up. When the document went to IESG review,= the IESG questioned whether the WG had considered the IPR. So, I posted th= e message at http://www.ietf.org/mail-archive/web/v6ops/current/msg14886.ht= ml. Discussion ensued, with some folks saying that the draft should be publishe= d and others saying that it should not. On Wednesday, I asked the chairs fo= r a consensus call. Their sense of the mailing list was that there was cons= ensus to publish. So, I cleared my DISCUSS and approved the document. Looking back on the process, it may have been a bit too informal. There was= never a formal last call, issued by the chairs. Nobody posted a message to= the list declaring consensus, one way or another. So we will repeat the la= st call, this time a little more formally. Ron From joelja@bogus.com Fri Feb 1 14:55: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 A349921F8E0F for ; Fri, 1 Feb 2013 14:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z94OiScJGepi for ; Fri, 1 Feb 2013 14:55:58 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA321F8E0E for ; Fri, 1 Feb 2013 14:55:58 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r11Mtn5d016387 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 1 Feb 2013 22:55:49 GMT (envelope-from joelja@bogus.com) Message-ID: <510C47F0.5040808@bogus.com> Date: Fri, 01 Feb 2013 14:55:44 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Ronald Bonica , "t.petch" , Brian E Carpenter , SM References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 01 Feb 2013 22:55:51 +0000 (UTC) Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 22:55:58 -0000 On 2/1/13 2:40 PM, Ronald Bonica wrote: > Folks, > > It appears that we have a procedural problem. So, let's do the following: > > - I ask the chairs to initiate a one week WG last call. The last call will be restricted to a discussion of whether this document should be published considering its IPR. Procedurally I am fine with requesting this. Given the desire not have the announcement of it to fall over a weekend for many I would suggest that we run it from monday to monday rather than running today. that would also provide time for commentary on the proposal for an another LC. > - If the WG concludes that the document should not be published, I will ask the IESG to rescind its approval of the draft > - If the draft reaches AUTH48 before the one week last call terminates, I will delay publication until the last call has yielded a formal conclusion > > Now, for a little background regarding how we got to this point. As Joel points out, the IPR was disclosed well before the WG Last Call. It was also mentioned in the shepherd's write-up. When the document went to IESG review, the IESG questioned whether the WG had considered the IPR. So, I posted the message at http://www.ietf.org/mail-archive/web/v6ops/current/msg14886.html. > > Discussion ensued, with some folks saying that the draft should be published and others saying that it should not. On Wednesday, I asked the chairs for a consensus call. Their sense of the mailing list was that there was consensus to publish. So, I cleared my DISCUSS and approved the document. > > Looking back on the process, it may have been a bit too informal. There was never a formal last call, issued by the chairs. Nobody posted a message to the list declaring consensus, one way or another. So we will repeat the last call, this time a little more formally. > > Ron > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Fri Feb 1 15:00: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 893C421E8041 for ; Fri, 1 Feb 2013 15:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.344 X-Spam-Level: X-Spam-Status: No, score=-109.344 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptwnydtlTm6d for ; Fri, 1 Feb 2013 15:00:16 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D5DE621E8049 for ; Fri, 1 Feb 2013 15:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=533; q=dns/txt; s=iport; t=1359759616; x=1360969216; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DSnf0SBIO1G7Xo9EBzuoR350y1/RSiupEgcTmv6ArIQ=; b=STitlkxb5gag7iyVXMLr0NONqfv6GPguDodS9bBJguBYZk6R1wInbkGB h3IsNJw6qEzp/iQMAieTB6QEQb/P61zpoNFw29loZqMfLR40/bCT3hC+u Oh+isCaVh31SZBiFZfQQ0KORkQMYbi8ydzcoHdDVnKXMGtiqMEdt4FlF2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAGhIDFGtJXG8/2dsb2JhbABABYYBuSwWc4IeAQEBAwE6PwULAgEIIhQFCyERJQIEDgUIh3cDCQa5HA2JVoJNiUyBG4M5YQOUQI0VhRKCfIIk X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171799893" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 01 Feb 2013 23:00:13 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r11N0BJx024425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 23:00:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 17:00:11 -0600 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOAM/jf1s7Ys1dTkqP0FL5vfVvEg== Date: Fri, 1 Feb 2013 23:00:10 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> In-Reply-To: <510B77E4.2060001@gmail.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: <2CD0D2E87E64AA4B9827B97FA8010E6A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 23:00:16 -0000 On Feb 1, 2013, at 12:08 AM, Brian E Carpenter wrote: > IMHO a WG Chair needs to make a formal call on the IPR question PDQ, > and if necessary, urgently request the IESG to rescind its approval. > I hope it isn't necessary, but it isn't my place to make the call. We actually thought we had asked on two occasions and not gotten much of a = response. However, consider this that request. We are interested in the wor= king group's opinion on the IPR claims by China Mobile on 464XLAT.= From Ted.Lemon@nominum.com Fri Feb 1 15:15: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 366911F0CFC for ; Fri, 1 Feb 2013 15:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zahoha-E-kjX for ; Fri, 1 Feb 2013 15:15:55 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id F2F3E1F0C4A for ; Fri, 1 Feb 2013 15:15:52 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUQxMo+w9ezMwTKg0+sYVXANjDzbjeGyM@postini.com; Fri, 01 Feb 2013 15:15:53 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 79C181B8497 for ; Fri, 1 Feb 2013 15:15:47 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 712D6190043 for ; Fri, 1 Feb 2013 15:15:47 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 15:15:41 -0800 From: Ted Lemon To: IPv6 Operations Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOADrKDU8u0Xat7E2HB1tWBU1s1ZhlLCsAgAD5QACAAARVAA== Date: Fri, 1 Feb 2013 23:15:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.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: <8062C015D3B79F44B8AFEFF26000A5FB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 23:15:56 -0000 On Feb 1, 2013, at 6:00 PM, Fred Baker (fred) wrote: > We actually thought we had asked on two occasions and not gotten much of = a response. However, consider this that request. We are interested in the w= orking group's opinion on the IPR claims by China Mobile on 464XLAT. The licensing declaration claims this option: Reasonable and Non-Discriminatory License to All Implementers with Possible= Royalty/Fee. This means that there is no guarantee that an open source implementation wo= uld not be subject to royalty, and no reason for commercial implementations= to assume that the royalty will not be more than they can afford. As I'v= e mentioned in previous messages, I think that a BCP with such an IPR restr= iction is undesirable. I currently oppose publishing the document as a BCP, but am willing to list= en to arguments to the contrary. I would support publishing the document = as informational. From jhw@apple.com Fri Feb 1 15:27: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 AD2D821F8CCB for ; Fri, 1 Feb 2013 15:27:19 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8a2LKUd6zaL for ; Fri, 1 Feb 2013 15:27:19 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 07E7321F8C93 for ; Fri, 1 Feb 2013 15:27:19 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) 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 <0MHK00B6WEGSCWC3@mail-out.apple.com> for v6ops@ietf.org; Fri, 01 Feb 2013 15:27:18 -0800 (PST) X-AuditID: 11807137-b7f156d000005a91-6f-510c4f56e641 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id D3.57.23185.65F4C015; Fri, 01 Feb 2013 15:27:18 -0800 (PST) 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 <0MHK00K6WEHIFQ20@aniseed.apple.com> for v6ops@ietf.org; Fri, 01 Feb 2013 15:27:18 -0800 (PST) From: james woodyatt In-reply-to: <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> Date: Fri, 01 Feb 2013 15:27:18 -0800 Message-id: <49DDDE6E-B9C4-4367-AB96-95A0435D7F7D@apple.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1668) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUi2FAsrhvmzxNo8O2vjsXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMXP7DdaC86wVH3uusTcw7mbpYuTkkBAwkWhse88KYYtJXLi3 nq2LkYtDSGAKk0T/+zMsEM4MJon7q24yglQxC2hJrN95nAnE5hXQk2h+cZ8VpEhYYD6jxPP1 c5hBEmwCKhLfLt8FK+IU8JPYMHUj2AoWAVWJnuPv2SAGqUpsunaaGcLWlnjy7gIrxFAbie/f lkGdcZpZom/PB3aQhAjQ0Cln7rNB3CorsfHwS6YJjAKzkBw1C8lRs5DMXcDIvIpRsCg1J7HS 0EwvsaAgJ1UvOT93EyM4AAvNdzBu/yt3iFGAg1GJh9fxJ3egEGtiWXFl7iFGCQ5mJRFe21qg EG9KYmVValF+fFFpTmrxIUZpDhYlcd5PjRyBQgLpiSWp2ampBalFMFkmDk6pBsZGDp9/Vs/O 9kqe8C3TT9OObFLX7XX77GO2JMb3jZIoa5J2J4uk1vfyVVbiVVMuJkbP8bm6Ibz1O+eF5KID qd8udCzcsU9nj6XbPCujVaxWRRPfWn6V5T3b9vnqj86zjf9k22tN3mXdXnvomGGD3LJ36pnC xw7zpjB/UXKYt0+4oqd96+XULCWW4oxEQy3mouJEAMSfnzI8AgAA Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 23:27:19 -0000 On Feb 1, 2013, at 15:15 , Ted Lemon wrote: > > This means that there is no guarantee that an open source implementation would not be subject to royalty, and no reason for commercial implementations to assume that the royalty will not be more than they can afford. As I've mentioned in previous messages, I think that a BCP with such an IPR restriction is undesirable. > > I currently oppose publishing the document as a BCP, but am willing to listen to arguments to the contrary. I would support publishing the document as informational. My position is the same as what Mr. Lemon declared above. -- james woodyatt core os networking From cb.list6@gmail.com Fri Feb 1 15:27: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 D7C5311E80A4 for ; Fri, 1 Feb 2013 15:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsvrC6XCkpxU for ; Fri, 1 Feb 2013 15:27:58 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id E37AF11E809C for ; Fri, 1 Feb 2013 15:27:57 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id gm6so5102814lbb.12 for ; Fri, 01 Feb 2013 15:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ApumYVeZ99LUEuZC+TACzBrUmR3jUnwqQnSFLOAtKMc=; b=m2xr19zoqFa5SV7mgnLeeP5TLsdRcqCfBtPF0LxS3xJdczBsNf2yQICePCyo+8ZYKA 9IqkKZj+2O90doI9s8Ns0c3PE0TzkuYaxYiC1elOboffaZ/oxholfTXTUCQoU106ZaSj fF2eApL4wpiD+exBdx/olQ7IjdE1mfzAgVWtkY2gjlyUiJD1BXmz8tOzuQOuyOB2sz34 ebTjr0dXR60oELUc0OwlhZ0E8cFscHKRDag7LktNB07fHPdLEaPjzp34ImPQrYBJatlP 2t2NpPkrFficqnMjgkyjDu4HXxg5UycBJYYCvlfCoTgibCeZxW0TFyws8vRcBS6dgqKI 9qIA== MIME-Version: 1.0 X-Received: by 10.112.46.199 with SMTP id x7mr5296763lbm.109.1359761276766; Fri, 01 Feb 2013 15:27:56 -0800 (PST) Received: by 10.112.7.165 with HTTP; Fri, 1 Feb 2013 15:27:56 -0800 (PST) Received: by 10.112.7.165 with HTTP; Fri, 1 Feb 2013 15:27:56 -0800 (PST) In-Reply-To: <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> Date: Fri, 1 Feb 2013 15:27:56 -0800 Message-ID: From: Cameron Byrne To: Fred Baker Content-Type: multipart/alternative; boundary=bcaec5540568e1899704d4b217ff Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 01 Feb 2013 23:27:59 -0000 --bcaec5540568e1899704d4b217ff Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Feb 1, 2013 3:00 PM, "Fred Baker (fred)" wrote: > > > On Feb 1, 2013, at 12:08 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > IMHO a WG Chair needs to make a formal call on the IPR question PDQ, > > and if necessary, urgently request the IESG to rescind its approval. > > I hope it isn't necessary, but it isn't my place to make the call. > > We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China Mobile on 464XLAT. > Since you ask about the claim, I appeal to the group's common sense. The draft plainly states this is just putting rfc 6145 and 6146 in series. Both of those rfcs have roots in work from nat-pt in 2000. It would be very unfortunate if we have to cower at an ipr claim that asserts our own standards against us (the ietf) CB Ps. I am not a lawyer. And, you alread told me the ietf is not a court...thx! _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --bcaec5540568e1899704d4b217ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Feb 1, 2013 3:00 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
>
>
> On Feb 1, 2013, at 12:08 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> > IMHO a WG Chair needs to make a formal call on the IPR question P= DQ,
> > and if necessary, urgently request the IESG to rescind its approv= al.
> > I hope it isn't necessary, but it isn't my place to make = the call.
>
> We actually thought we had asked on two occasions and not gotten much = of a response. However, consider this that request. We are interested in th= e working group's opinion on the IPR claims by China Mobile on 464XLAT.=
>

Since you ask about the claim, I appeal to the group's c= ommon sense. The draft plainly states this is just putting rfc 6145 and 614= 6 in series.=A0 Both of those rfcs have roots in work from nat-pt in 2000.<= /p>

It would be very unfortunate if we have to cower at an ipr c= laim that asserts our own standards against us (the ietf)

CB

Ps. I am not a lawyer. And, you alread told me the ietf is n= ot a court...thx! _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--bcaec5540568e1899704d4b217ff-- From joelja@bogus.com Fri Feb 1 16:23: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 65C6E21E8041 for ; Fri, 1 Feb 2013 16:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIIeKWYDDieQ for ; Fri, 1 Feb 2013 16:23:48 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D7E731F0C4A for ; Fri, 1 Feb 2013 16:23:48 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r120NlsC017414 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 2 Feb 2013 00:23:48 GMT (envelope-from joelja@bogus.com) Message-ID: <510C5C8E.4030203@bogus.com> Date: Fri, 01 Feb 2013 16:23:42 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Pete Vickers , "v6ops@ietf.org" References: <7CC3086C-67FB-4E0D-9DB5-864D7EE23498@gmail.com> <67D53A24-64FF-4E57-9E32-958F1F91BC00@systemnet.no> In-Reply-To: <67D53A24-64FF-4E57-9E32-958F1F91BC00@systemnet.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 02 Feb 2013 00:23:48 +0000 (UTC) Subject: Re: [v6ops] Fwd: v6ops Digest, Vol 30, Issue 1 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Feb 2013 00:23:49 -0000 On 2/1/13 3:21 AM, Pete Vickers wrote: >> ------------------------------ >> >> Message: 5 >> Date: Fri, 1 Feb 2013 19:43:04 +0900 >> From: Lorenzo Colitti >> To: Warren Kumari >> Cc: IPv6 Ops WG >> Subject: Re: [v6ops] Test for adoption as a working group document - >> Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt >> Message-ID: >> >> Content-Type: text/plain; charset="windows-1252" >> >> On Fri, Feb 1, 2013 at 6:31 AM, Warren Kumari wrote: >> >>> When I wrote that I though that this should be done somewhere else, I >>> didn't actually stop and figure out *where* else? >>> >> The way I see it, it doesn't matter where else. The IETF has no authority >> to mandate what vendors do and do not implement, only how they implement >> it. And since the IETF has no authority over this, it follows that the >> document will have a similar level of effect whether it's published as an >> IETF RFC or as a text file in my home directory: in both cases, >> approximately none. > I don't see why authority is necessary to provide a document that will be useful to many purposes. e.g.: > > - companies could point to it to pressure vendors to adhere. à la DoD and IPv6. > - Autoritive bodies (e.g. 3GPP etc) can take it as input to drastically reduce the timescales to ratify their own standards. > - analysis, debugging and development environments could use it as an aide-mémoire to ensure that relevant ground is covered in a consistent way. > > >> If a collection of operators got together and drew up a certification >> profile accompanied by a conformance test, and agreed to hold vendors to >> it, then that would be more useful. But the IETF is not the place to do >> that. The ops area has in it's wisdom in the past chartered an entire working group just for the purpose of enumerating the filtering capabilities that operators require from equipment. We also have the existence proof of 6204/6204bis. So I think simply stating that a document like this is not in our wheelhouse is not by itself a very strong argument. The argument that it should be done elsewhere could perhaps be more persuasive. joel > Indeed, and they could refer to a relevant RFC in that process. > > /Pete > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Fri Feb 1 16:48:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB15921E805A for ; Fri, 1 Feb 2013 16:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.171 X-Spam-Level: X-Spam-Status: No, score=-110.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clKXMNajny22 for ; Fri, 1 Feb 2013 16:48:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 106921F0CF8 for ; Fri, 1 Feb 2013 16:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3804; q=dns/txt; s=iport; t=1359766083; x=1360975683; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JdRH42rxVot/W63WgWWG7HgtbEdGAxuG4yU2azV2me8=; b=jBPeft/aX5zR5Hkvz0hlGUTplLAvuTVKJqIR022xwBRFX0pyUPkvGIfA BJclEhUqC1Ov5NqG2AQi5RSPzc3QWFQwwQ/8m44pyrrpkln45X6inQW8E u4ST9AC+6+DZeka8bL6bBIFNsLg0e2EZTidQp/FZBu7kmNYIXL0oMBDaG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADhhDFGtJXHB/2dsb2JhbABFvzIWc4IfAQEEeRACAQgEChQZBAchERQRAgQOBQiHdwMPuQUNiVaCTYlMhFRhA4gwjBCNFYUSgnyCJA X-IronPort-AV: E=Sophos;i="4.84,588,1355097600"; d="scan'208,217";a="172051010" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 02 Feb 2013 00:48:02 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r120m2LZ028619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Feb 2013 00:48:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 18:48:02 -0600 From: "Fred Baker (fred)" To: Cameron Byrne Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOAN701ulnf0rnDkyBOM6G8OcWjA== Date: Sat, 2 Feb 2013 00:48:02 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@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.121] Content-Type: multipart/alternative; boundary="_000_8C48B86A895913448548E6D15DA7553B7661B2xmbrcdx09ciscocom_" MIME-Version: 1.0 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sat, 02 Feb 2013 00:48:04 -0000 --_000_8C48B86A895913448548E6D15DA7553B7661B2xmbrcdx09ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Feb 1, 2013, at 3:27 PM, Cameron Byrne > wrote: Since you ask about the claim, I appeal to the group's common sense. The dr= aft plainly states this is just putting rfc 6145 and 6146 in series. Both = of those rfcs have roots in work from nat-pt in 2000. It would be very unfortunate if we have to cower at an ipr claim that asser= ts our own standards against us (the ietf) This is of course why we have asked China Mobile for the substance of the c= laim. If that is literally their claim, I wish them luck when it comes to e= nforcing it. But *that* question is not ours. The question for us is whethe= r, in the presence of the claim of IPR, we want to publish the draft at all= , and if so, with what status. There is a part of me that would be very happy for the working group to dec= ide it didn't want to publish the draft at all, and to state that the reaso= n is an IPR declaration that looks essentially vacuous and has been neither= explained nor substantiated by China Mobile. But that's just me. --_000_8C48B86A895913448548E6D15DA7553B7661B2xmbrcdx09ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7F92E73D25E76D478936BF3DCDF82223@cisco.com> Content-Transfer-Encoding: quoted-printable
On Feb 1, 2013, at 3:27 PM, Cameron Byrne <cb.list6@gmail.com> wrote:

Since you ask about the claim, I appeal to the group's common sense. The dr= aft plainly states this is just putting rfc 6145 and 6146 in series.  = Both of those rfcs have roots in work from nat-pt in 2000.

It would be very unfortunate if we have to cower at an ipr claim that asser= ts our own standards against us (the ietf)

This is of course why we have asked China Mobile for the substance of the c= laim. If that is literally their claim, I wish them luck when it comes to e= nforcing it. But *that* question is not ours. The question for us is whethe= r, in the presence of the claim of IPR, we want to publish the draft at all, and if so, with what status.

There is a part of me that would be very happy for the working group t= o decide it didn't want to publish the draft at all, and to state that the = reason is an IPR declaration that looks essentially vacuous and has been ne= ither explained nor substantiated by China Mobile. But that's just me.
--_000_8C48B86A895913448548E6D15DA7553B7661B2xmbrcdx09ciscocom_-- From randy@psg.com Fri Feb 1 19:40: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 7D1C521F8DD3 for ; Fri, 1 Feb 2013 19:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4jSZCa0j8JK for ; Fri, 1 Feb 2013 19:40:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1258721F8DD2 for ; Fri, 1 Feb 2013 19:40:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U1Txu-000LTe-Jg; Sat, 02 Feb 2013 03:40:30 +0000 Date: Sat, 02 Feb 2013 12:40:29 +0900 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.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 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sat, 02 Feb 2013 03:40:35 -0000 > The licensing declaration claims this option: > > Reasonable and Non-Discriminatory License to All Implementers with > Possible Royalty/Fee. > > This means that there is no guarantee that an open source > implementation would not be subject to royalty, and no reason for > commercial implementations to assume that the royalty will not be more > than they can afford. As I've mentioned in previous messages, I think > that a BCP with such an IPR restriction is undesirable. > I currently oppose publishing the document as a BCP, but am willing to > listen to arguments to the contrary. I would support publishing the > document as informational. with a change to "china mobile's blah blah" randy From owen@delong.com Fri Feb 1 20:09: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 0FB6421F8B63 for ; Fri, 1 Feb 2013 20:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p51TLpkwXLhm for ; Fri, 1 Feb 2013 20:09:18 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2A21F8B62 for ; Fri, 1 Feb 2013 20:09:17 -0800 (PST) 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 r1247wtS026428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Feb 2013 20:07:58 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1247wtS026428 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1359778078; bh=24NmHGBePa4OB17spdGOqu23hfk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QqfVV1x09utAPe4zXpeb65vv8nwKHPcD73zukhLOkB1XzdWFVcYbg9AyR54HUHAg7 B97DgYP0Nuqvdw9bHoeMiVeBj84Jqtp6x84xCKBHspMUrtGVuPTgMNBA7Lb0DFaceY pG3xsiPalN6Us6WsbjgRteiZbUGoq2meddkL/q9w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> Date: Fri, 1 Feb 2013 20:07:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 01 Feb 2013 20:07:58 -0800 (PST) Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sat, 02 Feb 2013 04:09:19 -0000 On Feb 1, 2013, at 15:15 , Ted Lemon wrote: > On Feb 1, 2013, at 6:00 PM, Fred Baker (fred) wrote: >> We actually thought we had asked on two occasions and not gotten much = of a response. However, consider this that request. We are interested in = the working group's opinion on the IPR claims by China Mobile on = 464XLAT. >=20 > The licensing declaration claims this option: >=20 > Reasonable and Non-Discriminatory License to All Implementers with = Possible Royalty/Fee. >=20 > This means that there is no guarantee that an open source = implementation would not be subject to royalty, and no reason for = commercial implementations to assume that the royalty will not be more = than they can afford. As I've mentioned in previous messages, I think = that a BCP with such an IPR restriction is undesirable. >=20 > I currently oppose publishing the document as a BCP, but am willing to = listen to arguments to the contrary. I would support publishing the = document as informational. >=20 I support this position as well. If it is to become BCP, it should be available to open source without = royalty. Owen From cb.list6@gmail.com Fri Feb 1 20:13: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 CC21021E80A0 for ; Fri, 1 Feb 2013 20:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUw3ytIwMp4a for ; Fri, 1 Feb 2013 20:13:03 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1821E809B for ; Fri, 1 Feb 2013 20:13:03 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so5233364lbo.38 for ; Fri, 01 Feb 2013 20:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nHWEuh+65pQjUWXDxIYYLrt+Tgjkrsr9qqEi4/wuJsc=; b=zz80fN07IlQmXLZpE0qhwbq138HPTjTrQZJeh4GjN8aOaFYR6umDGAUS6kA9/tiaEw boFRdEFQNGSV7FR9QohBy2xRu6LCN7i+31vmH0DeFXaXY9UqiH5rbpp7o0jJdA2AFYGY yOeEPTrwJG/O/JdA+RviiYic+MSRNSTRqwt4/ZE7t3VOHp+HdiKcV9x1ThSt4n596OQQ 1yKnUQPe8jM99UF1MIa0wqO0n6zUSuMfry/imAAmSi5DmPlFs97xhqi7U9KYUMK2cvDn qogec5dlRcEI0eC0K4+l7z4T65y92+xtJ+xmJNPPTiRlAy1azd+siN8UAnrAmKEmddND 6YxQ== MIME-Version: 1.0 X-Received: by 10.152.108.203 with SMTP id hm11mr13072043lab.4.1359778382093; Fri, 01 Feb 2013 20:13:02 -0800 (PST) Received: by 10.112.7.165 with HTTP; Fri, 1 Feb 2013 20:13:01 -0800 (PST) Received: by 10.112.7.165 with HTTP; Fri, 1 Feb 2013 20:13:01 -0800 (PST) In-Reply-To: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> Date: Fri, 1 Feb 2013 20:13:01 -0800 Message-ID: From: Cameron Byrne To: Owen DeLong Content-Type: multipart/alternative; boundary=bcaec54eedd6701dc504d4b61396 Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sat, 02 Feb 2013 04:13:04 -0000 --bcaec54eedd6701dc504d4b61396 Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Feb 1, 2013 8:09 PM, "Owen DeLong" wrote: > > > On Feb 1, 2013, at 15:15 , Ted Lemon wrote: > > > On Feb 1, 2013, at 6:00 PM, Fred Baker (fred) wrote: > >> We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China Mobile on 464XLAT. > > > > The licensing declaration claims this option: > > > > Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee. > > > > This means that there is no guarantee that an open source implementation would not be subject to royalty, and no reason for commercial implementations to assume that the royalty will not be more than they can afford. As I've mentioned in previous messages, I think that a BCP with such an IPR restriction is undesirable. > > > > I currently oppose publishing the document as a BCP, but am willing to listen to arguments to the contrary. I would support publishing the document as informational. > > > > I support this position as well. > > If it is to become BCP, it should be available to open source without royalty. > > Owen > Once again, I am not a lawyer. But it is open source and royalty free everywhere except China where the patent was issued. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --bcaec54eedd6701dc504d4b61396 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Feb 1, 2013 8:09 PM, "Owen DeLong" <owen@delong.com> wrote:
>
>
> On Feb 1, 2013, at 15:15 , Ted Lemon <Ted.Lemon@nominum.com> wrote:
>
> > On Feb 1, 2013, at 6:00 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> >> We actually thought we had asked on two occasions and not got= ten much of a response. However, consider this that request. We are interes= ted in the working group's opinion on the IPR claims by China Mobile on= 464XLAT.
> >
> > The licensing declaration claims this option:
> >
> > Reasonable and Non-Discriminatory License to All Implementers wit= h Possible Royalty/Fee.
> >
> > This means that there is no guarantee that an open source impleme= ntation would not be subject to royalty, and no reason for commercial imple= mentations to assume that the royalty will not be more than they can afford= . =A0 As I've mentioned in previous messages, I think that a BCP with s= uch an IPR restriction is undesirable.
> >
> > I currently oppose publishing the document as a BCP, but am willi= ng to listen to arguments to the contrary. =A0 I would support publishing t= he document as informational.
> >
>
> I support this position as well.
>
> If it is to become BCP, it should be available to open source without = royalty.
>
> Owen
>

Once again,=A0 I am not a lawyer. But it is open source and = royalty free everywhere except China where the patent was issued.

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

--bcaec54eedd6701dc504d4b61396-- From v6ops@globis.net Fri Feb 1 20:47: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 72D561F0D00 for ; Fri, 1 Feb 2013 20:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcBBEyfnw3NO for ; Fri, 1 Feb 2013 20:47:42 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 776CC1F0CF8 for ; Fri, 1 Feb 2013 20:47:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 54BE68700BC; Sat, 2 Feb 2013 05:42:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 BeEYEz4o3M2g; Sat, 2 Feb 2013 05:41:56 +0100 (CET) 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 9ED5B870081; Sat, 2 Feb 2013 05:41:56 +0100 (CET) Message-ID: <510C990E.8070505@globis.net> Date: Sat, 02 Feb 2013 05:41:50 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sat, 02 Feb 2013 04:47:43 -0000 Fred Baker (fred) wrote: > On Feb 1, 2013, at 12:08 AM, Brian E Carpenter wrote: > >> IMHO a WG Chair needs to make a formal call on the IPR question PDQ, >> and if necessary, urgently request the IESG to rescind its approval. >> I hope it isn't necessary, but it isn't my place to make the call. > > We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China Mobile on 464XLAT. Speaking as an individual, and as someone whose name appears in the "with thanks" section of this document, I'm uncomfortable with the thought that anyone would be swayed or otherwise persuaded to pay an as yet to be defined commercial licence fee for this technology, due to an IETF document that I've contributed to pro bono. I'm therefore not comfortable with the intended BCP status combined with the current IPR statement. Little guys can't afford IPR lawyers. No matter how much merit the IPR claim has (or not). From randy@psg.com Fri Feb 1 22:55: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 E229321F9112 for ; Fri, 1 Feb 2013 22:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M320Vbho9B0J for ; Fri, 1 Feb 2013 22:55:12 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6621F9111 for ; Fri, 1 Feb 2013 22:55:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U1X0F-000LrG-W1; Sat, 02 Feb 2013 06:55:08 +0000 Date: Sat, 02 Feb 2013 15:55:07 +0900 Message-ID: From: Randy Bush To: Zhenkai Wang In-Reply-To: References: 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: v6ops@ietf.org Subject: Re: [v6ops] China Mobile's Statement about IPR related to draft-ietf-v6ops-464xlat-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, 02 Feb 2013 06:55:13 -0000 > As a company, China Mobile has spent lots of efforts like expenditure of > man workforce, time, et al. on some technologies. luckily, all the rest of us do this as recreation and make no effort randy From brian.e.carpenter@gmail.com Sat Feb 2 00:11: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 329A721F9111 for ; Sat, 2 Feb 2013 00:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.611 X-Spam-Level: X-Spam-Status: No, score=-96.611 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDIzWQMP3f3G for ; Sat, 2 Feb 2013 00:11:43 -0800 (PST) Received: from mail-wi0-x22a.google.com (wi-in-x022a.1e100.net [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 378BA21F9106 for ; Sat, 2 Feb 2013 00:11:43 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so2605059wib.5 for ; Sat, 02 Feb 2013 00:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hCjohnIDLf38Ts+HVaDg1wXu2TpBEWHRu66v2wcwULw=; b=DNYqOPn6oP+mv0+pjJ/4npYhhSgWwFB4ZrV3yMQMdMU9lY7QZhLLvtixJvs/BD0vLR o9sNc3Cy4upxbvRHe/naiHd2ZnbpnDvwTzTuHox+wO25976MPMHqdxE3+RkjIHCzwPlB 67ImAc/Rfu9z6njx86QMJiIlyjGZWUAS53RDgcEmtRqeOXKboN2JiMTwP8cVa5JzoqEt m/aTrYyo/fGqDlr9sjpHkjblxtGdF/n560jwLH3GEGBXtEaO7n/5WFgbNf08c0opQ84y YFcjXs8qhvFxwLqh7VTlgx2atWCPaLN3tVUzBvOtCwm3/nBvICfgc7aV3GEqBbDZqE7z xx7A== X-Received: by 10.194.89.167 with SMTP id bp7mr25862526wjb.0.1359792702071; Sat, 02 Feb 2013 00:11:42 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-3.as13285.net. [2.101.188.3]) by mx.google.com with ESMTPS id j9sm1058489wia.5.2013.02.02.00.11.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Feb 2013 00:11:41 -0800 (PST) Message-ID: <510CCA4D.7010508@gmail.com> Date: Sat, 02 Feb 2013 08:11:57 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sat, 02 Feb 2013 08:11:44 -0000 On 01/02/2013 22:40, Ronald Bonica wrote: > Folks, > > It appears that we have a procedural problem. So, let's do the following: > > - I ask the chairs to initiate a one week WG last call. The last call will be restricted to a discussion of whether this document should be published considering its IPR. > - If the WG concludes that the document should not be published, I will ask the IESG to rescind its approval of the draft > - If the draft reaches AUTH48 before the one week last call terminates, I will delay publication until the last call has yielded a formal conclusion > > Now, for a little background regarding how we got to this point. As Joel points out, the IPR was disclosed well before the WG Last Call. It was also mentioned in the shepherd's write-up. When the document went to IESG review, the IESG questioned whether the WG had considered the IPR. So, I posted the message at http://www.ietf.org/mail-archive/web/v6ops/current/msg14886.html. > > Discussion ensued, with some folks saying that the draft should be published and others saying that it should not. On Wednesday, I asked the chairs for a consensus call. Their sense of the mailing list was that there was consensus to publish. So, I cleared my DISCUSS and approved the document. afaik that consensus call was not copied to the list. That was perhaps unfortunate. On 01/02/2013 23:00, Fred Baker (fred) wrote: > On Feb 1, 2013, at 12:08 AM, Brian E Carpenter wrote: > >> > IMHO a WG Chair needs to make a formal call on the IPR question PDQ, >> > and if necessary, urgently request the IESG to rescind its approval. >> > I hope it isn't necessary, but it isn't my place to make the call. > > We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China Mobile on 464XLAT. My opinion is that the IPR claim is no more worrisome than many others the IETF has chosen to live with, so the document should proceed as a BCP. The claim is on record for any implementor to consider, regardless of the status of the document. Brian From Ted.Lemon@nominum.com Sat Feb 2 05:11: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 A85D221F9095 for ; Sat, 2 Feb 2013 05:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy6JucjN3ja3 for ; Sat, 2 Feb 2013 05:11:28 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4D821F9096 for ; Sat, 2 Feb 2013 05:11:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ0Qf2Z61GewW/abJUkkgEkHgBXuSGzk@postini.com; Sat, 02 Feb 2013 05:11:28 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7642C10807B for ; Sat, 2 Feb 2013 05:11:27 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6DBA9190043; Sat, 2 Feb 2013 05:11:27 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sat, 2 Feb 2013 05:11:27 -0800 From: Ted Lemon To: Randy Bush Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOADrKDU8u0Xat7E2HB1tWBU1s1ZhlLCsAgAD5QACAAARVAIAASf2AgACfhgA= Date: Sat, 2 Feb 2013 13:11:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747A650@mbx-01.win.nominum.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63074747A03A@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sat, 02 Feb 2013 13:11:28 -0000 On Feb 1, 2013, at 10:40 PM, Randy Bush wrote: > with a change to "china mobile's blah blah" Good point. From fred@cisco.com Sat Feb 2 05:45:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0461B21F880F for ; Sat, 2 Feb 2013 05:45:08 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgoWZkJCLL6i for ; Sat, 2 Feb 2013 05:45:07 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2F81021F8740 for ; Sat, 2 Feb 2013 05:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=137; q=dns/txt; s=iport; t=1359812707; x=1361022307; h=date:from:message-id:to:subject:cc; bh=SUg7XyIgTgZi5teOA9cHZphqnqAKF/85n7047gKZDjE=; b=Y0GlFQSK2NCngC5eW3yMeFSKGaxOQ+FpmqQ2mPa8fphT9cYpZIrop3cV QCXIssIylgK8nhRxprSJ11PnyXm5eckzngsrmsHMJj2BgMscoeDir3yIK NqIZDZyYE5G/VdweXnxxoZV4jOcGen1KfhmjFObGnsoNGanz0p1lKTLTl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQKAIEXDVGrRDoH/2dsb2JhbABFhgGmfAGRLwQDgQQWc4MfPC0HiHENwi+OKYMpA4hmjlaPNIMd X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; d="scan'208";a="70249886" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 02 Feb 2013 13: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 r12Dj1A4005117; Sat, 2 Feb 2013 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r12Dj1k02256; Sat, 2 Feb 2013 05:45:01 -0800 (PST) Date: Sat, 2 Feb 2013 05:45:01 -0800 (PST) From: Message-Id: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-elkins-v6ops-ipv6-ipid-needed@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 13:45:11 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-ipid-needed. Please take a look at it and comment. From randy@psg.com Sat Feb 2 08:21: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 3251521F8556 for ; Sat, 2 Feb 2013 08:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hahO7E8Pr9VR for ; Sat, 2 Feb 2013 08:21:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D8B7E21F851C for ; Sat, 2 Feb 2013 08:21:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U1fqW-000N0H-Cq; Sat, 02 Feb 2013 16:21:40 +0000 Date: Sun, 03 Feb 2013 01:21:39 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 16:21:42 -0000 a strange document, a plea for ipid in v6. i kinda like[d] ipid and we did some reasearch measurements on it. actually, i think we are still collecting and have some years of longitudinal data. but i would think that this document would be in 6man, where putting ipid in the v6 header does not have a snowball's chance in hell. randy From mackermann@bcbsm.com Sat Feb 2 08:37: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 0223221F8632 for ; Sat, 2 Feb 2013 08:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piT+70fqEcbk for ; Sat, 2 Feb 2013 08:37:39 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8F921F84F0 for ; Sat, 2 Feb 2013 08:37:38 -0800 (PST) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id AB597136E66 for ; Sat, 2 Feb 2013 10:37:37 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 690D7136E4B; Sat, 2 Feb 2013 10:37:36 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 292574F8051; Sat, 2 Feb 2013 11:36:21 -0500 (EST) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id 1B6A34F8049; Sat, 2 Feb 2013 11:36:21 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Sat, 2 Feb 2013 11:37:35 -0500 From: "Ackermann, Michael" To: Randy Bush , Fred Baker Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCA= Date: Sat, 2 Feb 2013 16:37:34 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 16:37:41 -0000 Thanks for the comments Randy. We would be interested in your = measurements and any other related info/thoughts/insights you may have=21 We are new to IETF and if we should be working with other or additional = Working Groups, we are certainly open to that. =20 I am curious why you feel 6man would not be open to this? =20 Thanks again=21 Mike -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Randy Bush Sent: Saturday, February 02, 2013 11:22 AM To: Fred Baker Cc: IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed a strange document, a plea for ipid in v6. i kinda like=5Bd=5D ipid and = we did some reasearch measurements on it. actually, i think we are still = collecting and have some years of longitudinal data. but i would think that this document would be in 6man, where putting ipid = in the v6 header does not have a snowball's chance in hell. randy _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From cb.list6@gmail.com Sat Feb 2 10:16: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 330BA21F844F for ; Sat, 2 Feb 2013 10:16:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6xpsZtaI-UE for ; Sat, 2 Feb 2013 10:16:29 -0800 (PST) Received: from mail-la0-x231.google.com (la-in-x0231.1e100.net [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDD521F8447 for ; Sat, 2 Feb 2013 10:16:29 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fs13so3604259lab.36 for ; Sat, 02 Feb 2013 10:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g1vOvglHm+bfvxTx4mU2sqS/2eeNBd4wwaa2M0OvGyo=; b=f1g2r24E2tS8CvuotMH1hLszCkSzUe5+mQen/gcE3Prmpe/sC2rXlqBsM9e+ewD19W /eeA3RM4dwx7sqpkI2wJnZZnD7Bopx9uPCu0MW+a8uOF9Mnbm0OhbkTsEVQQS0PArVPG 5fjayxbdDPe48GyBU0016uY4PioYpeSAhtJJ+lduxOWPaXi81eRR3nvF4X1giEk3TVYZ 4H02AFIp0NUAt+ZLFDIZJnyiDECQnzWL8a0dllAwFoAg1U7bTUs4ah4fXFITG9s6a4up nfmBfAaZ/SLr4rCU3gb7vBxdlUYlJqqYI1AlUvKfxBVTgNBbkIZcDVrnsR87p2DglgZG B1jA== MIME-Version: 1.0 X-Received: by 10.112.51.44 with SMTP id h12mr6073594lbo.111.1359828988439; Sat, 02 Feb 2013 10:16:28 -0800 (PST) Received: by 10.112.7.165 with HTTP; Sat, 2 Feb 2013 10:16:28 -0800 (PST) In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> Date: Sat, 2 Feb 2013 18:16:28 +0000 Message-ID: From: Cameron Byrne To: "Eric Vyncke (evyncke)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" , "draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Feb 2013 18:16:30 -0000 I support the WG adoption of this I-D. I believe it would be helpful to call out that the drop rules can be statelessly implemented in the provider network while the ratelimiting function is stateful and is a better fit for the CPE. I would also suggest the the term residential be changed to include mobile. Perhaps "consumer grade" internet service or something like that. CB From fred@cisco.com Sat Feb 2 11:23:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF421F84F4 for ; Sat, 2 Feb 2013 11:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.935 X-Spam-Level: X-Spam-Status: No, score=-109.935 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smBi5EZB9YXX for ; Sat, 2 Feb 2013 11:23:11 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B206721F84E6 for ; Sat, 2 Feb 2013 11:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4486; q=dns/txt; s=iport; t=1359832991; x=1361042591; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qDb6nGyu4aLsJRyhJFsXOHL/JbZ40TMccpoD+Olvphc=; b=UvX4yIhFu3TGfckH8x6Pdi4Cisia+2sDm4APQrqAJmpHnMdVlNpn1K/3 616uOY9uY66B2OSl97m1cDrIn6D9fv1NH7F0Lrf5sbXCNKG8HK4Ck24qj 6ccEnrFtrIvumO46TnEfmXHfeBY6wgkuaGQ5Vie+4Hlzvwft0HdFa9csd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKVmDVGtJV2d/2dsb2JhbABFvzYWc4IfAQEBAwEBAQFrCwUJAgIBCCIkFgsGCyUCBA4FCId3AwkGDLdeDYlWBIwZgQ2DR2EDlEeCdYoihRKCfIFvNQ X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; d="scan'208";a="172317469" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 02 Feb 2013 19:23:11 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r12JNBVD012525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Feb 2013 19:23:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Sat, 2 Feb 2013 13:23:10 -0600 From: "Fred Baker (fred)" To: Zhenkai Wang Thread-Topic: [v6ops] China Mobile's Statement about IPR related to draft-ietf-v6ops-464xlat-00 Thread-Index: AQHOAXq8vfl2+qCwhECjs+RQsJsWbw== Date: Sat, 2 Feb 2013 19:23:10 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B767174@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="Windows-1252" Content-ID: <33A36BF4C7F7FA43A7CEEC68003005FA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] China Mobile's Statement about IPR related to draft-ietf-v6ops-464xlat-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, 02 Feb 2013 19:23:17 -0000 Mr Wang: I speak here as one of the chairs of v6ops. This is a formal question from = the IETF to China Mobile, and the answer may affect how the IETF treats the= posted internet draft.. The question before the house is not whether China Mobile puts effort into = what it does; we assume that China Mobile does, just as we all do. The ques= tion regards the substance of the IPR claim - what claims have been allowed= or filed for in the patent - and whether the claims apply to the current v= ersion of the draft. The statements of IPR were on the -00 and -01 versions= of the draft, which changed materially before reaching its current status. The draft proposes no new technology; if that were not true, this working g= roup could not, by charter, consider it. It depends on several other techno= logies, notably https://tools.ietf.org/html/rfc6052 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=3D41849 bytes= ) (Updates RFC4291) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6144 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April 2011. (Format: TXT=3D67181 bytes) (Status: INFORMATIONAL) https://tools.ietf.org/html/rfc6145 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April 2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC2765) (Updated by RFC6791) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6146 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=3D107954 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6147 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Status: PROPOSED STANDARD) plus several that are listed as "informative" in reading the document. (I n= ote that 6144 was overlooked in the bibliography of draft-ietf-v6ops-464xla= t). Hence, this draft is not about technology per se, it is about the use o= f existing technology in a 3GPP network. Is China Mobile's patent about the= use of the technologies in a 3GPP network, or is it on the technologies th= emselves? What is the substance of the IPR claim? Does it apply to http://t= ools.ietf.org/html/draft-ietf-v6ops-464xlat-09? Fred Baker co-chair, IETF IPv6 Operations Working Group On Jan 29, 2013, at 7:08 PM, Zhenkai Wang wrote: > Hello IETF, > =20 > As a company, China Mobile has spent lots of efforts like expenditure of = man workforce, time, et al. on some technologies. We underline that Intelle= ctual property Rights (IPRs) are an important part of technologies, and als= o respect IPRs like other companies in the industry. > =20 > The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is a co= mpliance with the rules of the IETF which are defined in RFC 3979, "Intelle= ctual Property Rights in IETF Technology." The licensing declaration for th= is Document =91c) Reasonable and Non-Discriminatory License to All Implemen= ters with Possible Royalty/Fee=92 made by China Mobile was in accordance wi= th our corporate strategy, as well as industry practice. > =20 > Best regards, > =20 > Wang Zhengkai > =20 > Wang Zhenkai > IP Counsel | China Mobile Research Institute > Office: +86 15801696688-35235 | Mobile: +8613810187794 | > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. > =20 > Confidentiality Notice: The information contained in this e-mail and any = accompanying attachment(s) is intended only for the use of the intended rec= ipient and may be confidential and/or privileged of China Mobile, its subsi= diaries and/or its affiliates. If any reader of this communication is not t= he intended recipient, unauthorized use, forwarding, printing, storing, dis= closure or copying is strictly prohibited, and may be unlawful. If you have= received this communication in error, please immediately notify the sender= by return e-mail, and delete the original message and all copies from your= system. Thank you. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Sat Feb 2 14:03: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 8B63421F84A1 for ; Sat, 2 Feb 2013 14:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROCb645UU1qq for ; Sat, 2 Feb 2013 14:03:44 -0800 (PST) Received: from nm28-vm0.bullet.mail.bf1.yahoo.com (nm28-vm0.bullet.mail.bf1.yahoo.com [98.139.213.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC2621F8470 for ; Sat, 2 Feb 2013 14:03:44 -0800 (PST) Received: from [98.139.212.146] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 02 Feb 2013 22:03:44 -0000 Received: from [98.139.212.192] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 02 Feb 2013 22:03:44 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 02 Feb 2013 22:03:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 5465.26659.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 16675 invoked by uid 60001); 2 Feb 2013 22:03:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359842623; bh=ttFaxz68hfjXQkbAXLSrOf/m/ZyhPScuaQ35+iW1+Oo=; 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=jlVZwYQOUf19v/2IXPifc/vMOjWOMIt9CAybbTBO653POGsUES958chlrmMVC2yAI0pQvY8mW+JhFKtQyAvz82wy9RkWW21oPjfkvoM0ZX0svF60Hvtba/CPBuiNjSn40A4zNTNacv9JvgR4wcCASMo0GCJy9jqmDX9lXd20qFA= 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=wBMHgGMWbtGGh20Bm+yoFsTysYYe94Gy7bdcY+wJ3o1QnhN4jD0vRjqVfStY4kg/CsJJBP92/sze36vyRx+oUXmdKWFSUUs7aGt0dB4ewF9UHnYot1CiE3WTZx6JC0MO1ukY1rDsvV6++ZERxeC4vHXr+F4EO957wivu1rgPtCI=; X-YMail-OSG: tXrhvtsVM1nmWFN6io9NIKw6vc2WJ1OxfwnWJKMBG2hL2tg sdP22VBNzQ.G.xCvpZ3jT9F3WSIdvGPCMfwJgEhdOT68pdzCSVTAEzFzjIVZ Ce.7XSsXk3Ei.XEX98sjFIUAW8.9ayUZnfTuzDEse30hdf3_OQFl6kn08.DN zw9HPJW4N6X0WSdo8qZxW8x_pGesTcSQ3jOYZ19vJPpbORTGrJqvraMVbB8T a6gXxuuZOtGF0lAxPSr77sXMRNE2HCh779KjlKkfyK5RE2O4UEibKTQcnOT3 Yj4zjEztUMNa9clUBJkwEynlW0.nzBTGfrhDnMWBD4H8XNsuiMJ7NScezovG 0VV4i436J_hsHOzvfJr5xMDkV6BjQseyqvwHUI8KKeQbwPtsX1dGOJ7.QgTc ERZtNQTb3wGijfcT6FIo2RIfYLBu2P5ps8v0DnlCEB_yqvX24MtLoa3Au9_y gZJFCAdbI4pNhm.t6_g0kFLOHj51yVSJjMQL2QQ2gRoQs.UErlErZUmiphq1 k3JCBsKl736Qh1WGcMjV.YYAQ Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Sat, 02 Feb 2013 14:03:43 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiQWNrZXJtYW5uLCBNaWNoYWVsIiA8TUFja2VybWFubkBiY2JzbS5jb20.Cj4gVG86IFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb20.OyBGcmVkIEJha2VyIDxmcmVkQGNpc2NvLmNvbT4KPiBDYzogSUVURiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBTdW5kYXksIDMgRmVicnVhcnkgMjAxMyAzOjM3IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.131.499 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> Message-ID: <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Sat, 2 Feb 2013 14:03:43 -0800 (PST) From: Mark Smith To: "Ackermann, Michael" , Fred Baker In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 22:03:45 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "Ackermann, Michael" =0A> To: Randy Bush ; Fred Baker =0A> Cc: IETF v6ops list =0A> Sent: Sunday, 3 Febru= ary 2013 3:37 AM=0A> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv= 6-ipid-needed=0A> =0A>T hanks for the comments Randy.=A0 We would be inter= ested in your measurements and =0A> any other related info/thoughts/insight= s you may have!=0A> =0A> We are new to IETF and if we should be working wit= h other or additional Working =0A> Groups, we are certainly open to that.= =A0 =0A> =0A> I am curious why you feel 6man would not be open to this?=A0 = =0A>=A0=0A=0ARandy is probably talking about proposed changes to the fixed = portion of the IPv6 header. The extension header approach you've take is th= e correct one to extend IPv6, although new extension header transparency ov= er the Internet can be a problem as some (most? all?) firewalls drop what t= hey don't understand.=0A=0AI've had a brief look at your drafts, one thing = I'm a bit confused about is exactly how the IPID field is used. Part of the= reason I ask is that it reads like your draft is saying that the IPID fiel= d always has useful values. My understanding is that the IPID field only ha= s to have useful values if the packet is carrying a fragment. Here's what R= FC791 says:=0A=0A=A0 Identification: =A016 bits=0A=0A=A0 =A0 An identifying= value assigned by the sender to aid in assembling the=0A=A0 =A0 fragments = of a datagram.=0A=0AAre you artificially setting the value of the IPID fiel= d in your test traffic, or do you happen to have traffic sources that set t= he IPID field value regardless of whether the packet contains a fragment or= not?=0A=0A=0AHave you considered the IPv6 Flow Label field for your purpos= e? It might suit your requirement.=0A=0A=0ARegards,=0AMark.=0A=0A> Thanks a= gain!=0A> =0A> Mike=0A> =0A> =0A> -----Original Message-----=0A> From: v6op= s-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Randy =0A> = Bush=0A> Sent: Saturday, February 02, 2013 11:22 AM=0A> To: Fred Baker=0A> = Cc: IETF v6ops list=0A> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-= ipv6-ipid-needed=0A> =0A> a strange document, a plea for ipid in v6.=A0 i k= inda like[d] ipid and we did some =0A> reasearch measurements on it.=A0 act= ually, i think we are still collecting and =0A> have some years of longitud= inal data.=0A> =0A> but i would think that this document would be in 6man, = where putting ipid in the =0A> v6 header does not have a snowball's chance = in hell.=0A> =0A> randy=0A> _______________________________________________= =0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman= /listinfo/v6ops=0A> =0A> =0A> The information contained in this communicati= on is highly confidential and is =0A> intended solely for the use of the in= dividual(s) to whom this communication is =0A> directed. If you are not the= intended recipient, you are hereby notified that =0A> any viewing, copying= , disclosure or distribution of this information is =0A> prohibited. Please= notify the sender, by electronic mail or telephone, of any =0A> unintended= receipt and delete the original message without making any copies.=0A> =0A= > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = =0A> nonprofit corporations and independent licensees of the Blue Cross and= Blue =0A> Shield Association.=0A> ________________________________________= _______=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/v6ops=0A> From fred@cisco.com Sat Feb 2 14:23: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 9BEE121F8574 for ; Sat, 2 Feb 2013 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.948 X-Spam-Level: X-Spam-Status: No, score=-109.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrzKnJ2gOIWA for ; Sat, 2 Feb 2013 14:23:19 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8700B21F851F for ; Sat, 2 Feb 2013 14:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5037; q=dns/txt; s=iport; t=1359843799; x=1361053399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9mdG+KAqwiazWtJfkb1SY7isUJ3p94dE7sfvtwTS66s=; b=iFmswXVXvhEO+kzcKwMy29vdGf5NMNZ91QrODbVNckCxrVg9zSqaPp3c zv5js8qe+75WWaCmVI8ykHCF8N2pnFlyYRPiFpxEi8RhPnsbvihGtYU00 tRhRyx+DBaCxvUPB+STq3eWlDJW+3GhISxDNCLvjRSVKHA1tKAw5WSi5m A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAG6QDVGtJXG//2dsb2JhbABFvzUWc4IfAQEBAwEBAQFrCwUHBAIBCBEEAQELHQcnCxQJCAIEDgUIh3cDCQYMwSUEjB2BDYNHYQOIMIwbjROFEoJ8gW81 X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; d="scan'208";a="172311110" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 02 Feb 2013 22:23:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r12MNIYB006213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Feb 2013 22:23:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Sat, 2 Feb 2013 16:23:18 -0600 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAZPm/mqxTUhRbESrmt6GbxpTfQ== Date: Sat, 2 Feb 2013 22:23:18 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7673AB@xmb-rcd-x09.cisco.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 22:23:20 -0000 On Feb 2, 2013, at 2:03 PM, Mark Smith wrote: >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: "Ackermann, Michael" >> To: Randy Bush ; Fred Baker >> Cc: IETF v6ops list >> Sent: Sunday, 3 February 2013 3:37 AM >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>=20 >> T hanks for the comments Randy. We would be interested in your measure= ments and=20 >> any other related info/thoughts/insights you may have! >>=20 >> We are new to IETF and if we should be working with other or additional = Working=20 >> Groups, we are certainly open to that. =20 >>=20 >> I am curious why you feel 6man would not be open to this? =20 >> =20 >=20 > Randy is probably talking about proposed changes to the fixed portion of = the IPv6 header. The extension header approach you've take is the correct o= ne to extend IPv6, although new extension header transparency over the Inte= rnet can be a problem as some (most? all?) firewalls drop what they don't u= nderstand. >=20 > I've had a brief look at your drafts, one thing I'm a bit confused about = is exactly how the IPID field is used. Part of the reason I ask is that it = reads like your draft is saying that the IPID field always has useful value= s. My understanding is that the IPID field only has to have useful values i= f the packet is carrying a fragment. Here's what RFC791 says: >=20 > Identification: 16 bits >=20 > An identifying value assigned by the sender to aid in assembling the > fragments of a datagram. It actually has to go farther than that. Suppose, just for fun, that the RFC 791 sender is always sending ipid=3D0, = and some router en route is fragmenting every third datagram. If the router= doing that leaves lipid alone, they will all appear to be fragments of the= same datagram. If the router is updating lipid, what should it update lipi= d to? No, the RFC 791 sender is on the hook to give datagrams within the same ses= sion (e.g., having the same source, destination, and protocol number) diffe= ring ipid values, since it doesn't know whether a router mid-stream will ne= ed to manipulate the packet. There are some interesting ramifications that can come into play there. It = is legal for an implementation to maintain some kind of counter and simply = enumerate the packets it sends, and that is the usual procedure AFAIK. It w= ould also be legal for a UDP application or a TCP/SCTP/DCCP transport to ke= ep a similar counter for the session, as long as it knew that there were no= other sessions with the same peer. In IPv6, since only the originator fragments, the whole point is kind of mo= ot. If the fragment header is there, the id field had bester be written in,= and it *is* meaningful. > Are you artificially setting the value of the IPID field in your test tra= ffic, or do you happen to have traffic sources that set the IPID field valu= e regardless of whether the packet contains a fragment or not? >=20 >=20 > Have you considered the IPv6 Flow Label field for your purpose? It might = suit your requirement. >=20 >=20 > Regards, > Mark. >=20 >> Thanks again! >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f Randy=20 >> Bush >> Sent: Saturday, February 02, 2013 11:22 AM >> To: Fred Baker >> Cc: IETF v6ops list >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>=20 >> a strange document, a plea for ipid in v6. i kinda like[d] ipid and we = did some=20 >> reasearch measurements on it. actually, i think we are still collecting= and=20 >> have some years of longitudinal data. >>=20 >> but i would think that this document would be in 6man, where putting ipi= d in the=20 >> v6 header does not have a snowball's chance in hell. >>=20 >> randy >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >> The information contained in this communication is highly confidential a= nd is=20 >> intended solely for the use of the individual(s) to whom this communicat= ion is=20 >> directed. If you are not the intended recipient, you are hereby notified= that=20 >> any viewing, copying, disclosure or distribution of this information is= =20 >> prohibited. Please notify the sender, by electronic mail or telephone, o= f any=20 >> unintended receipt and delete the original message without making any co= pies. >>=20 >> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are= =20 >> nonprofit corporations and independent licensees of the Blue Cross and B= lue=20 >> Shield Association. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From Guillaume.Leclanche@swisscom.com Sat Feb 2 16:02: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 52D4721F851C for ; Sat, 2 Feb 2013 16:02:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQfGJlOoDRUy for ; Sat, 2 Feb 2013 16:02:16 -0800 (PST) Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) by ietfa.amsl.com (Postfix) with ESMTP id 62F2921F84C9 for ; Sat, 2 Feb 2013 16:02:15 -0800 (PST) Received: by mail.swisscom.com; Sun, 3 Feb 2013 01:02:13 +0100 From: To: Thread-Topic: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security Thread-Index: AQHN+wI35CUCRUcNhEivPCDkb6diJ5haJY4AgAlHSwCAA9CFoA== Date: Sun, 3 Feb 2013 00:02:11 +0000 Message-ID: <1BE5D090C6244A49B9815F339F76EA4538304667@SG000708.corproot.net> References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: fr-CH, de-CH, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.222.87.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops@ietf.org, draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Feb 2013 00:02:17 -0000 > De=A0: Eduard Metz [mailto:etmetz@gmail.com] > Envoy=E9=A0: jeudi 31 janvier 2013 14:50 > > I general I think having different (defined) "security profiles" is somet= hing > that could be beneficial (e.g. CPE's having multiple predefined modes of > operation) so in that respect this is a good initiative. At the same time= it > would also be good if there would be some sort of applicability statement= for > these different profiles that describes which profile is most suitable fo= r > specific cases. Because, even though the draft claims this is sufficient = for the > proverbial grandma, I'm not convinced this category of users would also > actually need this (that they would be protected is also a rather big cla= im). It > may even be confusing since their Internet access service behaves > differently for IPv4 and IPv6. Yes, but on the other hand there are many more differences between v4 and v= 6 (starting with privacy extensions). We have to live with potential confus= ion during the few decades that this transition will last. Otherwise I agree that we should mitigate the "protected" word here. > Targeting for a fixed policy (Sec 3) doesn't seem realistic to me. As > mentioned in the draft, the policy must be maintained to ensure it lives = up to > it's goals / intention. In my opinion it's also this aspect that makes it= more or > less unsuitable for the average user. How do the authors feel about polic= y > maintainance (e.g. responsiblity of the end-user, or the operator/ISP)? I= n > particular the protection of weak services, or services in general would = be > better I think, seems a complex task given the large variation in devices= in the > home environment. Some guidelines on policy maintainance would be > usefull I think. The list of ports for this predefined setup is not an RFC recommendation, i= t's just an example. It should ideally be maintained by the ISP and enforce= d in the CPE, when the CPE is provided by the ISP. Ideally again, the user should be able to modify his firewalling rules on t= he CPE to match his own needs. > Is it correct that this draft suggest to implement RFC6092 except REC- > 11/18/33, and proposes alternatives for these requirements? This was at > least my interpretation of 3 & 4 in section 3.1 (note: 3 mentions REC- > 11/17/33, whereas 4 mentions REC-18 instead of 17). Re-reading 6092, it's REC-17 indeed. Thanks for the notice. > Section 3.2 describes that technical users could "open other applications= ", > not sure what is meant here. I thought the point was the CPE would be > open? Other applications then being the exceptions/weak services that are > prohibited? You're right; the wording is not appropriate. The idea is to say that the u= ser should be able to configure his rules. =20 > Not sure the policy really prevents unauthorised access. The policy preve= nts > (any) access to some known ports (that may have weaknesses), but other > services/devices are still accessible and vulnerable to unauthorised acce= ss > (e.g. a NAS using a web-based management interface, running on a differen= t > port). Also, do the statements in Section 6 mean that the balance-policy > does not protect against other threats as mentioned in Section 2? It's clear that the set of ports can't cover every single product existing = on the market that might introduce vulnerability in the customer network. However, this list is just an example in the RFC. Therefore every implement= ation of this policy will be different.=20 We'll probably have to complete the security section to make this more tran= sparent. >=20 > There is no mention about the use of privacy extensions, although this do= es > influence the end-to-end connectivity this draft attempts to restore. > Something to include? Could make sense. Let's see if we find a nice place to talk about it. Thanks for the review! Guillaume From Guillaume.Leclanche@swisscom.com Sat Feb 2 16:14: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 9421721F846E for ; Sat, 2 Feb 2013 16:14:47 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2KruxiUm1Jh for ; Sat, 2 Feb 2013 16:14:47 -0800 (PST) Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) by ietfa.amsl.com (Postfix) with ESMTP id C2FA121F844E for ; Sat, 2 Feb 2013 16:14:46 -0800 (PST) Received: by mail.swisscom.com; Sun, 3 Feb 2013 01:14:45 +0100 From: To: Thread-Topic: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security Thread-Index: AQHN+wI35CUCRUcNhEivPCDkb6diJ5haJY4AgAy2gACAAHFfUA== Date: Sun, 3 Feb 2013 00:14:43 +0000 Message-ID: <1BE5D090C6244A49B9815F339F76EA4538305691@SG000708.corproot.net> References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: fr-CH, de-CH, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.222.87.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops@ietf.org, draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Feb 2013 00:14:47 -0000 > De=A0: Cameron Byrne [mailto:cb.list6@gmail.com] > Envoy=E9=A0: samedi 2 f=E9vrier 2013 19:16 > I believe it would be helpful to call out that the drop rules can be stat= elessly > implemented in the provider network while the ratelimiting function is > stateful and is a better fit for the CPE. >=20 > I would also suggest the the term residential be changed to include mobil= e. > Perhaps "consumer grade" internet service or something like that. Hi Cameron, I understand very well your point and I guess your arguments (from a mobile= point of view), but this RFC wants to focus on the CPE features, and we do= n't want to talk about ISP filters. And regarding the mobile: nothing prevents the residential CPE uplink to be= mobile, and with LTE connectivity we'll certainly see that more and more. Guillaume From mackermann@bcbsm.com Sat Feb 2 16:27: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 3D5CC21F853C for ; Sat, 2 Feb 2013 16:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl+XFe-31Z7g for ; Sat, 2 Feb 2013 16:27:04 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 6461021F8530 for ; Sat, 2 Feb 2013 16:27:03 -0800 (PST) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 5E5AD17E45E for ; Sat, 2 Feb 2013 18:27:02 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 4A5DB17E42E; Sat, 2 Feb 2013 18:27:01 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 2E0994F804D; Sat, 2 Feb 2013 19:25:45 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 205954F8049; Sat, 2 Feb 2013 19:25:45 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Sat, 2 Feb 2013 19:27:00 -0500 From: "Ackermann, Michael" To: Mark Smith , Fred Baker Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAALBqgP//0x6Q Date: Sun, 3 Feb 2013 00:26:59 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DDD95@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 00:27:05 -0000 Thanks Mark. I think you are already aware that if Fragmentation is required, The = Fragmentation Header will be there and IPID will be in there and is needed = for reassembly. But are big issues is that for certain situations, the = IPID has be a very valuable diagnostic tool. Thus we feel it is needed = even in situations were fragmentation is not required. =20 We are open to what the best implementation or way to achieve that is, but = we have included one possible solution in our RFC.=20 Mike -----Original Message----- From: Mark Smith =5Bmailto:markzzzsmith=40yahoo.com.au=5D=20 Sent: Saturday, February 02, 2013 5:04 PM To: Ackermann, Michael; Fred Baker Cc: IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed ----- Original Message ----- > From: =22Ackermann, Michael=22 > To: Randy Bush ; Fred Baker > Cc: IETF v6ops list > Sent: Sunday, 3 February 2013 3:37 AM > Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 >T hanks for the comments Randy.=A0 We would be interested in your=20 >measurements and any other related info/thoughts/insights you may have=21 >=20 > We are new to IETF and if we should be working with other or=20 > additional Working Groups, we are certainly open to that. >=20 > I am curious why you feel 6man would not be open to this? >=A0 Randy is probably talking about proposed changes to the fixed portion of = the IPv6 header. The extension header approach you've take is the correct = one to extend IPv6, although new extension header transparency over the = Internet can be a problem as some (most? all?) firewalls drop what they = don't understand. I've had a brief look at your drafts, one thing I'm a bit confused about = is exactly how the IPID field is used. Part of the reason I ask is that it = reads like your draft is saying that the IPID field always has useful = values. My understanding is that the IPID field only has to have useful = values if the packet is carrying a fragment. Here's what RFC791 says: =A0 Identification: =A016 bits =A0 =A0 An identifying value assigned by the sender to aid in assembling the =A0 =A0 fragments of a datagram. Are you artificially setting the value of the IPID field in your test = traffic, or do you happen to have traffic sources that set the IPID field = value regardless of whether the packet contains a fragment or not? Have you considered the IPv6 Flow Label field for your purpose? It might = suit your requirement. Regards, Mark. > Thanks again=21 >=20 > Mike >=20 >=20 > -----Original Message----- > From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf=20 > Of Randy Bush > Sent: Saturday, February 02, 2013 11:22 AM > To: Fred Baker > Cc: IETF v6ops list > Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > a strange document, a plea for ipid in v6.=A0 i kinda like=5Bd=5D ipid = and=20 > we did some reasearch measurements on it.=A0 actually, i think we are=20 > still collecting and have some years of longitudinal data. >=20 > but i would think that this document would be in 6man, where putting=20 > ipid in the > v6 header does not have a snowball's chance in hell. >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > The information contained in this communication is highly confidential=20 > and is intended solely for the use of the individual(s) to whom this=20 > communication is directed. If you are not the intended recipient, you=20 > are hereby notified that any viewing, copying, disclosure or=20 > distribution of this information is prohibited. Please notify the=20 > 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=20 > are nonprofit corporations and independent licensees of the Blue Cross=20 > and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From owen@delong.com Sat Feb 2 16:33: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 038DB21F84B2 for ; Sat, 2 Feb 2013 16:33:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDnaZolm9eM9 for ; Sat, 2 Feb 2013 16:33:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B7CBF21F8599 for ; Sat, 2 Feb 2013 16:33:53 -0800 (PST) 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 r130XSMg026965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 2 Feb 2013 16:33:29 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r130XSMg026965 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1359851609; bh=2MF/6SqKfgMNDkkEa9F/3ZHTUX4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X66A4KUkwmbOq86M8WrW2WLNWOTvq4HG7icC0Jkcgq+FYej0ZFaa4ZOvzxEt+dVNz SmRvu4CqJKeXTwRNKNKfjEkFkcKi5+G4fDNXc8edb9WHURkRCKzLAVaR4Xq0gucGyQ 1JZiVnCwxt1rVk6tOVRAcrH6kM0vBNDGR3o1IBew= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DDD95@PWN401EA160.ent.corp.bcbsm.com> Date: Sat, 2 Feb 2013 16:33:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8C060383-65C6-4FA9-AEDA-C76684AB47E2@delong.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A0DDD95@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 02 Feb 2013 16:33:29 -0800 (PST) Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 00:33:56 -0000 It seems to me that in most of the situations you described, the flow = label could be used as a valid substitute. Am I wrong? Owen On Feb 2, 2013, at 16:26 , "Ackermann, Michael" = wrote: > Thanks Mark. >=20 > I think you are already aware that if Fragmentation is required, The = Fragmentation Header will be there and IPID will be in there and is = needed for reassembly. But are big issues is that for certain = situations, the IPID has be a very valuable diagnostic tool. Thus we = feel it is needed even in situations were fragmentation is not required. = =20 >=20 > We are open to what the best implementation or way to achieve that is, = but we have included one possible solution in our RFC.=20 >=20 >=20 > Mike >=20 >=20 >=20 > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@yahoo.com.au]=20 > Sent: Saturday, February 02, 2013 5:04 PM > To: Ackermann, Michael; Fred Baker > Cc: IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: "Ackermann, Michael" >> To: Randy Bush ; Fred Baker >> Cc: IETF v6ops list >> Sent: Sunday, 3 February 2013 3:37 AM >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>=20 >> T hanks for the comments Randy. We would be interested in your=20 >> measurements and any other related info/thoughts/insights you may = have! >>=20 >> We are new to IETF and if we should be working with other or=20 >> additional Working Groups, we are certainly open to that. >>=20 >> I am curious why you feel 6man would not be open to this? >> =20 >=20 > Randy is probably talking about proposed changes to the fixed portion = of the IPv6 header. The extension header approach you've take is the = correct one to extend IPv6, although new extension header transparency = over the Internet can be a problem as some (most? all?) firewalls drop = what they don't understand. >=20 > I've had a brief look at your drafts, one thing I'm a bit confused = about is exactly how the IPID field is used. Part of the reason I ask is = that it reads like your draft is saying that the IPID field always has = useful values. My understanding is that the IPID field only has to have = useful values if the packet is carrying a fragment. Here's what RFC791 = says: >=20 > Identification: 16 bits >=20 > An identifying value assigned by the sender to aid in assembling = the > fragments of a datagram. >=20 > Are you artificially setting the value of the IPID field in your test = traffic, or do you happen to have traffic sources that set the IPID = field value regardless of whether the packet contains a fragment or not? >=20 >=20 > Have you considered the IPv6 Flow Label field for your purpose? It = might suit your requirement. >=20 >=20 > Regards, > Mark. >=20 >> Thanks again! >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf=20 >> Of Randy Bush >> Sent: Saturday, February 02, 2013 11:22 AM >> To: Fred Baker >> Cc: IETF v6ops list >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>=20 >> a strange document, a plea for ipid in v6. i kinda like[d] ipid and=20= >> we did some reasearch measurements on it. actually, i think we are=20= >> still collecting and have some years of longitudinal data. >>=20 >> but i would think that this document would be in 6man, where putting=20= >> ipid in the >> v6 header does not have a snowball's chance in hell. >>=20 >> randy >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >> The information contained in this communication is highly = confidential=20 >> and is intended solely for the use of the individual(s) to whom this=20= >> communication is directed. If you are not the intended recipient, you=20= >> are hereby notified that any viewing, copying, disclosure or=20 >> distribution of this information is prohibited. Please notify the=20 >> 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=20= >> are nonprofit corporations and independent licensees of the Blue = Cross=20 >> and Blue Shield Association. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sat Feb 2 18:05: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 9E7A421F857A for ; Sat, 2 Feb 2013 18:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.257 X-Spam-Level: X-Spam-Status: No, score=-110.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtomm4qsaIqg for ; Sat, 2 Feb 2013 18:05:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EF35321F85DC for ; Sat, 2 Feb 2013 18:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1752; q=dns/txt; s=iport; t=1359857112; x=1361066712; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bQK2urTF7eiB4e6G0NNQOD9NKOJXN3jUKKLQKCEaYgQ=; b=FVX+PJehsq7WeS3yHbQSQcY8xVagzenkaZi24ZG7kOJfumKDSqy7LX/T R5o9Mw5ulcGyo3oHJqQPo7Ck9GMJwQlK6W5VmaHblUp9MmbpDBUJvk9A6 PoNXBWwV9/0oW+krc/bQe5L02MBiPCj8MBK8HvzLALZcXLYawSOEodHuO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOjEDVGtJV2d/2dsb2JhbABFvzIWc4IfAQEBAwF5BQsCAQgiJDIlAgQOBQiIAwbBIZBxYQOIMIo3lAmCfIIk X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; d="scan'208";a="172310713" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 03 Feb 2013 02:05:11 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1325BX5006135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Feb 2013 02:05:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sat, 2 Feb 2013 20:05:11 -0600 From: "Fred Baker (fred)" To: Owen DeLong Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAbLl+vwCm2kZNEu7LsIO4d+sJg== Date: Sun, 3 Feb 2013 02:05:10 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B76767A@xmb-rcd-x09.cisco.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A0DDD95@PWN401EA160.ent.corp.bcbsm.com> <8C060383-65C6-4FA9-AEDA-C76684AB47E2@delong.com> In-Reply-To: <8C060383-65C6-4FA9-AEDA-C76684AB47E2@delong.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: <54E6A4502158C3449D65DD015C5CF8A1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 02:05:18 -0000 On Feb 2, 2013, at 4:33 PM, Owen DeLong wrote: > It seems to me that in most of the situations you described, the flow lab= el could be used > as a valid substitute. >=20 > Am I wrong? I think you are. I may be wrong. Chair hat most definitely off. An ipid is by definition a field that contains a number that is *different*= for every reassembled datagram headed from point A to point B using a give= n transport protocol. The intended use case is fragmentation and reassembly= A Flow Label is by definition a field that contains a number that is the *= same* for every datagram headed from point A to point B that is within the = same flow, whatever a flow is. We have a number of RFCs that try to describ= e use cases, but it's hard for me to describe the flow label as having a re= al consensus behind it apart from that sentence. Now, you could argue (and get some significant debate from some in 6man) th= at an operator is within his rights to overwrite the usually-zero flow labe= l with a number of his choosing and use it in whatever way he might. From N= alini's perspective, if I understand it correctly, this is also counter-pro= ductive; if she wants to know about the order packets actually arrive in, t= hat action would, at least in the ipid case, remove that information from t= he data stream. If one assumes that ipid simply counts, which is an undocum= ented and unrequired assumption, and the packets were out of order at the t= ime they arrived at the thing stomping on the flow label, they would now ap= pear to be in order. Yes, you could use the field. How you would use it would depend a lot on th= e assumptions you were making and what you hoped to learn from it. From markzzzsmith@yahoo.com.au Sat Feb 2 18: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 1E84221F85DC for ; Sat, 2 Feb 2013 18:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg2Q7y7hcCTf for ; Sat, 2 Feb 2013 18:15:54 -0800 (PST) Received: from nm18.bullet.mail.bf1.yahoo.com (nm18.bullet.mail.bf1.yahoo.com [98.139.212.177]) by ietfa.amsl.com (Postfix) with SMTP id A5CBF21F85AE for ; Sat, 2 Feb 2013 18:15:53 -0800 (PST) Received: from [98.139.212.147] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:15:53 -0000 Received: from [98.139.212.223] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:15:53 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:15:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 39056.77425.bm@omp1032.mail.bf1.yahoo.com Received: (qmail 78039 invoked by uid 60001); 3 Feb 2013 02:15:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359857752; bh=os8pYptEav7PlobiHa7nu+eIyHhOgq9+MRqPRrrrawM=; 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=nli1tetyWHJoaRrm+Xuu/Usswy/YHFgQu1C6oe3aOp2qmecEcv/QoNqDFNOixEE0fcmna9jHO0veWjxPmGk/75ZTz6i7lTgNgXZAYoYhTiEBN6kOEytHW8y2C5kpGKHFOcXNY4DYYBXbWmVQtm02XRkDHk9M40fEZu5AzNunslM= 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=bGzmPYU7YQ0Xrv/9aG3TsnR2bb7TpE4Oui87AClpiYGoIFXNsOihned2KUP/g5hO5dOMMKJa9EjQONhD+BaRePn3iUFz0cJwzNsDEnxUjnw32rldxrbYQmF6oZm/DxM/D+FpK/XODC6guZhXE6CcD1yTvHwwxL86aAIEqYbXeSw=; X-YMail-OSG: lOBpxy8VM1nearc6YqP4vH4IQmJq7NjU850v8d6XLdsgm21 ruIqpbQ34M3Dk91aF8Fh6bN54EH13usvC72OPsJnxgjY12MZb_9xMvXC3NaR TpLW9KgJUkFVecf.0qA3kH5D5XiIhEqhXkgdkR7YldklO3HB8bwizuMRfFzs LwQn5oggB0fhSdJRyQM6FbwVvji6HNuyWR300Plira_o85b9kccugHLt8ojb MCiSCRa5VJRFIuBQ3Rb5QkgpDn4ZtdU9JJk3jiX5eDV4eQeKiCOXQPb5aN2i wIU2EWzGDUgkR3gLZkkjHbeaSALtLJ_IMNOYNuKxWrpNH3Rq93kkKp2_mO3q kGnf5jZeKhcorImudr_oJDu8b9l1tBrgzF_WoYS4ztujin6ihJ4hWbcsQ1uZ M2ukR4uKFWZJzjyD7GVx10c6HK4yaK74Np70O1QoUpE0c_0T.CEUDrj80qo7 6xHj6L1bcsdblUON_zEdu8d2Ii3yEwTpwzV72pDnKexsLrRCUdBrmMsTYmIK WXUQocXUgmadetPvyGRS_gM57iQ-- Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Sat, 02 Feb 2013 18:15:52 PST X-Rocket-MIMEInfo: 001.001, SGkgRnJlZCwKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPgo.IFRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiAiQWNrZXJtYW5uLCBNaWNoYWVsIiA8TUFja2VybWFubkBiY2JzbS5jb20.OyBJRVRGIHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFN1bmRheSwgMyBGZWJydWFyeSAyMDEzIDk6MjMgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.131.499 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> <8C48B86A895913448548E6D15DA7553B7673AB@xmb-rcd-x09.cisco.com> Message-ID: <1359857752.49949.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Sat, 2 Feb 2013 18:15:52 -0800 (PST) From: Mark Smith To: "Fred Baker \(fred\)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B7673AB@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 02:15:55 -0000 Hi Fred,=0A=0A=0A----- Original Message -----=0A> From: Fred Baker (fred) <= fred@cisco.com>=0A> To: Mark Smith =0A> Cc: "Ack= ermann, Michael" ; IETF v6ops list = =0A> Sent: Sunday, 3 February 2013 9:23 AM=0A> Subject: Re: [v6ops] new dra= ft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A> =0A> On Feb 2, 2013, at 2:= 03 PM, Mark Smith =0A> wrote:=0A>=0A=A0 =0A=0A=0A>> I've had a brief look at your drafts, one thing I'm a bit confus= ed =0A> about is exactly how the IPID field is used. Part of the reason I a= sk is that it =0A> reads like your draft is saying that the IPID field alwa= ys has useful values. My =0A> understanding is that the IPID field only has= to have useful values if the =0A> packet is carrying a fragment. Here's wh= at RFC791 says:=0A>> =0A>> =A0 Identification:=A0 16 bits=0A>> =0A>> =A0 = =A0 An identifying value assigned by the sender to aid in assembling the= =0A>> =A0 =A0 fragments of a datagram.=0A> =0A> It actually has to go fart= her than that.=0A> =0A> Suppose, just for fun, that the RFC 791 sender is a= lways sending ipid=3D0, and =0A> some router en route is fragmenting every = third datagram. If the router doing =0A> that leaves lipid alone, they will= all appear to be fragments of the same =0A> datagram. If the router is upd= ating lipid, what should it update lipid to?=0A> =0A> No, the RFC 791 sende= r is on the hook to give datagrams within the same session =0A> (e.g., havi= ng the same source, destination, and protocol number) differing ipid =0A> v= alues, since it doesn't know whether a router mid-stream will need to =0A> = manipulate the packet.=0A> =0A> There are some interesting ramifications th= at can come into play there. It is =0A> legal for an implementation to main= tain some kind of counter and simply =0A> enumerate the packets it sends, a= nd that is the usual procedure AFAIK.=0A=0AI also asked the question becaus= e I thought I read somewhere that Linux set the ID field to zeros when the = packet didn't contain a fragment. My memory is vague, however perhaps that = is the case when the DF bit is set on the packet, so the ID field will neve= r be used to defragment.=0A=0AThe reason I think I remember this is because= it seemed like an unusual optimisation. I'm doing some digging around to s= ee if I can confirm my memory is correct or not.=0A=0A=0A> =A0It would=A0= =0A=0A> also be legal for a UDP application or a TCP/SCTP/DCCP transport to= keep a =0A> similar counter for the session, as long as it knew that there= were no other =0A> sessions with the same peer.=0A>=A0=0A> In IPv6, since = only the originator fragments, the whole point is kind of moot.=A0=0A=0A> I= f the fragment header is there, the id field had bester be written in, and = it =0A> *is* meaningful.=0A> =0A>> Are you artificially setting the value = of the IPID field in your test =0A> traffic, or do you happen to have traff= ic sources that set the IPID field value =0A> regardless of whether the pac= ket contains a fragment or not?=0A>> =0A>> =0A>> Have you considered the I= Pv6 Flow Label field for your purpose? It might =0A> suit your requirement.= =0A>> =0A>> =0A>> Regards,=0A>> Mark.=0A>> =0A>>> Thanks again!=0A>>> = =0A>>> Mike=0A>>> =0A>>> =0A>>> -----Original Message-----=0A>>> From: v= 6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =0A> Of Ran= dy =0A>>> Bush=0A>>> Sent: Saturday, February 02, 2013 11:22 AM=0A>>> To= : Fred Baker=0A>>> Cc: IETF v6ops list=0A>>> Subject: Re: [v6ops] new dra= ft: draft-elkins-v6ops-ipv6-ipid-needed=0A>>> =0A>>> a strange document, a= plea for ipid in v6.=A0 i kinda like[d] ipid and we =0A> did some =0A>>> = reasearch measurements on it.=A0 actually, i think we are still =0A> collec= ting and =0A>>> have some years of longitudinal data.=0A>>> =0A>>> but i = would think that this document would be in 6man, where putting =0A> ipid in= the =0A>>> v6 header does not have a snowball's chance in hell.=0A>>> =0A= >>> randy=0A>>> _______________________________________________=0A>>> v6= ops mailing list=0A>>> v6ops@ietf.org=0A>>> https://www.ietf.org/mailman/= listinfo/v6ops=0A>>> =0A>>> =0A>>> The information contained in this commu= nication is highly confidential =0A> and is =0A>>> intended solely for the= use of the individual(s) to whom this =0A> communication is =0A>>> direct= ed. If you are not the intended recipient, you are hereby =0A> notified tha= t =0A>>> any viewing, copying, disclosure or distribution of this informat= ion is =0A> =0A>>> prohibited. Please notify the sender, by electronic mai= l or telephone, =0A> of any =0A>>> unintended receipt and delete the origi= nal message without making any =0A> copies.=0A>>> =0A>>> Blue Cross Blue S= hield of Michigan and Blue Care Network of Michigan =0A> are =0A>>> nonpro= fit corporations and independent licensees of the Blue Cross and =0A> Blue = =0A>>> Shield Association.=0A>>> ________________________________________= _______=0A>>> v6ops mailing list=0A>>> v6ops@ietf.org=0A>>> https://www.= ietf.org/mailman/listinfo/v6ops=0A>>> =0A> From randy@psg.com Sat Feb 2 18: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 8FF6921F85FC for ; Sat, 2 Feb 2013 18:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHJUDFOrQMYs for ; Sat, 2 Feb 2013 18:21:12 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 021C021F8600 for ; Sat, 2 Feb 2013 18:21:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U1pCg-000OuD-9x; Sun, 03 Feb 2013 02:21:10 +0000 Date: Sun, 03 Feb 2013 11:21:09 +0900 Message-ID: From: Randy Bush To: Michael Ackermann In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.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: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 02:21:12 -0000 > Thanks for the comments Randy. We would be interested in your > measurements and any other related info/thoughts/insights you may > have! what is left of my memory is that the first paper on using ipid was "Touring the internet in a TCP sidecar" Rob Sherwood & Neil Spring IMC 2006 Proceedings of the 6th ACM SIGCOMM conference on Internet measurement but that could have been their record route paper. been too long. sorry. > We are new to IETF and if we should be working with other or > additional Working Groups, we are certainly open to that. that is generally called 'venue shopping.' in a culture as small as the ietf, it is quite noticeable and frowned upon. > I am curious why you feel 6man would not be open to this? because ipv6 is perfect, especially the address model and the header. lack of usability is the fault of the operators, vendors, application developers, users, and the people in the black helicopters. < /dripping sarcasm > randy From markzzzsmith@yahoo.com.au Sat Feb 2 18:39: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 A2A7821F85E7 for ; Sat, 2 Feb 2013 18:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HFm1a2WXcCj for ; Sat, 2 Feb 2013 18:39:14 -0800 (PST) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with SMTP id 6C4E421F85BF for ; Sat, 2 Feb 2013 18:39:14 -0800 (PST) Received: from [98.139.212.144] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:39:13 -0000 Received: from [98.139.212.221] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:39:13 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:39:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 843663.2385.bm@omp1030.mail.bf1.yahoo.com Received: (qmail 79048 invoked by uid 60001); 3 Feb 2013 02:39:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359859153; bh=drd7aIvcozAxMWl2BJ9ci1FVQDcuTK2VfZ2OS/AsVKE=; 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=rtaAj1En7r8Q7q2cwXxDYpORq4tTjBsJCB8AVxuprwm7ZnL+Ii1M1OIdaOn4+7u810qUUeG4KuvqrdEErR1TFt/aQzKGVx0rGfgDCWa6mQOKxuFO3U7NLcODzjOlNZPDof84CUn4I5eC6OIQcJkzwbErL0dKdkqouKcsqJ6XVc4= 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=zVU9hBOmJAUaAfHgFr4+ioXWwg40b7qHzufmbP5Ed2a0A+WxFqAPWPftZpAmo4C+EqIjb9SgXFLJaiUFXpaWnR70LIM2MPbpNDbNxMee1EBsUAQxBadxEyU5YOH1J+7vFk5u/a3v+0avKBuEJ3gyv4F1C8Nl3rQIG83LoEGr6f8=; X-YMail-OSG: 6tFzBbYVM1l.OylIv2LocoX1mkmqmv3hvsRY4kfH.O4u8kI 3wy7FpG6kQoIhBqhVXVLhISLMhAeGqjjwU597aRW2DhUhf8sZcGYcrn2a6dD nluvalpefXFZLzJ8FXpWZYXGuVEEXEZgME9alUqOEMfhHU40PN9UI7G0.vor y.PlLGyVzKQWaKQwe8oyYydbycs3EqwykdS2mCvTqag.a6udG.DGYGWxX.z2 rhKuJWmRc7qil2IikvWqtGW8aOWASZb0qi323zWQywqbTUucsgFYaLNHnwHh _CswugvhilU8AXkVpu5kL2bciW9KNi7FMpUcYsQ.tWSRe.LLWN1nCV1swtzS bQGMblTvXvXHsduiV.T6wUoHYDc4l3UHDp_HLtWFcca3Nqd_oYjfD4X3hfHs YmQnr97DoyK.8YxfXUa6AhB_K1RjTAZeuhk9OIRH4JfkNM3c5L8f8agkvHRo ILSHDvdJaKv0Lr8ur.lVLgaOrbcdnGs7MgVyDaKMRfzodoDfnJ79ppy0Spty hg6A28HH9.6rL4q.ur6kFpaI9M9Jz Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Sat, 02 Feb 2013 18:39:13 PST X-Rocket-MIMEInfo: 001.001, CgoKCjxzbmlwPgo.IAo.IEkgYWxzbyBhc2tlZCB0aGUgcXVlc3Rpb24gYmVjYXVzZSBJIHRob3VnaHQgSSByZWFkIHNvbWV3aGVyZSB0aGF0IExpbnV4IHNldCB0aGUgCj4gSUQgZmllbGQgdG8gemVyb3Mgd2hlbiB0aGUgcGFja2V0IGRpZG4ndCBjb250YWluIGEgZnJhZ21lbnQuIE15IG1lbW9yeSBpcyAKPiB2YWd1ZSwgaG93ZXZlciBwZXJoYXBzIHRoYXQgaXMgdGhlIGNhc2Ugd2hlbiB0aGUgREYgYml0IGlzIHNldCBvbiB0aGUgcGFja2V0LCBzbyAKPiB0aGUgSUQgZmllbGQgd2lsbCBuZXZlciBiZSB1c2UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.131.499 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> <8C48B86A895913448548E6D15DA7553B7673AB@xmb-rcd-x09.cisco.com> <1359857752.49949.YahooMailNeo@web142502.mail.bf1.yahoo.com> Message-ID: <1359859153.60740.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Sat, 2 Feb 2013 18:39:13 -0800 (PST) From: Mark Smith To: Mark Smith , "Fred Baker \(fred\)" In-Reply-To: <1359857752.49949.YahooMailNeo@web142502.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 02:39:15 -0000 =0A=0A=0A=0A=0A> =0A> I also asked the question because I thought I r= ead somewhere that Linux set the =0A> ID field to zeros when the packet did= n't contain a fragment. My memory is =0A> vague, however perhaps that is th= e case when the DF bit is set on the packet, so =0A> the ID field will neve= r be used to defragment.=0A> =0A> The reason I think I remember this is bec= ause it seemed like an unusual =0A> optimisation. I'm doing some digging ar= ound to see if I can confirm my =0A> memory is correct or not.=0A> =0A>=A0= =0A=0AI wasn't right about the ID field being set to zeros under Linux, how= ever it is kept constant for DF packets. Here's some of the comment text at= the top of "inetpeer.c" under /net/ipv4/ in the Linux kernel -=0A=0A/= *=0A=0A=A0* =A0 =A0 =A0 =A0 =A0 =A0 =A0INETPEER - A storage for permanent i= nformation about peers=0A=A0*=0A=0A...=0A/*=0A=A0* =A0Theory of operations.= =0A=A0* =A0We keep one entry for each peer IP address. =A0The nodes contain= s long-living=0A=A0* =A0information about the peer which doesn't depend on = routes.=0A=A0* =A0At this moment this information consists only of ID field= for the next=0A=A0* =A0outgoing IP packet. =A0This field is incremented wi= th each packet as encoded=0A=A0* =A0in inet_getid() function (include/net/i= netpeer.h).=0A=A0* =A0At the moment of writing this notes identifier of IP = packets is generated=0A=A0* =A0to be unpredictable using this code only for= packets subjected=0A=A0* =A0(actually or potentially) to defragmentation. = =A0I.e. DF packets less than=0A=A0* =A0PMTU in size uses a constant ID and = do not use this code (see=0A=A0* =A0ip_select_ident() in include/net/ip.h).= =0A From markzzzsmith@yahoo.com.au Sat Feb 2 18:48:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14ADB21F841E for ; Sat, 2 Feb 2013 18:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgcThsma0UJu for ; Sat, 2 Feb 2013 18:48:43 -0800 (PST) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with SMTP id 24B2021F8415 for ; Sat, 2 Feb 2013 18:48:43 -0800 (PST) Received: from [98.139.212.151] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:48:42 -0000 Received: from [98.139.212.198] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:48:42 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 02:48:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 448856.9623.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 82049 invoked by uid 60001); 3 Feb 2013 02:48:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359859722; bh=1PJPdxCHnbAAaV2EIUnLJgiLI8Gh3VzhLSNn/aC+bKw=; 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=Z8DMKodsFlUHzYrbnBhE4Cm7LzBO1iEBNvRr89wfpmM3m+8wKgt3OEgM6jGS5FZdlJjhBYN831j9g47fC8snV9BdKZuzYUSTZXiSb+57biu7g00RIONUQXQ1fEt2dDi7i7vpXSymClAa42HIRJAo9V6t/52e4//Bk6sVG/QD0jI= 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=HzXBYJc9Dr0PQzl5s4izyaCssLIPhGnUKyYtfNsmYB9Llb2Enc9CdKY6HkDqricHPkgVkcj29zoc9VjadThIHUYf0NPMZyi6QUVlm44ln9EpKf6pqE3Um2dXh0ClV+s9lIwkscIHtepYSzxZV74jh9ZLmliDllDhkNJpUROHXO0=; X-YMail-OSG: ceC65CEVM1nPqgJ9Ux1YoKozKECZX5sHmfLJHYnkJHy.yMU C3QwibZdcxGTm0xcgRVxI17po8MqKSuOiJPWuymbZ4mUG6bskLU5yp0GUnLi __vbZiAULqP.YuDWgUq8ttpq5zG5A60kQTGZSuG584KA8NwkWC26RQx5MVU3 fF9A21n_vd_mkneUxo4RYAQHbaRRFvRDLBr3ov5DPptCfaunHGjQrI_JPEaB S547N0cYyrOaYsFbF8ap39EvHhIhwLtDcawKVFGLsV1dsF_H_UARb0o_YMdh 7CNzMw88Go_Lw_6rehjxCd9_St68NljQ3Rr2cffPBegJNUF8tu31R6YXERFg MPb632KAIL__q9.VvMP6BXEVIebkQ4kXzb4UJ1_ftSwBwp2NXxzx35isifvY 8bAZMUlUZOF5hUF7J4ekC2t2WV6zMLfzaeOAhztkJDxxd3gxkHLjk5n.h4mx UzHGg5.5fQ30RGT6JIcCLmtR7EEXK8GYfMqNChEMJHejBTd_9NHFaX4lft4a aWUpEN2yCoIG5oRySFFRW8KY2 Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Sat, 02 Feb 2013 18:48:42 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPgo.IFRvOiBNaWNoYWVsIEFja2VybWFubiA8TUFja2VybWFubkBiY2JzbS5jb20.Cj4gQ2M6IElFVEYgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogU3VuZGF5LCAzIEZlYnJ1YXJ5IDIwMTMgMToyMSBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVkZWQKPiAKPj4gIFRoYW5rcyBmb3IgdGhlIGNvbW0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.131.499 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> Message-ID: <1359859722.80871.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Sat, 2 Feb 2013 18:48:42 -0800 (PST) From: Mark Smith To: Michael Ackermann In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 02:48:44 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Randy Bush =0A> To: Michael Ackermann =0A> Cc: IETF v6ops list= =0A> Sent: Sunday, 3 February 2013 1:21 PM=0A> Subject: Re= : [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A>> Thanks = for the comments Randy.=A0 We would be interested in your=0A>> measurement= s and any other related info/thoughts/insights you may=0A>> have!=0A> =0A>= what is left of my memory is that the first paper on using ipid was=0A> = =0A> =A0 =A0 "Touring the internet in a TCP sidecar" Rob Sherwood & Neil = =0A> Spring=0A> =A0 =A0 IMC 2006 Proceedings of the 6th ACM SIGCOMM confere= nce on Internet=0A> =A0 =A0 measurement=0A> =0A> but that could have been t= heir record route paper.=A0 been too long.=0A> sorry.=0A> =0A>> We are new= to IETF and if we should be working with other or=0A>> additional Working= Groups, we are certainly open to that.=0A> =0A> that is generally called '= venue shopping.'=A0 in a culture as small as the=0A> ietf, it is quite noti= ceable and frowned upon.=0A> =0A>> I am curious why you feel 6man would no= t be open to this?=0A> =0A> because ipv6 is perfect, especially the address= model and the header.=0A> lack of usability is the fault of the operators,= vendors, application=0A> developers, users, and the people in the black he= licopters.=0A> < /dripping sarcasm >=0A>=A0=0A=0AOr pragmatically, too much= deployed running code. The only option now available with the fixed IPv6 h= eader fields is to change their meaning in a backward compatible way, simil= ar to how the original ToS field was changed to DSCP in IPv4. Otherwise, an= IPv6 extension header, or it'd have to wait until a future version of IP. From markzzzsmith@yahoo.com.au Sat Feb 2 19:07: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 C249321F84EA for ; Sat, 2 Feb 2013 19:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8Vg3iLlorfP for ; Sat, 2 Feb 2013 19:07:24 -0800 (PST) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with SMTP id 922EB21F84E6 for ; Sat, 2 Feb 2013 19:07:24 -0800 (PST) Received: from [98.139.212.152] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 03:07:24 -0000 Received: from [98.139.212.246] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 03:07:24 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 03 Feb 2013 03:07:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35057.33307.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 1930 invoked by uid 60001); 3 Feb 2013 03:07:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1359860843; bh=AM7AJntAmSNA9fXN1ix9OS16ihqHlgtnUmJQqrEZbRw=; 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=FiHiNhvxCFvBur1MaCPwaFwLEj6vgTYdcu5D/OqfMhQdz6O1PXV85D774QzvHRdEA7/o+94FFeL5bCQ5cQz7JlpcDU7a+aVjNYtlUaUYCLxNC3jXmCj/NwORRCCB8t+wYrj72ThW6XIw+sgeB0qOBWYbYc2rDtep8KA7KEd+vus= 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=VO7dODmzcktY4HK5kcuXnTtG+Lj6XSv85RisUXqT9ZTyvMwQh4mCONVAbDXzwx3APCDEI0NWqYSwnLWWzPbXTy8Gts4BE8VirjdMfbNoSnvzEBclVZCA+Qb5ODsJAAKWCsK7XjI/Y4mdeLElFUzfUQiszQ8eQDxoPwihzimJIrE=; X-YMail-OSG: PLL74REVM1kBVfdWGn1YIFDuUGLPgoCs0B8mod0Z6UPHhbs q_B5SvzRTu9ONSJgg7M9M2yQjFt4jx7LOB2y_MTQ2au0ZYzIZpnQ0gPYxgTF XKhqM7wgRU03xOYqsdM6bCB0gvDJZM7jzeoLf_XygjkvWFA5vHoDROWRFlgl 6XpKrzkFqt3i0tKkhKpUfTwf8NTd7.g8yILMxmHfSAfwfxqx1eaWdyyXVw8a 0eURN0bOogVo_7vKODFkhZdo2hu_0Tomcts8u_jGB5DXKhFVUYdRlm1LU7x. 1RXGdNHWxWbAylOMovzTNBPpJpBLC0S_gZ.SfGBFE0wYlsEIN8wKkWPdLYIp NKNSE5JS__ILVDxb2Ptk4xBKbRpNchDRellMWLw7QZC54rjh1zhcAGyeBdG. pVlXbEoYQz3skMzs.wdkkZ1mJi3zLr9PcMOkyzK2LsjMLv03gv9c.dRN7DaX .EiU_sn_HjgTrckduXCRh9vXH.El9NQcM6QjvZg5fiJejBvKrbungfj4r3WK HzT8Aa9MfE89T07VNC3cqz2RH Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Sat, 02 Feb 2013 19:07:23 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiR3VpbGxhdW1lLkxlY2xhbmNoZUBzd2lzc2NvbS5jb20iIDxHdWlsbGF1bWUuTGVjbGFuY2hlQHN3aXNzY29tLmNvbT4KPiBUbzogY2IubGlzdDZAZ21haWwuY29tCj4gQ2M6IHY2b3BzQGlldGYub3JnOyBkcmFmdC12Nm9wcy12eW5ja2UtYmFsYW5jZWQtaXB2Ni1zZWN1cml0eUB0b29scy5pZXRmLm9yZwo.IFNlbnQ6IFN1bmRheSwgMyBGZWJydWFyeSAyMDEzIDExOjE0IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.131.499 References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> <1BE5D090C6244A49B9815F339F76EA4538305691@SG000708.corproot.net> Message-ID: <1359860843.650.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Sat, 2 Feb 2013 19:07:23 -0800 (PST) From: Mark Smith To: "Guillaume.Leclanche@swisscom.com" , "cb.list6@gmail.com" In-Reply-To: <1BE5D090C6244A49B9815F339F76EA4538305691@SG000708.corproot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 03:07:25 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "Guillaume.Leclanche@swi= sscom.com" =0A> To: cb.list6@gmail.com=0A= > Cc: v6ops@ietf.org; draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.= org=0A> Sent: Sunday, 3 February 2013 11:14 AM=0A> Subject: Re: [v6ops] new= draft: draft-v6ops-vyncke-balanced-ipv6-security=0A> =0A>> De=A0: Cameron= Byrne [mailto:cb.list6@gmail.com]=0A>> Envoy=E9=A0: samedi 2 f=E9vrier 20= 13 19:16=0A> =0A> =0A>> I believe it would be helpful to call out that the= drop rules can be =0A> statelessly=0A>> implemented in the provider netwo= rk while the ratelimiting function is=0A>> stateful and is a better fit fo= r the CPE.=0A>> =0A>> I would also suggest the the term residential be cha= nged to include mobile.=0A>> Perhaps "consumer grade" internet service or = something like that.=0A> =0A> Hi Cameron,=0A> =0A> I understand very well y= our point and I guess your arguments (from a mobile =0A> point of view), bu= t this RFC wants to focus on the CPE features, and we =0A> don't want to ta= lk about ISP filters.=0A=0AWhy not?=0A=0AInternode here in Australia provid= e their customers with a default packet filter on the BRAS/BNG for both IPv= 4 and IPv6. Customers can switch it off via the customer portal if they wan= t to. I can think of a few advantages of doing it there rather than on the = CPE -=0A=0A- it is CPE vendor and model independent, and here in Australia = ISPs don't usually operate the CPE for the customer. This has recently beco= me an option, however ISPs still don't insist you buy their CPE.=0A=0A- Int= ernet usage in Australia is monthly quota based (with traffic policing afte= r the quota is exceeded to avoid bill shock, and associated outrage segment= s on tabloid current affairs shows), and therefore the ISP dropped traffic = doesn't count against the customers' quotas=0A=0A=0AOne general concern I h= ave with this model though is that it doesn't encourage customers to fix th= eir malware infections, because it will usually hide it from them. Over tim= e, within the customer base, there could eventually be a large number of hi= dden infections. If the filtering system fails (e.g. error in applying RADI= US attributes or a faulty filter list update), then the malware would be un= leashed. I don't see how shifting this filtering function to the CPE would = avoid that possibility. I prefer the model where customers who appear to be= infected with malware are quarantined so that they suffer a consequence an= d therefore are taught to take preventative measures.=0A=0A> And regarding = the mobile: nothing prevents the residential CPE uplink to be =0A> mobile, = and with LTE connectivity we'll certainly see that more and more.=0A> =0A> = Guillaume=0A> =0A> _______________________________________________=0A> v6op= s mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /v6ops=0A> From fred@cisco.com Sat Feb 2 19:40: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 255A121F86AB for ; Sat, 2 Feb 2013 19:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.014 X-Spam-Level: X-Spam-Status: No, score=-110.014 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmgDMQ7Jasos for ; Sat, 2 Feb 2013 19:40:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C3D8D21F8534 for ; Sat, 2 Feb 2013 19:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5423; q=dns/txt; s=iport; t=1359862833; x=1361072433; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pTfVDBac6MX0GgDDTilkg75AZSju+dgjqNYqX6l3YG4=; b=aGsTrsFiBGFJhcH5VDhNPTkFzQ5lLYRxWLntXpDV2B2r2fxSVxzQNIxO yD2b6XJPAOrVZ86SrBy0Wg94jcufN/zjzBmebz+Vdghg5haUNNox+xif6 Hddd+jYKShROK11kf/vBV1b9QIC4pldGShqwpsNIn+Xrg8WAIE1ASn4/q g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKDbDVGtJV2a/2dsb2JhbAA/Br8yFnOCHwEBAQMBAQEBawsFBwQCAQgRBAEBAQodBycLFAkIAgQOBQiHdwMJBgzAdgSMHYENDIM7YQOIMIwbjROFEoJ8gW81 X-IronPort-AV: E=Sophos;i="4.84,591,1355097600"; d="scan'208";a="172363467" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 03 Feb 2013 03:40:32 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r133eWIn003874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Feb 2013 03:40:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sat, 2 Feb 2013 21:40:31 -0600 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAcA2+vwCm2kZNEu7LsIO4d+sJg== Date: Sun, 3 Feb 2013 03:40:30 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7677BA@xmb-rcd-x09.cisco.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> <8C48B86A895913448548E6D15DA7553B7673AB@xmb-rcd-x09.cisco.com> <1359857752.49949.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-Reply-To: <1359857752.49949.YahooMailNeo@web142502.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8E5B57D145E1704497046B91A6D92E7B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 03:40:34 -0000 On Feb 2, 2013, at 6:15 PM, Mark Smith wrote: > Hi Fred, >=20 >=20 > ----- Original Message ----- >> From: Fred Baker (fred) >> To: Mark Smith >> Cc: "Ackermann, Michael" ; IETF v6ops list >> Sent: Sunday, 3 February 2013 9:23 AM >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>=20 >>=20 >> On Feb 2, 2013, at 2:03 PM, Mark Smith >> wrote: >>=20 > =20 > >=20 >>> I've had a brief look at your drafts, one thing I'm a bit confused=20 >> about is exactly how the IPID field is used. Part of the reason I ask is= that it=20 >> reads like your draft is saying that the IPID field always has useful va= lues. My=20 >> understanding is that the IPID field only has to have useful values if t= he=20 >> packet is carrying a fragment. Here's what RFC791 says: >>>=20 >>> Identification: 16 bits >>>=20 >>> An identifying value assigned by the sender to aid in assembling t= he >>> fragments of a datagram. >>=20 >> It actually has to go farther than that. >>=20 >> Suppose, just for fun, that the RFC 791 sender is always sending ipid=3D= 0, and=20 >> some router en route is fragmenting every third datagram. If the router = doing=20 >> that leaves lipid alone, they will all appear to be fragments of the sam= e=20 >> datagram. If the router is updating lipid, what should it update lipid t= o? >>=20 >> No, the RFC 791 sender is on the hook to give datagrams within the same = session=20 >> (e.g., having the same source, destination, and protocol number) differi= ng ipid=20 >> values, since it doesn't know whether a router mid-stream will need to=20 >> manipulate the packet. >>=20 >> There are some interesting ramifications that can come into play there. = It is=20 >> legal for an implementation to maintain some kind of counter and simply= =20 >> enumerate the packets it sends, and that is the usual procedure AFAIK. >=20 > I also asked the question because I thought I read somewhere that Linux s= et the ID field to zeros when the packet didn't contain a fragment. My memo= ry is vague, however perhaps that is the case when the DF bit is set on the= packet, so the ID field will never be used to defragment. If DF is set, no router should ever be fragmenting. I could imagine that. > The reason I think I remember this is because it seemed like an unusual o= ptimisation. I'm doing some digging around to see if I can confirm my memor= y is correct or not. >=20 >=20 >> It would=20 >=20 >> also be legal for a UDP application or a TCP/SCTP/DCCP transport to keep= a=20 >> similar counter for the session, as long as it knew that there were no o= ther=20 >> sessions with the same peer. >> =20 >> In IPv6, since only the originator fragments, the whole point is kind of= moot.=20 >=20 >> If the fragment header is there, the id field had bester be written in, = and it=20 >> *is* meaningful. >>=20 >>> Are you artificially setting the value of the IPID field in your test=20 >> traffic, or do you happen to have traffic sources that set the IPID fiel= d value=20 >> regardless of whether the packet contains a fragment or not? >>>=20 >>>=20 >>> Have you considered the IPv6 Flow Label field for your purpose? It migh= t=20 >> suit your requirement. >>>=20 >>>=20 >>> Regards, >>> Mark. >>>=20 >>>> Thanks again! >>>>=20 >>>> Mike >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf= =20 >> Of Randy=20 >>>> Bush >>>> Sent: Saturday, February 02, 2013 11:22 AM >>>> To: Fred Baker >>>> Cc: IETF v6ops list >>>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>>>=20 >>>> a strange document, a plea for ipid in v6. i kinda like[d] ipid and w= e=20 >> did some=20 >>>> reasearch measurements on it. actually, i think we are still=20 >> collecting and=20 >>>> have some years of longitudinal data. >>>>=20 >>>> but i would think that this document would be in 6man, where putting=20 >> ipid in the=20 >>>> v6 header does not have a snowball's chance in hell. >>>>=20 >>>> randy >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>>=20 >>>> The information contained in this communication is highly confidential= =20 >> and is=20 >>>> intended solely for the use of the individual(s) to whom this=20 >> communication is=20 >>>> directed. If you are not the intended recipient, you are hereby=20 >> notified that=20 >>>> any viewing, copying, disclosure or distribution of this information i= s=20 >>=20 >>>> prohibited. Please notify the sender, by electronic mail or telephone,= =20 >> of any=20 >>>> unintended receipt and delete the original message without making any= =20 >> copies. >>>>=20 >>>> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan=20 >> are=20 >>>> nonprofit corporations and independent licensees of the Blue Cross and= =20 >> Blue=20 >>>> Shield Association. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>=20 From joelja@bogus.com Sat Feb 2 23:33: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 3BA8A21F88C7 for ; Sat, 2 Feb 2013 23:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.414 X-Spam-Level: X-Spam-Status: No, score=-101.414 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfS2tJNZJOsj for ; Sat, 2 Feb 2013 23:33:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 31ACF21F87ED for ; Sat, 2 Feb 2013 23:33:27 -0800 (PST) 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 r137XGOe037738 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 3 Feb 2013 07:33:16 GMT (envelope-from joelja@bogus.com) Message-ID: <510E12B7.4070106@bogus.com> Date: Sat, 02 Feb 2013 23:33:11 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter , Ronald Bonica References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510CCA4D.7010508@gmail.com> In-Reply-To: <510CCA4D.7010508@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Feb 2013 07:33:20 +0000 (UTC) Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sun, 03 Feb 2013 07:33:28 -0000 On 2/2/13 12:11 AM, Brian E Carpenter wrote: > On 01/02/2013 22:40, Ronald Bonica wrote: >> Folks, >> >> It appears that we have a procedural problem. So, let's do the following: >> >> - I ask the chairs to initiate a one week WG last call. The last call will be restricted to a discussion of whether this document should be published considering its IPR. >> - If the WG concludes that the document should not be published, I will ask the IESG to rescind its approval of the draft >> - If the draft reaches AUTH48 before the one week last call terminates, I will delay publication until the last call has yielded a formal conclusion >> >> Now, for a little background regarding how we got to this point. As Joel points out, the IPR was disclosed well before the WG Last Call. It was also mentioned in the shepherd's write-up. When the document went to IESG review, the IESG questioned whether the WG had considered the IPR. So, I posted the message at http://www.ietf.org/mail-archive/web/v6ops/current/msg14886.html. >> >> Discussion ensued, with some folks saying that the draft should be published and others saying that it should not. On Wednesday, I asked the chairs for a consensus call. Their sense of the mailing list was that there was consensus to publish. So, I cleared my DISCUSS and approved the document. > afaik that consensus call was not copied to the list. That was perhaps unfortunate. It was literally a call, as in voice. > > On 01/02/2013 23:00, Fred Baker (fred) wrote: > >> On Feb 1, 2013, at 12:08 AM, Brian E Carpenter wrote: >> >>>> IMHO a WG Chair needs to make a formal call on the IPR question PDQ, >>>> and if necessary, urgently request the IESG to rescind its approval. >>>> I hope it isn't necessary, but it isn't my place to make the call. >> We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China Mobile on 464XLAT. > My opinion is that the IPR claim is no more worrisome than many others the IETF > has chosen to live with, so the document should proceed as a BCP. The claim > is on record for any implementor to consider, regardless of the status of > the document. > > Brian > From joelja@bogus.com Sun Feb 3 00:15: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 467CB21F8445 for ; Sun, 3 Feb 2013 00:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwxvsRrdrRzF for ; Sun, 3 Feb 2013 00:15:10 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C8DAB21F847C for ; Sun, 3 Feb 2013 00:15:10 -0800 (PST) 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 r138F7IG038205 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 3 Feb 2013 08:15:08 GMT (envelope-from joelja@bogus.com) Message-ID: <510E1C86.5040608@bogus.com> Date: Sun, 03 Feb 2013 00:15:02 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Mark Smith , Michael Ackermann References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359859722.80871.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1359859722.80871.YahooMailNeo@web142503.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Feb 2013 08:15:09 +0000 (UTC) Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 08:15:11 -0000 On 2/2/13 6:48 PM, Mark Smith wrote: > > > > ----- Original Message ----- >> From: Randy Bush >> To: Michael Ackermann >> Cc: IETF v6ops list >> Sent: Sunday, 3 February 2013 1:21 PM >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >> >>> Thanks for the comments Randy. We would be interested in your >>> measurements and any other related info/thoughts/insights you may >>> have! >> what is left of my memory is that the first paper on using ipid was >> >> "Touring the internet in a TCP sidecar" Rob Sherwood & Neil >> Spring >> IMC 2006 Proceedings of the 6th ACM SIGCOMM conference on Internet >> measurement >> >> but that could have been their record route paper. been too long. >> sorry. >> >>> We are new to IETF and if we should be working with other or >>> additional Working Groups, we are certainly open to that. >> that is generally called 'venue shopping.' in a culture as small as the >> ietf, it is quite noticeable and frowned upon. >> >>> I am curious why you feel 6man would not be open to this? >> because ipv6 is perfect, especially the address model and the header. >> lack of usability is the fault of the operators, vendors, application >> developers, users, and the people in the black helicopters. >> < /dripping sarcasm > >> > Or pragmatically, too much deployed running code. The only option now available with the fixed IPv6 header fields is to change their meaning in a backward compatible way, similar to how the original ToS field was changed to DSCP in IPv4. Otherwise, an IPv6 extension header, or it'd have to wait until a future version of IP. It's probably not reasonable to expect intermediate hops on a network to look at extension headers, except for hop by hop, options they're not supposed to anyway. it's hard enough to find the upper layer header when you need it if there are extension headers or fragmentation that starts to get messy.. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sun Feb 3 00:51: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 AC3D621F8464 for ; Sun, 3 Feb 2013 00:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.758 X-Spam-Level: X-Spam-Status: No, score=-99.758 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O7MmWhYUy1h for ; Sun, 3 Feb 2013 00:51:54 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D03721F8440 for ; Sun, 3 Feb 2013 00:51:53 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so4011146wey.33 for ; Sun, 03 Feb 2013 00:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1z8es7/goj+FxamGX3XcZR6vddq4tQNSXrAg2pD/H/Q=; b=oc7pH+PsRLY9Y7W0LSHGewcBDcSff0F0mQadcEvh5RJ7yFVDQL4QimfmW6YticZds6 jsyAP+Af/OjE9MP9X/We7VHyyCExR5rdhXWVnZaA9fUVo7AmbzpOHqMdLfanUuoFjsNy aB+DomwOAIsu+aLugK978AwZtGzPTOLKUvdepEUW9FyNawKsd4KECb+YzMU5btK2fgCg gVy3amODgjJFwaIXkAwqAFrZ8jd9QqKWzjSdUqdqZr/0lsst0Y/fgFtKcN3LrFt7zFRT PjEN2ANBrbeuLBxrkNW6f9lAojSDg5wCPGrF6hQ1Ym0MJD8KMkg5iotplX2yFhGiIgNP QWJA== X-Received: by 10.181.13.195 with SMTP id fa3mr5109465wid.8.1359881513090; Sun, 03 Feb 2013 00:51:53 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-151.as13285.net. [2.102.218.151]) by mx.google.com with ESMTPS id fx5sm14346543wib.11.2013.02.03.00.51.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 00:51:52 -0800 (PST) Message-ID: <510E2527.1060605@gmail.com> Date: Sun, 03 Feb 2013 08:51:51 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <1359842623.14958.YahooMailNeo@web142503.mail.bf1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A0DDD95@PWN401EA160.ent.corp.bcbsm.com> <8C060383-65C6-4FA9-AEDA-C76684AB47E2@delong.com> In-Reply-To: <8C060383-65C6-4FA9-AEDA-C76684AB47E2@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 08:51:54 -0000 On 03/02/2013 00:33, Owen DeLong wrote: > It seems to me that in most of the situations you described, the flow label could be used > as a valid substitute. I don't see how. By definition, the flow label is identical for all packets of a given flow. Therefore, it doesn't distinguish packets such as split or duplicated packets. However, the authors might look at RFC 6437 carefully to see if it helps. Brian From warren@kumari.net Sun Feb 3 05:34: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 48E9C21F86CA for ; Sun, 3 Feb 2013 05:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFznfajlz-Bt for ; Sun, 3 Feb 2013 05:34:04 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9671121F86C1 for ; Sun, 3 Feb 2013 05:34:04 -0800 (PST) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id 6E6021B40706; Sun, 3 Feb 2013 08:34:03 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> Date: Sun, 3 Feb 2013 08:34:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1499) Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 13:34:05 -0000 On Feb 2, 2013, at 11:37 AM, "Ackermann, Michael" = wrote: > Thanks for the comments Randy. We would be interested in your = measurements and any other related info/thoughts/insights you may have! >=20 > We are new to IETF and if we should be working with other or = additional Working Groups, we are certainly open to that. =20 >=20 > I am curious why you feel 6man would not be open to this? =20 You may want to (re)read:=20 http://www.ietf.org/mail-archive/web/v6ops/current/msg10260.html I suspect almost exactly the same arguments will be made=85 W >=20 > Thanks again! >=20 > Mike >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Randy Bush > Sent: Saturday, February 02, 2013 11:22 AM > To: Fred Baker > Cc: IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > a strange document, a plea for ipid in v6. i kinda like[d] ipid and = we did some reasearch measurements on it. actually, i think we are = still collecting and have some years of longitudinal data. >=20 > but i would think that this document would be in 6man, where putting = ipid in the v6 header does not have a snowball's chance in hell. >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- Credo quia absurdum est. From Ted.Lemon@nominum.com Sun Feb 3 07:07: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 AF52221F8468 for ; Sun, 3 Feb 2013 07:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIxxdqZ3gyeb for ; Sun, 3 Feb 2013 07:07:17 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 232FF21F845A for ; Sun, 3 Feb 2013 07:07:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ59JEH1CpPBmPHXJRHv/X2sJ+925HXe@postini.com; Sun, 03 Feb 2013 07:07:17 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ABB381080A3 for ; Sun, 3 Feb 2013 07:07:16 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8E461190043; Sun, 3 Feb 2013 07:07:16 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 07:07:16 -0800 From: Ted Lemon To: joel jaeggli Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOARz5MPAQd9auikmkNZsIVpRjiphoRVKAgAB+3AA= Date: Sun, 3 Feb 2013 15:07:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747BB67@mbx-01.win.nominum.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510CCA4D.7010508@gmail.com> <510E12B7.4070106@bogus.com> In-Reply-To: <510E12B7.4070106@bogus.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: <5A3E0DBB20ADA04380A995BAD23DC040@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Sun, 03 Feb 2013 15:07:17 -0000 On Feb 3, 2013, at 2:33 AM, joel jaeggli wrote: > It was literally a call, as in voice. Aren't consensus calls in meetings supposed to be repeated on the mailing l= ist? From alexandru.petrescu@gmail.com Sun Feb 3 08:07: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 3219721F84C6 for ; Sun, 3 Feb 2013 08:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.934 X-Spam-Level: *** X-Spam-Status: No, score=3.934 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBJQUYJnthih for ; Sun, 3 Feb 2013 08:07:47 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 1D02B21F8472 for ; Sun, 3 Feb 2013 08:07:45 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id A5D2D9400F3 for ; Sun, 3 Feb 2013 17:07:39 +0100 (CET) Message-ID: <510E8B47.7020401@gmail.com> Date: Sun, 03 Feb 2013 17:07:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130129190051.26798.90046.idtracker@ietfa.amsl.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33D1C@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA33D1C@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130203-0, 03/02/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-01.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: Sun, 03 Feb 2013 16:07:48 -0000 Le 01/02/2013 22:47, Vízdal Ale¹ a écrit : > Hi, > > thanks for the update. Please find some comments below. > > 3.1 Scenario 1: No Global Address on the UE > > After the initial configuration using RS/RA the 3GPP network still > may be sending the RAs as the 3GPP TS 29.061, 11.2.1.3.4 says that > > "MaxRtrAdvInterval shall have a default value of 21 600 s (6 h) and > MinRtrAdvInterval shall have a default value of 0,75 × > MaxRtrAdvInterval i.e.16 200 s (4,5 h)." > > So, it shall be mentioned that the SLAAC feature shall be disabled > on the 3GPP interface to avoid this interface to be self auto > configured with a GUA resulting in the same /64 bound to both 3GPP > and LAN interfaces. I agree with this suggestion. In addition, this should be strengthened by the fact that once the wlan interface is up and the forwarding is set, this becomes a Router. As far as I remember specifications, a Router does not do interpret the received RAs (not for SLAAC nor for any other parameter interpretation, like MTU) on any of its interfaces. > 3.2 Scenario 2: Global Address Only Assigned to LAN > > In case of Privacy Extensions will be enabled on the 3GPP interface, > shall it be mentioned that each address from a given prefix shall be > moved or is it obvious? I don't think it is obvious. In our setting the privacy address is there but we simply didn't think about moving it. > 4. Security Considerations > > Since Scenario 3 does not allow for Privacy Extension to run the > 3GPP interface, UEs that require this functionality must find an > alternative method. > > Given that the Privacy Extensions will be disabled on the 3GPP > interface, can we propose to use Privacy Extensions on LAN interface > to fix the issue above? Sounds as a good idea. In this way one offers privacy for applications running on a cellular-enabled Router which has extended the /64 beyond its cellular interface. I think it makes sense. But I think it is also worth formulating this first in terms of a need for Privacy - i.e. make sure that 64share does not eliminate Privacy. Alex > > Cheers, Ales > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org Sent: Tuesday, January 29, 2013 8:01 PM To: >> i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D >> Action: draft-ietf-v6ops-64share-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Operations >> Working Group of the IETF. >> >> Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile >> Interface to a LAN Author(s) : Cameron Byrne Dan Drown >> Filename : draft-ietf-v6ops-64share-01.txt Pages >> : 8 Date : 2013-01-29 >> >> Abstract: This document describes three methods for extending an >> IPv6 /64 prefix from a User Equipment 3GPP radio interface to a >> LAN. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-64share-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Sun Feb 3 08:26:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708DC21F8555 for ; Sun, 3 Feb 2013 08:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.784 X-Spam-Level: ** X-Spam-Status: No, score=2.784 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwcfKVe7Kmub for ; Sun, 3 Feb 2013 08:26:34 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E70B921F8200 for ; Sun, 3 Feb 2013 08:26:32 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D38D0940153; Sun, 3 Feb 2013 17:26:26 +0100 (CET) Message-ID: <510E8FAE.4080104@gmail.com> Date: Sun, 03 Feb 2013 17:26:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <510A75DA.60305@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33B6E@SRVHKE02.rdm.cz> <510BFCBA.6060100@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33D0C@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA33D0C@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130203-0, 03/02/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Sun, 03 Feb 2013 16:26:35 -0000 Le 01/02/2013 20:26, Vízdal Ale¹ a écrit : >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, February 01, >> 2013 6:35 PM To: Vízdal Ale¹ Cc: v6ops@ietf.org Subject: Re: >> [v6ops] Test for adoption as a working group document - Re: I-D >> Action: draft-binet-v6ops-cellular-host-requirements-02.txt >> >> Le 01/02/2013 12:07, Vízdal Ale¹ a écrit : >>>> -----Original Message----- From: v6ops-bounces@ietf.org >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru >>>> Petrescu Sent: Thursday, January 31, 2013 2:47 PM To: >>>> v6ops@ietf.org Subject: Re: [v6ops] Test for adoption as a >>>> working group document - Re: I-D Action: >>>> draft-binet-v6ops-cellular-host-requirements-02.txt >>>> >>>> HEllo, >>>> >>>> This draft had a competitor in the same space IIRC? What was >>>> the name of that draft? >>> >>> You're talking about draft-ietf-v6ops-rfc3316bis-00. These drafts >>> are not competing as each of them has a different goal. >> >> I don't understand? >> >> The abstract of one says: "This document lists a set of >> IPv6-related requirements to be supported by cellular hosts." >> >> and the abstract of the other includes: "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)." > > Section 1.1 provides the following explanation > > This document lists the required features while > [I-D.ietf-v6ops-rfc3316bis] is doing a good job in identifying > issues and explaining how to implement basic IPv6 features in a > mobile context. Some of the features discussed in > [I-D.ietf-v6ops-rfc3316bis] are also listed in this document as a > requirement: the main reason is to collect in one single document a > comprehensive list of requirements with the required language. Thanks for pointing to that text. I need to better understand it. But I doubt [I-D.ietf-v6ops-rfc3316bis] is _not_ trying to also have a comprehensive list of requirements. I have some comments about this comprehensive list of requirements and I would like to post them here in the v6ops list. But not sure on which draft will they go. >> As an example which makes me think they compete, in the running >> text one draft says 'should' Prefix Exclude Option (of PD) and the >> other says MUST for the same. Both these recommendations are for >> cellular-enabled Hosts, right? >> >>>> In this draft, there is a section about which I have high >>>> interest - "4. Cellular Devices with LAN Capabilities". This >>>> approaches very much to what an IPv6 Mobile Router is, whose >>>> one particular interface is cellular and others are LAN. >>>> >>>> In this respect, implementing an IPv6 Mobile Router there are >>>> several possibilities and each may have an impact on that >>>> cellular interface. >>>> >>>> For example, the use of Prefix Delegation has an impact on the >>>> cellular interface - and that is already said as REQ#27. >>> >>>> But there are others. For example, the use of IPv6 Network >>>> Prefix Translation, or, not least, the use of Mobile IPv6 (with >>>> NEMO extensions if possible). This latter is all the more >>>> important since it is mentioned in the IPv6 Node Requirements >>>> document, and this draft also mentions that in addition to the >>>> cellular interface there is a WiFi interface - only Mobile IPv6 >>>> is able to make handovers between the two interfaces. >>> >>> It's a scope question. Can you please review the draft and >>> provide us with your comments? >> >> Yes, in section "4. Cellular Devices with LAN Capabilities" lists >> a number of requirements for Cellular Devices with LAN >> Capabilities. Some of these requirements request that that >> cellular-enabled device uses DHCP Prefix Delegation in order to >> obtain a Prefix for the LAN. >> >> But there exist other methods to achieve the same effect as >> assigning a Prefix on the LAN from DHCP-PD: Network Prefix >> Translation, and Prefix Delegation with Network Mobility. >> >> My comment is - why aren't these mentioned in the list of >> requirements? > > There has been no demand for anything else than DHCP-PD so far. Ok, I didn't know that. Running DHCP-PD on the real interface is one way of obtaining addresses for the LAN interface. One other is to run DHCP-PD on a virtual tunnel, whose other end is the Home Agent of (Mobile IP). This way is specified in RFC6276 "DHCPv6 Prefix Delegation for Network Mobility (NEMO)". This requires the use of protocol Mobile IP. The protocol Mobile IP is necessary when this Router has an additional egress WiFi interface (in addition to the ingress LAN WiFi interface). For the same problem (make addresses for devices on the LAN interface), instead of using DHCP-PD, one may use NPTv6 "Network Prefix Translation" RFC6296. Alex > >> Regards, >> >> Alex >> >>> >>>> Regards, >>>> >>>> Alex >>> >>> Ales > > Ales > From alexandru.petrescu@gmail.com Sun Feb 3 10:04:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA49521F8689 for ; Sun, 3 Feb 2013 10:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.759 X-Spam-Level: * X-Spam-Status: No, score=1.759 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxNsc31dMrYZ for ; Sun, 3 Feb 2013 10:04:43 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8582A21F892C for ; Sun, 3 Feb 2013 10:04:40 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 42F3294017E for ; Sun, 3 Feb 2013 19:04:35 +0100 (CET) Message-ID: <510EA6B1.2040006@gmail.com> Date: Sun, 03 Feb 2013 19:04:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130203-0, 03/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [v6ops] Cellular Host - a misnomer? draft-binet-v6ops-cellular-host-requirements-02.txt and draft-ietf-v6ops-rfc3316bis-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, 03 Feb 2013 18:04:43 -0000 Please let me allow a generic comment about draft-binet-v6ops-cellular-host-requirements-02.txt "IPv6 Requirements for Cellular Hosts" and about draft-ietf-v6ops-rfc3316bis-00 "IPv6 for 3GPP Cellular Hosts" In short, I think the term Cellular Host is a reductionist, conflict-generating misnomer, of what is described in the documents. To avoid this, and to clarify, I tend to suggest to avoid 'cellular host' to profit a Host-IMP-Router kind of definition. And put the relevant requirements specific on these parts - either on the Host or on the IMP or on the Router. In detail, my reading is that although one of the documents tries to clarify this (draft-ietf calls a cellular host a host with a cellular interface) the spirit of what seems to be described in both documents is a smartphone, or a 'mobile device' (draft-ietf puts reqs only on cellular hosts, not on interfaces). And this smartphone view has some problems. 1. One problem I struggle with, and exposed in some public discussions, is that the 64share technique is able to work only when certain requirements of the 3GPP Gateway and the USB cellular interface satisfy. E.g. that neither the 3GPP Gateway, nor the USB cellular interface, MUST not send NS for any address in the announced /64 range. IF any of these two happens, the 64share method won't work. In practice we identified that this happens with a particular combination of network operator and bran dof USB LTE key. We need to avoid that situation in order for 64share to work. We need to put requirements on the 3GPP Gateway (do not send NS) and on the USB cellular interface (do not send NS, nor pretend or fake NSs). If not a requirement, then maybe a statement that declares that if either the Gateway or the USB interface sends an NS then the 64share won't work. But where could we express that requirement/statement? It is not a requirement for the Cellular Host per se. 2. Typically a Host has a single interface. When that interface is Cellular and runs IP, the Host actually has more than just a cellular interface. E.g. a typical smartphone. That "cellular host" is also a "WiFi STA" at the same time, or a "bluetooth node". And at times it becomes a Router with e.g. 64share. It is very hard to put IP Requirements entirely on the Cellular Host when what we want is only requirements on the Cellular interface part. A Host with multiple interface is dealt with in MIF WG. There they're also seen as mostly the 'mobile device' or the 'smartphone'. It has some RFC and active WG I-Ds which pertain to this discussion (DNS server selection, DHCP route option, to name a few). These techniques should be integrated here, I think. 3. Maybe the only Cellular Hosts (i.e. a Host running IP and having a single interface which is cellular) is represented by some of smallest autonomous M2M Modules. E.g. sierra wireless M2M modules. And surprisingly these 'pure' Cellular Hosts are put out of scope by draft-binet-v6ops-cellular-host-requirements-02. But these may be the only devices which may be qualified as 'pure' cellular hosts. 4. The USB keys which are cellular interfaces and made to be plugged on laptops obviously would not qualify as Cellular Hosts. Although their CPU/MEM is relatively powerful enough to run IP, they're not autonomous - they're the 'IMP' of a Host. Other examples of this problem follow. Example: REQ#10 of draft-binet says "The cellular host SHOULD embed a DHCPv6 client". But should this be implemented in the USB key? Or in the Host whose cellular interface is it? Example: REQ#12 of draft-binet says "REQ#12: The cellular host SHOULD implement the Customer Side Translator function". But if I use a big Mobile Router whose one single interface cellular (the others are wifi, bluetooth, .15.4, .11p, RS232 SLIP, USBnet - nothing to do about Customer Side) - should it still implement Customer Side Translator function? Other examples: > The DNS server configuration is learned from 3GPP link layer > signaling. However, the cellular host should also implement the IPv6 > Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6 > is still optional for cellular hosts, and learning the DNS server > addresses from the link layer signaling can be cumbersome when the MT > and the TE are separated using other techniques than PPP interface. But we know that if that cellular Host is a router with a cellular interface then it should use _only_ DHCP to obtain the DNS address. It can't use RA for that because it's a Router. > For the purposes of this document, IP mobility is not relevant. The IP mobility (aka Mobile IP protocol) is irrelevant only for the 'pure' cellular hosts, i.e. these M2M cellular-only devices. All the other cellular-enabled devices may need Mobile IP. > The movement of cellular hosts within 3GPP networks is handled by > link layer mechanisms in majority of cases. YEs, I agree mobility in 3GPP is handled by link layer mechanisms. Often the term GTP comes up and could be mentioned. But it is not the reason why cellular-enabled Hosts don't run Mobile IP. It is because a majority of their sessions are such that they can be handed over from iface to another without needing continuous sessions (e.g. bursty http transactions are probably the most used app on smartphones). These hosts are multiply-ifaced Hosts which is ok and deserves mentioning. > 3GPP Release-8 introduced the dual-stack Mobile IPv6 (DSMIPv6) for a > client based mobility [RFC5555]. Client based IP mobility is > optional in 3GPP architecture. I think 3GPP should be notified about a number of shortcomings of RFC5555 (compared to the simultaneous use of MIP4 and MIP6). I think it is not right to invoke 3GPP documents here when many oppinions expressed at IETF are that RFC5555 has probably several competitors. For example, 3GPP documents could mention Mobile IPv4 simultaneous with Mobile IPv6 to achieve mobility, optionally. > o The host can be a "closed" device with optimized applications, > with no possibility to add or download applications that can have IP > communications. An example of such a host is a very simple form of > a mobile phone. Sorry - which is that device? Qualifying them as 'open' or 'close' without saying with respect to whom is not clear. A very simple form of a mobile phone? The smallest Mobile Phone (e.g. simvalley) is not running IP. And, the simplest form of an M2M autonomous cellular device is not a phone either. > o The host can be an open device, e.g., a "smart phone" where it is > possible to download applications to expand the functionality of the > device. A smartphone is more than just being open. It is a complete platform which most if not all times has more than a cellular interface (it has cellular and wifi/bluetooth). Is this a cellular Host? I doubt. It is a MIF host. > o The cellular radio modem part can be separated from the host IP > stack with an interface. On example of such host is a laptop > computer that uses a USB cellular modem for the cellular access. I agree. But there seem to be cases where that separation is not so clearcut. Some USB cellular modem interfaces appear to be generating IP messages. The requirements in this document apply to the radio modem? Or to the USB HOST (Host has double meaning when we talk USB and IP at the same time). > If a cellular host has additional interfaces on which IP is used, > (such as Ethernet, WLAN, Bluetooth, etc.) then there may be > additional requirements for the device, beyond what is discussed in > this document. Should these requirements converge? Regards, Alex From fredbakersba@gmail.com Sun Feb 3 13:21: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 59DEC21F884A for ; Sun, 3 Feb 2013 13:21:50 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W00hidUVVWH for ; Sun, 3 Feb 2013 13:21:49 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id DE4A521F854B for ; Sun, 3 Feb 2013 13:21:49 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id wz17so2859303pbc.1 for ; Sun, 03 Feb 2013 13:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=6ES+fd7MEw/UuaEvO7WwdEpdB6AWGAMFUfEYaSfv8TY=; b=JaY3By0Ixl3Ug1iZzC028V85DWRTKsIPezFeAcu4D8PYlG4JZuRruh9+rgc0XDNlzX 6SeXRdv/hwIdTBH1TZ6coZPUFnmUhUwASxsyrKsUoTkGEGmOg63RpzDqtMlg/xgNZxzb f4nylkOxOnmha3nJfSRuj6sdDoIJ/a/jhlXCrUoYI6xYDo3+WJ+DBS9LUOD1Szh88LMg NOtRlwEGrQ/N7YrzvgfhfmZK49c2T525fFO6sTvSYxjStc4tp8vgOvb6+nd18hhRJhaa Mtre+XEo1GZQaXuc/FwuZxV8hJfCrq+E0MuX3fHaOigYTTnz2938qgbHEuOeXxZ+lJRj Zcig== X-Received: by 10.68.197.135 with SMTP id iu7mr49437745pbc.71.1359926509546; Sun, 03 Feb 2013 13:21:49 -0800 (PST) Received: from sjc-fred-8818.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id hs2sm15651252pbc.22.2013.02.03.13.21.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 13:21:48 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Feb 2013 11:00:02 -0800 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sun, 03 Feb 2013 14:02:52 -0800 Cc: Ron Bonica Subject: [v6ops] draft-ietf-v6ops-nat64-experience 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, 03 Feb 2013 21:21:50 -0000 This is to initiate a two week working group last call of = http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience. 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 cb.list6@gmail.com Sun Feb 3 17:37: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 76DAC21F845F for ; Sun, 3 Feb 2013 17:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdj64ujmKFXf for ; Sun, 3 Feb 2013 17:37:54 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7D40821F8481 for ; Sun, 3 Feb 2013 17:37:54 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id ge1so6251826lbb.1 for ; Sun, 03 Feb 2013 17:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=96wk1R1VdUCaTby5+vUeinafBeM+41nMycVA216pJa8=; b=lajyBHwnW+zzJVj0U3ywCf8GJ+k0XigrbOMy+VLIK3phYmhV05H5yuWk61BesNFU3m UBTuHCCr7jyxw1FJ1Ln9NxZJ13QYHdVx1VNcV0uG6Dx9fqSkxvHnOwsY2LlnW7aJmZXU JQMm5EiypzXqW/IXKRBh0XQF0ms3eV8ey2f/Nu3l4BVNpufx8k8cHuU/GY1PiKpD1fZr y/ak2SXhypBPiEV6ui4Xasmf0ZY77s5Mgr2Vi/HUdZ9QV6rafLj9OKfkfGVvFE4EMyR5 FkiLaqffw0q/rGXrq0BQUsjk9DitTqe0/cvlVF7nnC1ZULtFcuUQw8hLaGPx4fIxx25i qp+w== MIME-Version: 1.0 X-Received: by 10.152.144.130 with SMTP id sm2mr17668864lab.49.1359941873465; Sun, 03 Feb 2013 17:37:53 -0800 (PST) Received: by 10.112.7.165 with HTTP; Sun, 3 Feb 2013 17:37:53 -0800 (PST) Date: Sun, 3 Feb 2013 17:37:53 -0800 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 01:37:55 -0000 Since a lot of folks talk about IPv6 in mobile, i figured i would pen my own view and experience here. It hopefully will set some context for the WG work products draft-ietf-v6ops-464xlat, draft-ietf-v6ops-64share, draft-binet-v6ops-cellular-host-requirements. Please do note 464XLAT is not 3GPP/mobile specific. AFAIK, there is exactly 1 provider in the world of 3GPP that offers dual-stack service by default, Verizon Wireless (hat tip). I did not count, but there is probably more that 50 LTE networks out there today http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be some others that support default-on dual-stack, i but i don't know of them. So, conclusion #1 is that that LTE does not require or even help IPv6 deployment. Look at the facts. There is a long list of LTE networks that definitely do not have IPv6 or dual-stack by default: AT&T, Sprint, EE, T-Mobile DE, Rogers, Vodafone, .. I believe a lot of folks, myself included, thought network upgrades would bring about more IPv6 features and deployment. In my own experience, this is the exact opposite in reality. Let me explain. There are 4 major providers of 3GPP equipment. I will exonerate Huawei since i don't know anything about them and Cisco because i know there stuff works (AFAIK). The other 2 providers are specifically defunct on the IPv4v6 front. One -- has a brand new high capacity P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6). And the other, which is painfully wrecking my IPv4v6 deployment plans, has a newish (few years old now) high capacity SGSN which does not support IPv4v6 (also supports v4 or v6). Witness, new gear does not result in v4v6 (dual-stack). In fact, the legacy SGSN that i had from the same vendor does support v4v6, but it is now end of life (at least as far as my network)! It is just the new one that does not have dual-stack support. Thought i would just share, and dispel any misconceptions folks had about 3GPP / LTE networks and IPv6, especially about dual-stack. There is nothing wrong with the 3GPP specs, and i know the network operators are asking but not getting the features ... That said, draft-ietf-v6ops-464xlat and draft-ietf-v6ops-64share are both hacks that try to route around the brokeness of economics, NAT444s, vendors that don't ship 4+ year old 3GPP defined mandatory features (IPv4v6 LTE bearers), and IPV4-only apps like Skype. CB From ek@google.com Sun Feb 3 22:20: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 5134121F841C for ; Sun, 3 Feb 2013 22:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGQ5xyy0M6Uf for ; Sun, 3 Feb 2013 22:20:41 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9639C21F841B for ; Sun, 3 Feb 2013 22:20:41 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so6008800obb.17 for ; Sun, 03 Feb 2013 22:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=6QqspeWUl4xcP5egJ7Dn/GCNEjH3CuT19O+qOQffF/k=; b=d6cdiqpxvLGQYi5qtuLLC5wwvLV4XHFwtDH/K3t/FGAb4NQS1kyJxT7nfxAWnkTAZN qafPQZZAGq4WcQsmR7vr4IiJ2BlQCKmBQRd+aR9hp8t63FLDUdPuKQspR7uk3C1UTERA +qsiLgWC2UoAR8eeDN2D/BAJ7nWz09AnrbrBpAwK+4ch5+kU+vnxFBfgXZddd/lZHSVz tDt0bGmrmvSd0rm0A1Zk8AvUBtNAGhMMB/JKoqZTZgYATFpSZ2NXvSiJ6u54hD8wij0R ZcFjtyAh7DopoghTWBEy8IXmwEyfEWb7bC3cOoWHKjYQ4Fs/ynnK2AbHuA9GCGUmUClV a7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=6QqspeWUl4xcP5egJ7Dn/GCNEjH3CuT19O+qOQffF/k=; b=fQ5PlEvByOXVjV8xsmcFFoSSBrZxO/hyAv17o+qPEO7Q8HTjO528bRl3TGcrOiQmwr 3LU3R811doC3VnWFnyLVcywOAfUQYN/DMZpz93CUiHngSkmM0Fy7DeR3wxVAlxhSod// oJFAWjYTJi/82omkppOBwgW+QFZeQ/GQJzv61gfOFp6sgCTBkmqeRliJnTZHoUWk8XdI jKM0cSajxaQZewVHwONDB00TyRjT3tkxGzYfk6sxmdcU0y3auyiU2dgGu7Snu9kEKsja LS3cF4GRWcJ4T8nKpK8XTrhSgCQpcRM3Tjxyiwm0t+28tlYJs1ICyJh/mNFabo7ltExD cK0Q== X-Received: by 10.60.19.37 with SMTP id b5mr1149115oee.128.1359958840936; Sun, 03 Feb 2013 22:20:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.50.227 with HTTP; Sun, 3 Feb 2013 22:20:20 -0800 (PST) In-Reply-To: <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> From: Erik Kline Date: Mon, 4 Feb 2013 15:20:20 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmV7kdwXf7ECNzlHjQXNSG/RN3P9JFyMLAyAAJLOUp5SGZud9h9HUzwNP3jGmK3bVpiP/GfkuBxdeOp7LP3sbT9Wh98lw/IqJYjXRwOay1D/UJSvNuMnhZXX0WnOpiXdC6xjiCiJ3EDr/E1og8maTQRoJFXAL4/PW27wXSRT3g9g10pd28j/uGnwXltwO3yPG03bbWD Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 06:20:42 -0000 > There is a part of me that would be very happy for the working group to > decide it didn't want to publish the draft at all, and to state that the > reason is an IPR declaration that looks essentially vacuous and has been > neither explained nor substantiated by China Mobile. But that's just me. I could definitely agree with this. At the very least I would not be in favor of any standards-level status above {experimental,informational}. From simon.perreault@viagenie.ca Mon Feb 4 01:30: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 F243221F8651 for ; Mon, 4 Feb 2013 01:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUaMLhwAPGYm for ; Mon, 4 Feb 2013 01:30:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 870C121F863F for ; Mon, 4 Feb 2013 01:30:02 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D2E0440425 for ; Mon, 4 Feb 2013 04:30:01 -0500 (EST) Message-ID: <510F7FCC.5040705@viagenie.ca> Date: Mon, 04 Feb 2013 10:30:52 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 09:30:03 -0000 Le 2013-02-04 02:37, Cameron Byrne a écrit : > The other 2 providers are specifically defunct on the IPv4v6 front. > One -- has a brand new high capacity P-GW/GGSN which does not support > IPv4v6 (it supports v4 or v6). And the other, which is painfully > wrecking my IPv4v6 deployment plans, has a newish (few years old now) > high capacity SGSN which does not support IPv4v6 (also supports v4 or > v6). Witness, new gear does not result in v4v6 (dual-stack). In > fact, the legacy SGSN that i had from the same vendor does support > v4v6, but it is now end of life (at least as far as my network)! It > is just the new one that does not have dual-stack support. Curious... Why is this happening? Is it malice or incompetence? Or some other reason? I'm not expecting perfect answers on a public list, but it might still be interesting... Simon From etmetz@gmail.com Mon Feb 4 01:34: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 2329421F863F for ; Mon, 4 Feb 2013 01:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epCU2S9iKXTR for ; Mon, 4 Feb 2013 01:34:57 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 876F421F8635 for ; Mon, 4 Feb 2013 01:34:57 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id l10so6345295oag.30 for ; Mon, 04 Feb 2013 01:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KNw9WToth4E0cXIIrBWaFrE7KvV2IZWpurK1ayXVwQU=; b=WXDoOc4X0nC2xmYeC0vP8O+4FC6FpWHSsZjK50XG2G5gdihJUwDCxE0CN0Qd3GZkSn 8axNQHYl/PmoG9W1v+J1CRJx3SgwCaCQykfccWo4To7WNteBvunMkz061fu6+fB+U9Qj qQKiuD3yZrEE0GFLEq6u/AZswDKXJXuX5jBkVg++ZzmH5tkXhjk1UQVOR8kvKlWw7FgK UG97Li1+3JxWVogbSEbQDlxGZlxtPpUPfaecYD4puilW4IsGGFozqK6r7fMVuMGW94kg flDtnO/czva7nVSDssX59xtNP/YPt/+fMLad0ayIz1WquYP3uuO4rfm3WqcIXQriDOcq QkEw== MIME-Version: 1.0 X-Received: by 10.182.98.109 with SMTP id eh13mr15211076obb.50.1359970496981; Mon, 04 Feb 2013 01:34:56 -0800 (PST) Received: by 10.60.12.201 with HTTP; Mon, 4 Feb 2013 01:34:56 -0800 (PST) In-Reply-To: <1BE5D090C6244A49B9815F339F76EA4538305691@SG000708.corproot.net> References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> <1BE5D090C6244A49B9815F339F76EA4538305691@SG000708.corproot.net> Date: Mon, 4 Feb 2013 10:34:56 +0100 Message-ID: From: Eduard Metz To: Guillaume.Leclanche@swisscom.com Content-Type: multipart/alternative; boundary=14dae93a15c360acce04d4e2cef5 Cc: "draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 09:34:58 -0000 --14dae93a15c360acce04d4e2cef5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isn't it up to the ISP's to decide where to implement these filters? As long as it results in the same functionality for the end-users. /Eduard On Sun, Feb 3, 2013 at 1:14 AM, wrote: > > De : Cameron Byrne [mailto:cb.list6@gmail.com] > > Envoy=E9 : samedi 2 f=E9vrier 2013 19:16 > > > > I believe it would be helpful to call out that the drop rules can be > statelessly > > implemented in the provider network while the ratelimiting function is > > stateful and is a better fit for the CPE. > > > > I would also suggest the the term residential be changed to include > mobile. > > Perhaps "consumer grade" internet service or something like that. > > Hi Cameron, > > I understand very well your point and I guess your arguments (from a > mobile point of view), but this RFC wants to focus on the CPE features, a= nd > we don't want to talk about ISP filters. > And regarding the mobile: nothing prevents the residential CPE uplink to > be mobile, and with LTE connectivity we'll certainly see that more and mo= re. > > Guillaume > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --14dae93a15c360acce04d4e2cef5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Isn't it up to the ISP's to decide where to implem= ent these filters? As long as it results in =A0the same functionality for t= he end-users.

/Eduard


On Sun, Feb 3, 2013 at 1:14 AM, <Guillaume.Leclanche@swisscom.com> wrote:
> De=A0: Cameron Byrne [mailto:cb.= list6@gmail.com]
> Envoy=E9=A0: samedi 2 f=E9vrier 2013 19:16


> I believe it would be helpful to call out that the drop rules can be s= tatelessly
> implemented in the provider network while the ratelimiting function is=
> stateful and is a better fit for the CPE.
>
> I would also suggest the the term residential be changed to include mo= bile.
> Perhaps "consumer grade" internet service or something like = that.

Hi Cameron,

I understand very well your point and I guess your arguments (from a mobile= point of view), but this RFC wants to focus on the CPE features, and we do= n't want to talk about ISP filters.
And regarding the mobile: nothing prevents the residential CPE uplink to be= mobile, and with LTE connectivity we'll certainly see that more and mo= re.

Guillaume

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

--14dae93a15c360acce04d4e2cef5-- From etmetz@gmail.com Mon Feb 4 01:43: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 9323621F85AD for ; Mon, 4 Feb 2013 01:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZzO6EolM3o5 for ; Mon, 4 Feb 2013 01:43:19 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0C99121F842D for ; Mon, 4 Feb 2013 01:43:18 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wd20so6195918obb.9 for ; Mon, 04 Feb 2013 01:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9ODeSZEABlP4lIuLuOPp664ATcPsCUpwOmL/c5Ag9w4=; b=NWaEL5MzWp2ihpCWca7a1kLbmyiMjc98xJhdUIf8rw/I7opwVIv2MrDD9/OHlSYlpO zP/g0VEsW54zmZ7YM4/4Nttd3JAcFzMbm/K8NMQ8LCb7G77rPG0ADW49clyrlIz7hpsh /bVnaI3iEna0fecEYd1CnL0n1iq0/fqEkG7OIktoSVir2S6fKJ0wjcbvdH1rr9s5bv2D cHC5Xjpaoskkq+wEZHaurE9g4hFuHXdL6PkpM9tWzDhYpMsqzGbzUk6tGpl7JyLNWIKl Bgeddq+d7U9blpXGS8pcrvnwmFLFHLyFERYN9n87SujQWA0QHjR++bH0t3YJyrGIlKDE XhnQ== MIME-Version: 1.0 X-Received: by 10.60.154.169 with SMTP id vp9mr15758632oeb.109.1359970998648; Mon, 04 Feb 2013 01:43:18 -0800 (PST) Received: by 10.60.12.201 with HTTP; Mon, 4 Feb 2013 01:43:18 -0800 (PST) In-Reply-To: <1BE5D090C6244A49B9815F339F76EA4538304667@SG000708.corproot.net> References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> <1BE5D090C6244A49B9815F339F76EA4538304667@SG000708.corproot.net> Date: Mon, 4 Feb 2013 10:43:18 +0100 Message-ID: From: Eduard Metz To: Guillaume.Leclanche@swisscom.com Content-Type: multipart/alternative; boundary=bcaec550b136477f6b04d4e2ecb2 Cc: "v6ops@ietf.org" , "draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 09:43:19 -0000 --bcaec550b136477f6b04d4e2ecb2 Content-Type: text/plain; charset=ISO-8859-1 > > It's clear that the set of ports can't cover every single product existing > on the market that might introduce vulnerability in the customer network. > However, this list is just an example in the RFC. Therefore every > implementation of this policy will be different. > > We'll probably have to complete the security section to make this more > transparent. > > > > Indeed this is should be pointed out clearly. Also if the draft does not describe a policy in itself, but a way to define a more open policy this should also be clear. And again, an applicability statement / some usecase would be helpful to provide some understanding in which cases this (type of) policy would be benefical over that defined in RFC6092. /Eduard > > > --bcaec550b136477f6b04d4e2ecb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable





It's clear that the set of ports can't cover every single pro= duct existing on the market that might introduce vulnerability in the custo= mer network.
However, this list is just an example in the RFC. Therefore every implement= ation of this policy will be different.

We'll probably have to complete the security section to make this more = transparent.

>


Indeed = this is should be pointed out clearly. Also if the draft does not describe = a policy in itself, but a way to define a more open policy this should also= be clear. And again, an applicability statement / some usecase would be he= lpful to provide some understanding in which cases this (type of) policy wo= uld be benefical over that defined in RFC6092.

/Eduard
=A0



--bcaec550b136477f6b04d4e2ecb2-- From tjc@ecs.soton.ac.uk Mon Feb 4 02:04: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 7E7FD21F85DC for ; Mon, 4 Feb 2013 02:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+kS4SJqUUf8 for ; Mon, 4 Feb 2013 02:04:34 -0800 (PST) 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 01AA821F8415 for ; Mon, 4 Feb 2013 02:04:33 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r14A4TLV002078 for ; Mon, 4 Feb 2013 10:04:29 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r14A4TLV002078 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1359972269; bh=pyIPVD9ChOxRo9cI5FXbb+Ceaow=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=s3364U7bM0v1sLCqji/TbiEeA8LJcNczhjx1CFP2eobdY5DL9tBzWKqCHRLyQEs5s V6qoDHs7kBuliKlcDDQcnpQjLQmrC/cwEZ3032gS8rH/qjpnc4xEC8Gi0fTRz4S/x0 Yhu1jGKG5r4hZ3LOYldmI3B0t5L9tUZ++n/D7iE8= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p13A4Y0430632808NP ret-id none; Mon, 04 Feb 2013 10:04:29 +0000 Received: from ip-160-206.eduroam.soton.ac.uk (ip-160-206.eduroam.soton.ac.uk [152.78.160.206]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r14A4RsU019196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Feb 2013 10:04:28 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: Date: Mon, 4 Feb 2013 10:04:35 +0000 Content-Transfer-Encoding: 7bit Message-ID: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> <7A4FFF35-718E-4553-892F-142340C37AAC@ecs.soton.ac.uk> To: IPv6 Operations X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p13A4Y043063280800; tid=p13A4Y0430632808NP; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r14A4TLV002078 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 10:04:35 -0000 On 4 Feb 2013, at 06:20, Erik Kline wrote: > > At the very least I would not be in favor of any standards-level > status above {experimental,informational}. This. Tim From v6ops@globis.net Mon Feb 4 05:41: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 1F6C221F8605 for ; Mon, 4 Feb 2013 05:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OzLPDKA4hUc for ; Mon, 4 Feb 2013 05:41:43 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2573A21F85FE for ; Mon, 4 Feb 2013 05:41:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0CA218700DD; Mon, 4 Feb 2013 14:36:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 657SWAsqcQ5Q; Mon, 4 Feb 2013 14:35:58 +0100 (CET) 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 E1A3B87007E; Mon, 4 Feb 2013 14:35:57 +0100 (CET) Message-ID: <510FB937.40208@globis.net> Date: Mon, 04 Feb 2013 14:35:51 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Fred Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience 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, 04 Feb 2013 13:41:44 -0000 I have read this draft, and I don't particularly see in its current form how it significantly advances our knowledge of operational experience of NAT64 in a way that could be applied by other operators. When I compare it something like rfc3974 rfc5037 or rfc6586 I don't see any detail of what was tested, tips or lists of features that worked as expected, gotchas, common pitfalls to be avoided, configuration information, additional algorithms, or open issues that the IETF or manufacturers still need to address. Fred Baker wrote: > This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience. 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 alexandru.petrescu@gmail.com Mon Feb 4 06:18: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 54BE821F85F7 for ; Mon, 4 Feb 2013 06:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.918 X-Spam-Level: X-Spam-Status: No, score=-9.918 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ldQBQ4nF6VC for ; Mon, 4 Feb 2013 06:18:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id EC5B621F85ED for ; Mon, 4 Feb 2013 06:18:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r14EIHOk000686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 4 Feb 2013 15:18:17 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r14EIHIE015141 for ; Mon, 4 Feb 2013 15:18:17 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r14EICcV004135 for ; Mon, 4 Feb 2013 15:18:17 +0100 Message-ID: <510FC324.7090908@gmail.com> Date: Mon, 04 Feb 2013 15:18:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <510F7FCC.5040705@viagenie.ca> In-Reply-To: <510F7FCC.5040705@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 14:18:24 -0000 Le 04/02/2013 10:30, Simon Perreault a écrit : > Le 2013-02-04 02:37, Cameron Byrne a écrit : >> The other 2 providers are specifically defunct on the IPv4v6 front. >> One -- has a brand new high capacity P-GW/GGSN which does not >> support IPv4v6 (it supports v4 or v6). And the other, which is >> painfully wrecking my IPv4v6 deployment plans, has a newish (few >> years old now) high capacity SGSN which does not support IPv4v6 >> (also supports v4 or v6). Witness, new gear does not result in >> v4v6 (dual-stack). In fact, the legacy SGSN that i had from the >> same vendor does support v4v6, but it is now end of life (at least >> as far as my network)! It is just the new one that does not have >> dual-stack support. > > Curious... Why is this happening? Is it malice or incompetence? Or > some other reason? Let me add to this curiosity. I doubt it's malice nor incompetence. My local experience is that one operator's LTE deployment is IPv4 not IPv6, and NAT not publicly routable addresses. This is surprisingly different than same operator's 3G deployment which offers publicly routable IPv4 addresses for top class subscriptions and IPv6 for test cases (not for the public). (on another hand, the bandwidth, latency and fair-use limits on the subscription plan offered by the LTE network are better than 3G.) When I express this kind of surprise - a future generation cellular network with a past generation of IP protocols - I am not well understood. I am explained that the network is new, entirely independent from 3G, and hence many of the achievements in 3G can't be reused. I suspect that they couldn't obtain new IPv4 publicly routable addresses for the new LTE deployment. I suspect that, absent IPv4 publicly routable space - an operator prefers to offer NAT-IPv4 rather than IPv6. I also suspect that although the things move slowly, they may move in the right direction. A parallel could be drawned between the GPRS-3G migration and 3G-LTE, in terms of IP family of protocols. If I remember correctly, the GPRS deployment was IPv4 NAT and one had to wait for 2nd generation 3G deployments to see publicly routable IPv4 addresses and IPv6 in test. Maybe now we wait the same - a second or 3rd generation LTE deployment to see publicly routable IPv4 and IPv6. So, I personnally wait for the following, in this order: - 3G network to become IPv6 for everybody - LTE network to become IPv4 publicly routable addresses - LTE network to become IPv6 as test - LTE network to become IPv6 for everybody All this maybe in 3-6 years time. At that time we'd talk 5G already I believe. Alex > > I'm not expecting perfect answers on a public list, but it might > still be interesting... > > Simon _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From warren@kumari.net Mon Feb 4 07:20: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 D005B21F88CA for ; Mon, 4 Feb 2013 07:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCXV7MSMp6Sv for ; Mon, 4 Feb 2013 07:20:23 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5702521F88BE for ; Mon, 4 Feb 2013 07:20:23 -0800 (PST) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id 00D2C1B4015C; Mon, 4 Feb 2013 10:20:21 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Mon, 4 Feb 2013 10:20:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1BD776F7-70B1-4B7C-A215-4CE2AC9F7624@kumari.net> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> To: Erik Kline X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 15:20:24 -0000 On Feb 4, 2013, at 1:20 AM, Erik Kline wrote: >> There is a part of me that would be very happy for the working group = to >> decide it didn't want to publish the draft at all, and to state that = the >> reason is an IPR declaration that looks essentially vacuous and has = been >> neither explained nor substantiated by China Mobile. But that's just = me. I have not (and will not) read the claims in the IPR, and so I cannot = form my own opinion of the IPR=85. >=20 > I could definitely agree with this. >=20 > At the very least I would not be in favor of any standards-level > status above {experimental,informational}. I would prefer that this just goes away. If that doesn't happen, I can = live with experimental or informational. I really don't see how this can be a BCP if it is unclear if folk can = implement=85 W > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- The plural of anecdote is not evidence. -- Bill Lockyer, California Attorney General From swmike@swm.pp.se Mon Feb 4 08:43: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 A7AAE21F85B4 for ; Mon, 4 Feb 2013 08:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtmkVfM6e9NS for ; Mon, 4 Feb 2013 08:43:08 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1A62521F85B0 for ; Mon, 4 Feb 2013 08:43:07 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4E0F59C; Mon, 4 Feb 2013 17:43:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 453469A; Mon, 4 Feb 2013 17:43:06 +0100 (CET) Date: Mon, 4 Feb 2013 17:43:06 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <510FC324.7090908@gmail.com> Message-ID: References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 16:43:08 -0000 On Mon, 4 Feb 2013, Alexandru Petrescu wrote: > A parallel could be drawned between the GPRS-3G migration and 3G-LTE, in > terms of IP family of protocols. If I remember correctly, the GPRS > deployment was IPv4 NAT and one had to wait for 2nd generation 3G > deployments to see publicly routable IPv4 addresses and IPv6 in test. > Maybe now we wait the same - a second or 3rd generation LTE deployment > to see publicly routable IPv4 and IPv6. This is really weird. Personally, I'm trying to get 2G/3G/4G equal service with proper establishment and handover between the networks for a IPv4v6 PDP context. > So, I personnally wait for the following, in this order: > - 3G network to become IPv6 for everybody > - LTE network to become IPv4 publicly routable addresses > - LTE network to become IPv6 as test > - LTE network to become IPv6 for everybody > All this maybe in 3-6 years time. At that time we'd talk 5G already I > believe. Doing IPv4v6 on LTE is not that much of a problem, that's doable today (my experience). Getting the same IPv4v6 so the customer can establish a IPv4v6 PDP context in 3G, handing over to 4G and back to 3G, that's where it gets interesting. :P For me 2G/3G/4G are different access technologies that should be transparent to the user, they should offer the same services just at increasingly higher speeds. IPv6 only access on 2G/3G/4G is also doable (there are quite a few phones and usb dongles that do this), the problem is that IPv6 only + NAT64 gives a lousy end user experience without 464XLAT, so that's a no-go. -- Mikael Abrahamsson email: swmike@swm.pp.se From Fred.L.Templin@boeing.com Mon Feb 4 08:50: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 6CCD621F8967 for ; Mon, 4 Feb 2013 08:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oj-FRoJ7azW for ; Mon, 4 Feb 2013 08:50:58 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id B1B2A21F84D8 for ; Mon, 4 Feb 2013 08:50:57 -0800 (PST) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r14Govnd030490 for ; Mon, 4 Feb 2013 08:50:57 -0800 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r14Gotxu030442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 4 Feb 2013 08:50:57 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 4 Feb 2013 08:50:56 -0800 From: "Templin, Fred L" To: IETF v6ops list Date: Mon, 4 Feb 2013 08:50:55 -0800 Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: Ac4CEytEr5H4Kk0KQ5e3FkAvvKl7HwA4u2fw Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> In-Reply-To: <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 16:50:58 -0000 Hi, Two drafts the authors should be aware of are "Updated Specification of the IPv4 ID Field": https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ and "The Subnetwork Encapsulation and Adapation Layer (SEAL)": https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ The former is a revised specification of the use of the IPv4 ID field and defines the cases in which the ID field does and does not contain useful information. The latter is a means for adding a 32-bit ID field during encapsulation, where the ID appears in an extension header similar to the way the IPv6 fragment header currently appears. Point being that the IPv4 ID was never intended for purposes such as ensuring uniqueness other than for the fragmentation and reassembly process. And, for IPv6, there are already ways to add an ID to a packet if one is needed. Thanks - Fred fred.l.templin@boeing.com From fred@cisco.com Mon Feb 4 09:17: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 7D8AC21F8A79 for ; Mon, 4 Feb 2013 09:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.256 X-Spam-Level: X-Spam-Status: No, score=-110.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNzczMS+cFHy for ; Mon, 4 Feb 2013 09:17:03 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B816621F8A77 for ; Mon, 4 Feb 2013 09:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3262; q=dns/txt; s=iport; t=1359998223; x=1361207823; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=qb8GIoroBhTKYx7U1AW87K8B6K60DR26LdtmkMMeSpA=; b=T0y4tTOGQbMIp6lZL+0j/cqEKGgvwDIxTh0305fNf8haRppF4j3dUWFE 9kMfoRZAaWkAwiUCxVnmI1BOltnOm9+Njep/vBgDR7iwho/9yuB1Bp8JT Ie+B2M/EafaUkBAsICLKe9G3EPU0nvIG1cHCv4e7d+d5D1gTReu4JUPRy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO/rD1GtJXHA/2dsb2JhbABFvzkWc4IfAQEBAwEBAQEaHUQLAgEZAwECCwsBAQcQJwsbAggCBBMIiAMGDLt1jRoaaQgBgkthA5c8jzSCfIFoBxce X-IronPort-AV: E=Sophos;i="4.84,601,1355097600"; d="scan'208";a="172831229" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 04 Feb 2013 17:17:03 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r14HH3DR009962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Feb 2013 17:17:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 11:17:02 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org list" Thread-Topic: Call for Comment: "RFC Format Requirements and Future Development" Thread-Index: AQHOAvtyz/011A2wdjolYmtak5x0CQ== Date: Mon, 4 Feb 2013 17:17:02 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B768E1C@xmb-rcd-x09.cisco.com> References: 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: <4AE052FD51D5554A91DE36EA2FA0705A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Fwd: Call for Comment: "RFC Format Requirements and Future Development" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 17:17:04 -0000 Operators may have comments here. One of the arguments for flat ASCII, for = example, has been the ability to read it on a simple terminal in a machine = room. > From: IAB Chair > Subject: Call for Comment: "RFC Format Requirements and Future Developmen= t" > Date: February 1, 2013 11:53:28 AM PST > To: "ietf-announce@ietf.org" > Cc: "rfc-interest@rfc-editor.org" >=20 > This is an announcement of an IETF-wide Call for Comment on "RFC Format R= equirements and Future Development". >=20 > The document is being considered for publication as an Informational RFC = within the IAB stream, and is available for inspection here:=20 > http://tools.ietf.org/html/draft-iab-rfcformatreq > =20 > The Call for Comment will last until February 29, 2013. Please send comme= nts to iab at iab.org or submit them via TRAC (see below). Please also cc: = rfc-interest@rfc-editor.org (for membership info, see: https://www.rfc-edit= or.org/mailman/listinfo/rfc-interest). > =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > Submitting Comments via TRAC=20 > 1. To submit an issue in TRAC, you first need to login to the IAB site on= the tools server:=20 > http://tools.ietf.org/wg/iab/trac/login=20 > =20 > 2. If you don't already have a login ID, you can obtain one by navigating= to this site:=20 > http://trac.tools.ietf.org/newlogin=20 > =20 > 3. Once you have obtained an account, and have logged in, you can file an= issue by navigating to the ticket entry form:=20 > http://trac.tools.ietf.org/wg/iab/trac/newticket=20 > =20 > 4. When opening an issue:=20 > a. The Type: field should be set to "defect" for an issue with the curren= t document text, or "enhancement" for a proposed addition of functionality = (such as an additional requirement).=20 > b. The Priority: field is set based on the severity of the Issue. For exa= mple, editorial issues are typically "minor" or "trivial".=20 > c. The Milestone: field should be set to milestone1 (useless, I know).=20 > d. The Component: field should be set to the document you are filing the = issue on.=20 > e. The Version: field should be set to "1.0".=20 > f. The Severity: field should be set to based on the status of the docume= nt (e.g. "In WG Last Call" for a document in IAB last call)=20 > g. The Keywords: and CC: fields can be left blank unless inspiration seiz= es you.=20 > h. The Assign To: field is generally filled in with the email address of = the editor.=20 > =20 > 5. Typically it won't be necessary to enclose a file with the ticket, but= if you need to, select "I have files to attach to this ticket".=20 > =20 > 6. If you want to preview your Issue, click on the "Preview" button. When= you're ready to submit the issue, click on the "Create Ticket" button.=20 > =20 > 7. If you want to update an issue, go to the "View Tickets" page:=20 > http://trac.tools.ietf.org/wg/iab/trac/report/1=20 > =20 > Click on the ticket # you want to update, and then modify the ticket fiel= ds as required.=20 > =20 From cb.list6@gmail.com Mon Feb 4 09:34:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4080C21F89CE for ; Mon, 4 Feb 2013 09:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FlZ034EIt2E for ; Mon, 4 Feb 2013 09:34:25 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 57BC221F89BA for ; Mon, 4 Feb 2013 09:34:25 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id fq13so4763895lab.7 for ; Mon, 04 Feb 2013 09:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=CY69gY1aeGTUjslbleQNxBkUrBnW7rJMWLiBHZXzeJE=; b=kEocZ6qid7s7U/nRegokF5gumibxwMGxJa85Rg8J9f1DFDFKjGINXgctQDCIKjtHzI 8Xqf3ortKPe/KB12H7ElVdQqHbjjPQJ2J0BOSPt4KkNo4Wl8Sm+hevYZhdpQqr1Y1dUX 88nOstoZqlMLhfGk4V1upHR8BfX81PyogV8bk8GyspR2wycrRNAL9HUmf8TKLSoeBcoL 5SnVUvJ406WguCH8QHRYAxn1QIkB1grsSP7p8qQjr3d+GnqqsnuUkF3nLbTihB5iYblB c2Wyk1upbXO2I/1geHhWAgy3Sh0Cr2NDfa5GTbUxhPCnRkOR7JSRo4a7qFO5wHZ1S9Zn QRNw== MIME-Version: 1.0 X-Received: by 10.112.38.164 with SMTP id h4mr8433702lbk.123.1359999264199; Mon, 04 Feb 2013 09:34:24 -0800 (PST) Received: by 10.112.7.165 with HTTP; Mon, 4 Feb 2013 09:34:23 -0800 (PST) In-Reply-To: <1BD776F7-70B1-4B7C-A215-4CE2AC9F7624@kumari.net> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> <1BD776F7-70B1-4B7C-A215-4CE2AC9F7624@kumari.net> Date: Mon, 4 Feb 2013 09:34:23 -0800 Message-ID: From: Cameron Byrne To: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 17:34:26 -0000 On Mon, Feb 4, 2013 at 7:20 AM, Warren Kumari wrote: > > On Feb 4, 2013, at 1:20 AM, Erik Kline wrote: > >>> There is a part of me that would be very happy for the working group to >>> decide it didn't want to publish the draft at all, and to state that th= e >>> reason is an IPR declaration that looks essentially vacuous and has bee= n >>> neither explained nor substantiated by China Mobile. But that's just me= . > > I have not (and will not) read the claims in the IPR, and so I cannot for= m my own opinion of the IPR=85. > If you cannot form an opinion, then do not form an opinion... yet you sent this mail and gave your opinion. So, i am lost. You are not the only person on the list to make this statement and lose me in the process, so i assume i am somehow missing something. But, let's explore a little. I do encourage you to form an opinion. I am sure the IETF's own website is not too encumbering to you, so allow me to link you to the relevant parts. China Mobile filed an IPR disclosure to the IETF about a Chinese patent they own https://datatracker.ietf.org/ipr/1730/ The relevant part is the date of the application / grant June 26, 2009. We don't know the details of that patent, but I have the feeling we do not need those details. Now, if you may review http://www.ietf.org/mail-archive/web/v6ops/current/msg00917.html You will see discussion on the v6ops list where this is said: "I wrote about the v4-v6-v4 case where IPv4 clients sit behind a CPE or layer in the stack that translates their IPv4 packets into IPv6 packets using SIIT (=3D stateless) and then the resulting IPv6 packets flow through the same NAT64 translators that IPv6 hosts that want to talk to the IPv4 world also use." by one Iljitsch van Beijnum. This is almost exactly the abstract of 464XLAT. This nearly perfect summary of 464XLAT has a time stamp of 25 May 2008, over a year before the IPR was granted. I am not asking anyone to change an opinion, i am not a lawyer, i am just providing some open data points. CB >> >> I could definitely agree with this. >> >> At the very least I would not be in favor of any standards-level >> status above {experimental,informational}. > > I would prefer that this just goes away. If that doesn't happen, I can li= ve with experimental or informational. > I really don't see how this can be a BCP if it is unclear if folk can imp= lement=85 > > W > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > -- > The plural of anecdote is not evidence. > -- Bill Lockyer, California Attorney General > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mackermann@bcbsm.com Mon Feb 4 09: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 B37DD21F8A90 for ; Mon, 4 Feb 2013 09:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.97 X-Spam-Level: X-Spam-Status: No, score=-5.97 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2JUmjG9BG3f for ; Mon, 4 Feb 2013 09:53:21 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 6588621F8959 for ; Mon, 4 Feb 2013 09:53:20 -0800 (PST) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id DEB5E136D10 for ; Mon, 4 Feb 2013 11:53:19 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id E8A71136D15; Mon, 4 Feb 2013 11:53:18 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 8FB644F80B5; Mon, 4 Feb 2013 12:51:58 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 7B34F4F80AA; Mon, 4 Feb 2013 12:51:58 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Mon, 4 Feb 2013 12:53:18 -0500 From: "Ackermann, Michael" To: "Templin, Fred L" , IETF v6ops list Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8A= Date: Mon, 4 Feb 2013 17:53:16 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 17:53:22 -0000 Thanks for your comments Fred=21 The first draft you reference seems to highlight the need for an IPID = field larger than 16 bits (v4) or 32 bits (v6), due to the much faster = networks we have today. We agree and that is very lightly referenced in = our RFC. The reason for only lightly, is that we chose to focus on the = need for IPID at all, since many at the IETF did not agree this was an = issue when we first introduced it. Our original proposal suggested going = to 64 bits as part of the solution, but for now we have backed off on = solutions and are focused on convincing the IETF that the elimination of = IPID as a diagnostic facility, would be bad for end user organizations. =20 The second draft you referenced is one I was not aware of but is very = impressive and well written=21 I know it was focused on tunnels and = encapsulation, but among many other things it seems to promote the value = of uniquely identifying packets, in particular ones that could be = duplicate, improper or even malicious. If I am interpreting properly, = then we are in full agreement. =20 Our main issue is that information such as provided by IPID can be = critical to reliably running sophisticated networks today.=20 Thanks again=21 Mike -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Templin, Fred L Sent: Monday, February 04, 2013 11:51 AM To: IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed Hi, Two drafts the authors should be aware of are =22Updated Specification of = the IPv4 ID Field=22: https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ and =22The Subnetwork Encapsulation and Adapation Layer (SEAL)=22: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ The former is a revised specification of the use of the IPv4 ID field and = defines the cases in which the ID field does and does not contain useful = information. The latter is a means for adding a 32-bit ID field during = encapsulation, where the ID appears in an extension header similar to the = way the IPv6 fragment header currently appears. Point being that the IPv4 ID was never intended for purposes such as = ensuring uniqueness other than for the fragmentation and reassembly = process. And, for IPv6, there are already ways to add an ID to a packet if = one is needed. Thanks - Fred fred.l.templin=40boeing.com _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From Ted.Lemon@nominum.com Mon Feb 4 09:54: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 3EBEE21F8AAC for ; Mon, 4 Feb 2013 09:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHBPCHSnIPwO for ; Mon, 4 Feb 2013 09:54:10 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 42CCF21F8A25 for ; Mon, 4 Feb 2013 09:54:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ/1uxcoCSSTqe9exZf2T/AfITWgkyeA@postini.com; Mon, 04 Feb 2013 09:54:04 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BF4DAF8009 for ; Mon, 4 Feb 2013 09:54:03 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B6954190043; Mon, 4 Feb 2013 09:54:03 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 09:54:03 -0800 From: Ted Lemon To: Cameron Byrne Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOAv3nccxuYvEwzkiDdYHsjfT+sJhqgVsA Date: Mon, 4 Feb 2013 17:54:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747E229@mbx-01.win.nominum.com> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> <1BD776F7-70B1-4B7C-A215-4CE2AC9F7624@kumari.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7AE92621BA4651409DFB31328261BF61@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 17:54:11 -0000 On Feb 4, 2013, at 12:34 PM, Cameron Byrne wrote: > If you cannot form an opinion, then do not form an opinion... There is actually no benefit to any of us to try to form an opinion about t= he validity of any IPR claim. It is not we who would actually be responsi= ble for deciding whether the IPR claim has been infringed if a claim of inf= ringement were made. Indeed, in making such a determination we might expos= e ourselves to liability, should the court rule differently. So whether or not the working group decides to publish this as a BCP, the w= orking group absolutely should not take a position on the validity of the I= PR, as you have proposed it do. From nick@inex.ie Mon Feb 4 09:58: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 EE78121F8A55 for ; Mon, 4 Feb 2013 09:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3Dl6b9zYFpE for ; Mon, 4 Feb 2013 09:58:41 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0BC21F8A25 for ; Mon, 4 Feb 2013 09:58:40 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r14Hu7Ah056489 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 17:56:08 GMT (envelope-from nick@inex.ie) Message-ID: <510FF6CA.8040705@inex.ie> Date: Mon, 04 Feb 2013 17:58:34 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Cameron Byrne References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> <1BD776F7-70B1-4B7C-A215-4CE2AC9F7624@kumari.net> In-Reply-To: X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 17:58:42 -0000 On 04/02/2013 17:34, Cameron Byrne wrote: > If you cannot form an opinion, then do not form an opinion... yet you > sent this mail and gave your opinion. So, i am lost. You are not the > only person on the list to make this statement and lose me in the > process, so i assume i am somehow missing something. But, let's > explore a little. You possibly are. If Warren reads a USPTO patent and then his employer violates it either by accident or design, and then gets sued for patent violation, then they could end up in 3x damages territory for wilful infringement if the law suit is successful. Because of this, people in large companies tend to have very clear rules about certain types of people not reading patents. As this is a chinese patent, it's less clear what the rules might be, but it's entirely possible that Warren's employer might have put a blanket ban in place on reading patents in general. > I do encourage you to form an opinion. I am sure the IETF's own > website is not too encumbering to you, so allow me to link you to the > relevant parts. > > China Mobile filed an IPR disclosure to the IETF about a Chinese > patent they own https://datatracker.ietf.org/ipr/1730/ This isn't very useful either: the patent is in chinese. I don't read chinese, so have no idea what it's saying, and am not prepared to use google translate to try to work it out. I support Fred's formal request to CM to clarify their position on the patent and its application to this ID. Nick From Fred.L.Templin@boeing.com Mon Feb 4 10:17: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 0A1FC21F853D for ; Mon, 4 Feb 2013 10:17:22 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUx2kbg9ignf for ; Mon, 4 Feb 2013 10:17:21 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8121121F84B2 for ; Mon, 4 Feb 2013 10:17:21 -0800 (PST) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r14IHK2P011804 for ; Mon, 4 Feb 2013 10:17:20 -0800 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r14IGoKZ011370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Feb 2013 10:17:20 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 4 Feb 2013 10:17:15 -0800 From: "Templin, Fred L" To: "Ackermann, Michael" , IETF v6ops list Date: Mon, 4 Feb 2013 10:17:12 -0800 Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8CAAAkecA== Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.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 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 18:17:22 -0000 Hi Michael, Forgot to mention that here is another one you would want to cite: http://datatracker.ietf.org/doc/rfc4963/ Thanks - Fred > -----Original Message----- > From: Ackermann, Michael [mailto:MAckermann@bcbsm.com] > Sent: Monday, February 04, 2013 9:53 AM > To: Templin, Fred L; IETF v6ops list > Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > Thanks for your comments Fred! >=20 > The first draft you reference seems to highlight the need for an IPID > field larger than 16 bits (v4) or 32 bits (v6), due to the much faster > networks we have today. We agree and that is very lightly referenced in > our RFC. The reason for only lightly, is that we chose to focus on the > need for IPID at all, since many at the IETF did not agree this was an > issue when we first introduced it. Our original proposal suggested goin= g > to 64 bits as part of the solution, but for now we have backed off on > solutions and are focused on convincing the IETF that the elimination of > IPID as a diagnostic facility, would be bad for end user organizations. >=20 > The second draft you referenced is one I was not aware of but is very > impressive and well written! I know it was focused on tunnels and > encapsulation, but among many other things it seems to promote the value > of uniquely identifying packets, in particular ones that could be > duplicate, improper or even malicious. If I am interpreting properly, > then we are in full agreement. >=20 > Our main issue is that information such as provided by IPID can be > critical to reliably running sophisticated networks today. >=20 > Thanks again! >=20 > Mike >=20 >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Monday, February 04, 2013 11:51 AM > To: IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > Hi, >=20 > Two drafts the authors should be aware of are "Updated Specification of > the IPv4 ID Field": >=20 > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ >=20 > and "The Subnetwork Encapsulation and Adapation Layer (SEAL)": >=20 > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ >=20 > The former is a revised specification of the use of the IPv4 ID field and > defines the cases in which the ID field does and does not contain useful > information. The latter is a means for adding a 32-bit ID field during > encapsulation, where the ID appears in an extension header similar to the > way the IPv6 fragment header currently appears. >=20 > Point being that the IPv4 ID was never intended for purposes such as > ensuring uniqueness other than for the fragmentation and reassembly > process. And, for IPv6, there are already ways to add an ID to a packet i= f > one is needed. >=20 > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > The information contained in this communication is highly confidential an= d > is intended solely for the use of the individual(s) to whom this > communication is directed. If you are not the intended recipient, you are > hereby notified that any viewing, copying, disclosure or distribution of > this information is prohibited. Please notify the sender, by electronic > mail or telephone, of any unintended receipt and delete the original > message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are > nonprofit corporations and independent licensees of the Blue Cross and > Blue Shield Association. From warren@kumari.net Mon Feb 4 11:20: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 8DDF621F89E9 for ; Mon, 4 Feb 2013 11:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXGiEwtP34K3 for ; Mon, 4 Feb 2013 11:20:44 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ED021F8996 for ; Mon, 4 Feb 2013 11:20:43 -0800 (PST) Received: from dhcp-222-190.meetings.nanog.org (dhcp-222-190.meetings.nanog.org [199.187.222.190]) by vimes.kumari.net (Postfix) with ESMTPSA id BD8C81B40706; Mon, 4 Feb 2013 14:20:42 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Mon, 4 Feb 2013 14:20:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7ABC555A-9063-4875-8236-43C5B6D98CDA@kumari.net> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> <1BD776F7-70B1-4B7C-A215-4CE2AC9F7624@kumari.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 19:20:44 -0000 On Feb 4, 2013, at 12:34 PM, Cameron Byrne wrote: > On Mon, Feb 4, 2013 at 7:20 AM, Warren Kumari = wrote: >>=20 >> On Feb 4, 2013, at 1:20 AM, Erik Kline wrote: >>=20 >>>> There is a part of me that would be very happy for the working = group to >>>> decide it didn't want to publish the draft at all, and to state = that the >>>> reason is an IPR declaration that looks essentially vacuous and has = been >>>> neither explained nor substantiated by China Mobile. But that's = just me. >>=20 >> I have not (and will not) read the claims in the IPR, and so I cannot = form my own opinion of the IPR=85. >>=20 >=20 > If you cannot form an opinion, then do not form an opinion... yet you > sent this mail and gave your opinion. =20 I cannot form an opinion on the validity / claims in the IPR -- Nick and = Ted saved me the trouble of explaining why=85 Even if I could read the = application / patent I, not being a lawyer (and not wanting to play one = on TV), I probably wouldn't be able to figure out what exactly was being = claimed... Luckily, the validity, color, flavor, etc isn't important -- what is = important is if folk (like small players, the open source community) can = implement this without royalty and without fear of being the one = fighting the claims=85 > So, i am lost. You are not the > only person on the list to make this statement and lose me in the > process, so i assume i am somehow missing something. But, let's > explore a little. >=20 > I do encourage you to form an opinion. I am sure the IETF's own > website is not too encumbering to you, so allow me to link you to the > relevant parts. >=20 > China Mobile filed an IPR disclosure to the IETF about a Chinese > patent they own https://datatracker.ietf.org/ipr/1730/ >=20 > The relevant part is the date of the application / grant June 26, > 2009. We don't know the details of that patent, but I have the > feeling we do not need those details. >=20 > Now, if you may review > http://www.ietf.org/mail-archive/web/v6ops/current/msg00917.html >=20 > You will see discussion on the v6ops list where this is said: "I > wrote about the v4-v6-v4 case where IPv4 clients sit behind a CPE or > layer in the stack that translates their IPv4 packets into IPv6 > packets using SIIT (=3D stateless) and then the resulting IPv6 packets > flow through the same NAT64 translators that IPv6 hosts that want to > talk to the IPv4 world also use." by one Iljitsch van Beijnum. This > is almost exactly the abstract of 464XLAT. >=20 > This nearly perfect summary of 464XLAT has a time stamp of 25 May > 2008, over a year before the IPR was granted. So, as I said, I'm not a lawyer, nor do I want to be one, but what I = *think* you are saying is that this is prior art, and so the claims are = not valid?=20 If this is what you are saying, it seems (to me at least) to make this = all the more worrying. If Joe Schmo implements this, based on the assumption the claims are not = valid, doesn't he end up potentially being the one stuck in lawsuits = over this? And if he assumes it is valid (which is safer), he possibly = has to pay some (unstated) royalty... If that is not what you were saying, please ignore the above... >=20 > I am not asking anyone to change an opinion, i am not a lawyer, i am > just providing some open data points. Neither (obviously) am I -- which is why unclear legal stuff scares me, = and I default to the "Arrrgh, run away" stance=85 W >=20 > CB >=20 >=20 >>>=20 >>> I could definitely agree with this. >>>=20 >>> At the very least I would not be in favor of any standards-level >>> status above {experimental,informational}. >>=20 >> I would prefer that this just goes away. If that doesn't happen, I = can live with experimental or informational. >> I really don't see how this can be a BCP if it is unclear if folk can = implement=85 >>=20 >> W >>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> -- >> The plural of anecdote is not evidence. >> -- Bill Lockyer, California Attorney General >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 -- Hope is not a strategy. -- Ben Treynor, Google From joelja@bogus.com Mon Feb 4 11:40: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 6CC4721F8A6E; Mon, 4 Feb 2013 11:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1k4PrmQKMjQ; Mon, 4 Feb 2013 11:40:20 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 04D6B21F8A64; Mon, 4 Feb 2013 11:40:19 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r14JeIR2061055 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 4 Feb 2013 19:40:19 GMT (envelope-from joelja@bogus.com) Message-ID: <51100E9D.6050803@bogus.com> Date: Mon, 04 Feb 2013 11:40:13 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG , Working Group Chairs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 04 Feb 2013 19:40:19 +0000 (UTC) Subject: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 19:40:20 -0000 To emphasize Fred's request, please share you opinion on whether this document should be published intact (as a BCP), with with a lower state (informational), or not at all, given the IPR disclosure associated with it. The document can be reviewed here: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 the known IPR disclosure is here: https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-v6ops-464xlat if you have registered your opinion on this subject already you will be counted. The deadline for commentary is Monday Feb 11th 2012. From sm@resistor.net Mon Feb 4 12:29: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 AB99521F8B1C; Mon, 4 Feb 2013 12:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JSBRmJ77nbg; Mon, 4 Feb 2013 12:29:13 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C815321F84CE; Mon, 4 Feb 2013 12:29:13 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r14KT3fb008107; Mon, 4 Feb 2013 12:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360009749; bh=DsZG7ywmZfeSRpOxu2WzbBMsRcHiE1ZXYn9QQF4Pz0E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QcEwY4zX5kpCzvx2O7FFxbOtTQbSC5waYv0rAWmBSLeDSiEq9Xhk2zJ8bh3OEW/Zb mBBpi3UznAfi4nWr1/Rq70CRZjtu5vQAsPv/x5KEIzxFbYqdH1ltcfwbxYYDMBMBph 50JfS62VRoN6WnMCICZJE0n8cupeWHi8phD6WQww= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360009749; i=@resistor.net; bh=DsZG7ywmZfeSRpOxu2WzbBMsRcHiE1ZXYn9QQF4Pz0E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BNm/b6zCxjHPXbxWtD6wpYRL3VKO9KAP8kAwz6XsxVoyuwIuGaA/utxaSiBKWzBXb fgMhzE7GocE79U02mymo0Gt+iqpHFj+OmGcAdA4rtK2aRFt8UiV7VtcSnvNqT5afyM /VP2qr3dUxldhtR7MLEmzUZFgqih68fUIonqBKDc= Message-Id: <6.2.5.6.2.20130204115515.09d54b60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 04 Feb 2013 12:09:41 -0800 To: v6ops@ietf.org From: SM In-Reply-To: <51100E9D.6050803@bogus.com> References: <51100E9D.6050803@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: wgchairs@ietf.org, Zhenkai Wang Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 20:29:17 -0000 At 11:40 04-02-2013, joel jaeggli wrote: >To emphasize Fred's request, please share you opinion on whether >this document should be published intact (as a BCP), with with a >lower state (informational), or not at all, given the IPR disclosure >associated with it. > >The document can be reviewed here: > >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > >the known IPR disclosure is here: > >https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-v6ops-464xlat > >if you have registered your opinion on this subject already you will >be counted. > >The deadline for commentary is Monday Feb 11th 2012. "China Mobile has spent lots of efforts like expenditure of man workforce, time, et al. on some technologies" [1]. It is unknown how anyone following this intended IETF best current practice for building a service based on 464XLAT architecture will be affected by that. I mentioned previously that the the IPR disclosure at https://datatracker.ietf.org/ipr/1730/ is not IETF-friendly. I don't think that the draft should be published as a BCP. I would like to thank the V6OPS WG Chair for his attempt to clarify the situation [2]. I note that here has not been any reply from Mr Wang who is affiliated with China Mobile. Regards, -sm 1. http://www.ietf.org/mail-archive/web/v6ops/current/msg15016.html 2. http://www.ietf.org/mail-archive/web/v6ops/current/msg15093.html From ietfdbh@comcast.net Mon Feb 4 12:48: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 D306821F8AF8 for ; Mon, 4 Feb 2013 12:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHwNgr7+rT76 for ; Mon, 4 Feb 2013 12:48:22 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 40CC621F8AE7 for ; Mon, 4 Feb 2013 12:48:22 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id wJSc1k0030ldTLk5ELoEPc; Mon, 04 Feb 2013 20:48:14 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta04.westchester.pa.mail.comcast.net with comcast id wLoE1k0033Ecudz3QLoEL4; Mon, 04 Feb 2013 20:48:14 +0000 From: "ietfdbh" To: "'joel jaeggli'" , "'IPv6 Ops WG'" , "'Working Group Chairs'" References: <51100E9D.6050803@bogus.com> In-Reply-To: <51100E9D.6050803@bogus.com> Date: Mon, 4 Feb 2013 15:48:04 -0500 Message-ID: <001501ce0318$ee63a810$cb2af830$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHhLqfxTiU/82od+QI0+CB9rQXmHJhD1EpQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360010894; bh=fhli/YAi7G+kHSzMWLEBmOicvgpoaHv8Pk7XzGaAjwE=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=sv4i6RobU6nyNfIWEwfjLnhXQu7ktV66vvqkVJlqMPzEZWCoV58FG0/S2YgKiBrFG AsyTtHsyrIZxgcWeZAc627XxAlGDi1fEws2eWa3760X/ifuiCZppY+wKJL2ciPTM9J bAWFAGFcRQHbGgYmlaUtUSwa8VwNCeOGU+NXkRnXtCweTJfidmCAAyH0JVkpncC7Yu xcHALg3ocDVdWwkuXtLz+vJppHyJy0CBQRrlrnR2oka9HzDPeB1VHzF6ILrZ0PaTp3 mnRWXupSET8uqpRP5Kze2GUgG9tQrNj0R4WArqMjovuptww0duh0cGm4uSy1+IpkU3 IVq27JJ6YehQw== X-Mailman-Approved-At: Mon, 04 Feb 2013 12:53:05 -0800 Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 20:48:23 -0000 Hi, Since the licensing terms are "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee", I think Informational sounds correct. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of joel jaeggli Sent: Monday, February 04, 2013 2:40 PM To: IPv6 Ops WG; Working Group Chairs Subject: Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) To emphasize Fred's request, please share you opinion on whether this document should be published intact (as a BCP), with with a lower state (informational), or not at all, given the IPR disclosure associated with it. The document can be reviewed here: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 the known IPR disclosure is here: https://datatracker.ietf.org/ipr/search/?option=document_search&document_sea rch=draft-ietf-v6ops-464xlat if you have registered your opinion on this subject already you will be counted. The deadline for commentary is Monday Feb 11th 2012. From lee.howard@twcable.com Mon Feb 4 13:50: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 7294121F8AB7; Mon, 4 Feb 2013 13:50:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd9pXnL7OReJ; Mon, 4 Feb 2013 13:50:02 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7B21F8A71; Mon, 4 Feb 2013 13:50:02 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,602,1355115600"; d="scan'208";a="21904837" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Feb 2013 16:49:39 -0500 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 4 Feb 2013 16:49:54 -0500 From: "Howard, Lee" To: joel jaeggli , IPv6 Ops WG , Working Group Chairs Date: Mon, 4 Feb 2013 16:49:53 -0500 Thread-Topic: Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4DIZD/WyBBgT70S7y0tCG09kAFcQ== Message-ID: In-Reply-To: <51100E9D.6050803@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 04 Feb 2013 14:28:27 -0800 Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Mon, 04 Feb 2013 21:50:03 -0000 BCP is premature. Lee On 2/4/13 2:40 PM, "joel jaeggli" wrote: >To emphasize Fred's request, please share you opinion on whether this >document should be published intact (as a BCP), with with a lower state >(informational), or not at all, given the IPR disclosure associated with >it. > >The document can be reviewed here: > >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > >the known IPR disclosure is here: > >https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document= _s >earch=3Ddraft-ietf-v6ops-464xlat > >if you have registered your opinion on this subject already you will be >counted. > >The deadline for commentary is Monday Feb 11th 2012. > 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 Ragnar.Anfinsen@altibox.no Mon Feb 4 15:31: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 6051221F8B30 for ; Mon, 4 Feb 2013 15:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSyb1OhNlkon for ; Mon, 4 Feb 2013 15:31:15 -0800 (PST) Received: from asav5.lyse.net (asav5.lyse.net [81.167.37.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2918521F881D for ; Mon, 4 Feb 2013 15:31:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by asav5.lyse.net (Postfix) with ESMTP id 7B3B890175; Tue, 5 Feb 2013 00:31:13 +0100 (CET) X-Virus-Scanned: amavisd-new at lyse.net Received: from prdsmtp01.lyse.no (unknown [79.161.5.211]) by asav5.lyse.net (Postfix) with ESMTP id EDF539014D; Tue, 5 Feb 2013 00:31:12 +0100 (CET) Received: from PRDHUB02.lyse.no (192.168.205.152) by prdsmtp01.lyse.no (79.161.5.211) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 5 Feb 2013 00:30:26 +0100 Received: from PRDMBX02.lyse.no ([fe80::14b9:b4e8:9cc8:6970]) by prdhub02.lyse.no ([fe80::b00d:88bb:8623:fd99%12]) with mapi id 14.02.0318.001; Tue, 5 Feb 2013 00:30:37 +0100 From: "Anfinsen, Ragnar" To: Eduard Metz Thread-Topic: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security Thread-Index: AQHN+wI3nXKl8QgzEEioUyj6l1V73JhaJY4AgAy2gACAAGQYgIACLtoAgAD6QgA= Date: Mon, 4 Feb 2013 23:30:37 +0000 Message-ID: In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [192.168.11.15] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3DB5DE3DDA52DC42A7D6792DF39275A7@lyse.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Feb 2013 23:31:16 -0000 Eduard, all, That is totally right, this draft describes the principal of allowing all t= raffic, both inbound and outbound, except some ports that the ISP/CPE manuf= acturer/end-user decides. I also see the challenge in how do define/update a list of ports that shoul= d be blocked. I can see a possibility that someone makes a public, well mai= ntained list, which a CPE/ISP can subscribe to in order to keep the list up= to date. However, I also see that such task involves a lot of trust and ma= intenance. Maybe some trusted body, like ISC or HoneyNet, should consider maintaining = such list. But keeping in mind that this should not be a list that is to fr= equently updated. Just my 5 cent. /Ragnar On 04.02.13 10:34, "Eduard Metz" = > wrote: Isn't it up to the ISP's to decide where to implement these filters? As lon= g as it results in the same functionality for the end-users. /Eduard On Sun, Feb 3, 2013 at 1:14 AM, > wrote: > De : Cameron Byrne [mailto:cb.list6@gmail.com] > Envoy=E9 : samedi 2 f=E9vrier 2013 19:16 > I believe it would be helpful to call out that the drop rules can be stat= elessly > implemented in the provider network while the ratelimiting function is > stateful and is a better fit for the CPE. > > I would also suggest the the term residential be changed to include mobil= e. > Perhaps "consumer grade" internet service or something like that. Hi Cameron, I understand very well your point and I guess your arguments (from a mobile= point of view), but this RFC wants to focus on the CPE features, and we do= n't want to talk about ISP filters. And regarding the mobile: nothing prevents the residential CPE uplink to be= mobile, and with LTE connectivity we'll certainly see that more and more. Guillaume _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Mon Feb 4 16:20: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 9135B21F8573 for ; Mon, 4 Feb 2013 16:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKJTzeZ3SE5E for ; Mon, 4 Feb 2013 16:20:31 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C62E521F84FB for ; Mon, 4 Feb 2013 16:20:30 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r150KHdB064575 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 00:20:17 GMT (envelope-from joelja@bogus.com) Message-ID: <5110503C.8000806@bogus.com> Date: Mon, 04 Feb 2013 16:20:12 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Ted Lemon , Cameron Byrne References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <8C48B86A895913448548E6D15DA7553B765FB5@xmb-rcd-x09.cisco.com> <8C48B86A895913448548E6D15DA7553B7661B2@xmb-rcd-x09.cisco.com> <1BD776F7-70B1-4B7C-A215-4CE2AC9F7624@kumari.net> <8D23D4052ABE7A4490E77B1A012B63074747E229@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747E229@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 05 Feb 2013 00:20:18 +0000 (UTC) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 00:20:31 -0000 On 2/4/13 9:54 AM, Ted Lemon wrote: > On Feb 4, 2013, at 12:34 PM, Cameron Byrne wrote: >> If you cannot form an opinion, then do not form an opinion... > There is actually no benefit to any of us to try to form an opinion about the validity of any IPR claim. It is not we who would actually be responsible for deciding whether the IPR claim has been infringed if a claim of infringement were made. Indeed, in making such a determination we might expose ourselves to liability, should the court rule differently. > > So whether or not the working group decides to publish this as a BCP, the working group absolutely should not take a position on the validity of the IPR, as you have proposed it do. The IETF does not take a position on the validity of an ipr disclosure on a published or unpublished document. you as an individual may take any position you like. The question is, given the disclosure as it exits are we comfortable with the wglc/ietf lc decision to publish, do we not want it to be a bcp, or should it not be published? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From randy@psg.com Mon Feb 4 19:41:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8521F85F3 for ; Mon, 4 Feb 2013 19:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twd6-FqXlEwJ for ; Mon, 4 Feb 2013 19:41:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 62E2721F8682 for ; Mon, 4 Feb 2013 19:41:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U2ZPR-0007uE-Mt; Tue, 05 Feb 2013 03:41:25 +0000 Date: Tue, 05 Feb 2013 12:41:24 +0900 Message-ID: From: Randy Bush To: Ray Hunter In-Reply-To: <510FB937.40208@globis.net> References: <510FB937.40208@globis.net> 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: IETF v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience 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, 05 Feb 2013 03:41:26 -0000 > I have read this draft, and I don't particularly see in its current > form how it significantly advances our knowledge of operational > experience of NAT64 in a way that could be applied by other operators. marketing department of damaged operator will like it. but i doubt it is worth the fight over this one. those who drink the koolaid will continue to do so, and the others not. as it adds no new value or information, it will not influence their decisions. randy From nalini.elkins@insidethestack.com Mon Feb 4 20:20: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 0B7F021F8994 for ; Mon, 4 Feb 2013 20:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA9aMxxWnmRM for ; Mon, 4 Feb 2013 20:20:46 -0800 (PST) Received: from nm24-vm0.access.bullet.mail.sp2.yahoo.com (nm24-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0F65021F8992 for ; Mon, 4 Feb 2013 20:20:41 -0800 (PST) Received: from [98.139.44.97] by nm24.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 04:20:33 -0000 Received: from [98.139.44.89] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 04:20:33 -0000 Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 04:20:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 612974.2970.bm@omp1026.access.mail.sp2.yahoo.com Received: (qmail 83946 invoked by uid 60001); 5 Feb 2013 04:20:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360038033; bh=tf+XxkA8d4iJx4xnI/fhsrsp0c/WyWR2zkQSxOEwPEs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZQ40F59/9gR0aXHN8sQ8ULPkeAVoScg5b4boSO4L7n7JfQTEcCW7fuB8TLVcieG/uATZpTcChekz/EJ5pupZdMU5JuZuioBXv1M/gXHzxB1wRSEHTTMUU4bHqzgZZfbDpPzfiP8B8DqyOqNE17XS5Zi31onjRQmNDhbBYEI022s= X-YMail-OSG: OrRGpyAVM1lKFc7ekMTMldhMVtPn7rqBEOCF4eBQh9xWi1w .9wK3jbetgPDHXRBneAUYQ0IGumgG7Jxd6kCKk_kXMzaakeaykYGEmL96X8a nmodrlDkl8S5IFCfiwY9oFYTHh4t3U4J58eOUQ.SDj7yD06lbOHakik7zjYK CamW55Lx9dCkA9iWn6Jhfw7XXr3DHh_F7Q1N11WrrojczzFEqbDfkUkqm2zG 2sXRWM3_X4RsXvFMcHVaT5hryY_biGEc8R07kqkibMs2OeZM2EMflLPRzY7x LcygJ_bZh2NUHKJX6gniMZb9PiXlfuBpPs5GPSxR0Lw4zq8J3uPGmeU.cy5c Pa3UIMJksdvNI.3du77uK3uNHmdDEWFbSiWX44cpbFX84CuPTwOGb9MpKh1i Y5gB2_3ziLQ444UsRKiD.p2dW1eSwS.tEXgn2ie2OEnSB5fBHebv3x0CR3Dv vxtiVAOVIzaTqLPbauwoTvhuC58iXq3H2eXE__wj6mddG1WrB4o0ZNWRtSdR .cq7ZxgNvjIq0_ThCmgjOquOYyJx2sczKvB6lS8iCa4xigOTewLrp4LN1UCD KBlyNdqSNS.BRjGFHZ8is8jofCdb8e5qbCeZxUOvSz8I- Received: from [50.0.137.66] by web2809.biz.mail.ne1.yahoo.com via HTTP; Mon, 04 Feb 2013 20:20:32 PST X-Rocket-MIMEInfo: 001.001, RnJlZCwKClRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLiDCoEkgaGF2ZSBub3QgeWV0IGZpbmlzaGVkIGNvbXBsZXRlbHkgYW5hbHl6aW5nIHlvdXIgUkZDIGJ1dCBJIGhhdmUgc29tZSBxdWVzdGlvbnMgZm9yIHlvdToKCkluIHlvdXIgU0VBTCBSRkMsIHdvdWxkwqBhbiBJUElEIHdvdWxkIG9ubHkgZXhpc3QgaW4gdGhlIHR1bm5lbGVkIGhlYWRlciB1c2VkIHRvIHRyYXZlcnNlIHRoZSBNUExTIGJhY2tib25lIG5ldHdvcms_CgpXb3VsZCBldmVyeSBJUHY2IHBhY2tldCB0aGVuIG5lZWQgdGhpcyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> Message-ID: <1360038032.64563.YahooMailNeo@web2809.biz.mail.ne1.yahoo.com> Date: Mon, 4 Feb 2013 20:20:32 -0800 (PST) From: Nalini Elkins To: "Templin, Fred L" , "Ackermann, Michael" , IETF v6ops list In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 04:20:47 -0000 Fred,=0A=0AThanks so much for your comments. =A0I have not yet finished com= pletely analyzing your RFC but I have some questions for you:=0A=0AIn your = SEAL RFC, would=A0an IPID would only exist in the tunneled header used to t= raverse the MPLS backbone network?=0A=0AWould every IPv6 packet then need t= his header?=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.= =0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A----- Original Messag= e -----=0AFrom: "Templin, Fred L" =0ATo: "Ackerm= ann, Michael" ; IETF v6ops list =0ACc= : =0ASent: Monday, February 4, 2013 10:17 AM=0ASubject: Re: [v6ops] new dra= ft: draft-elkins-v6ops-ipv6-ipid-needed=0A=0AHi Michael,=0A=0AForgot to men= tion that here is another one you would want to cite:=0A=0Ahttp://datatrack= er.ietf.org/doc/rfc4963/=0A=0AThanks - Fred=0A=0A> -----Original Message---= --=0A> From: Ackermann, Michael [mailto:MAckermann@bcbsm.com]=0A> Sent: Mon= day, February 04, 2013 9:53 AM=0A> To: Templin, Fred L; IETF v6ops list=0A>= Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> = =0A> Thanks for your comments Fred!=0A> =0A> The first draft you reference = seems to highlight the need for an IPID=0A> field larger than 16 bits (v4) = or 32 bits (v6), due to the much faster=0A> networks we have today.=A0 We = agree and that is very lightly referenced in=0A> our RFC.=A0 The reason fo= r only lightly, is that we chose to focus on the=0A> need for IPID at all, = since many at the IETF did not agree this was an=0A> issue when we first in= troduced it.=A0 Our original proposal suggested going=0A> to 64 bits as pa= rt of the solution, but for now we have backed off on=0A> solutions and are= focused on convincing the IETF that the elimination of=0A> IPID as a diagn= ostic facility, would be bad for end user organizations.=0A> =0A> The secon= d draft you referenced is one I was not aware of but is very=0A> impressive= and well written!=A0 I know it was focused on tunnels and=0A> encapsulati= on, but among many other things it seems to promote the value=0A> of unique= ly identifying packets, in particular ones that could be=0A> duplicate, imp= roper or even malicious.=A0 =A0 If I am interpreting properly,=0A> then we = are in full agreement.=0A> =0A> Our main issue is that information such as = provided by IPID can be=0A> critical to reliably running sophisticated netw= orks today.=0A> =0A> Thanks again!=0A> =0A> Mike=0A> =0A> =0A> =0A> -----Or= iginal Message-----=0A> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@= ietf.org] On Behalf Of=0A> Templin, Fred L=0A> Sent: Monday, February 04, 2= 013 11:51 AM=0A> To: IETF v6ops list=0A> Subject: Re: [v6ops] new draft: dr= aft-elkins-v6ops-ipv6-ipid-needed=0A> =0A> Hi,=0A> =0A> Two drafts the auth= ors should be aware of are "Updated Specification of=0A> the IPv4 ID Field"= :=0A> =0A> https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-upda= te/=0A> =0A> and "The Subnetwork Encapsulation and Adapation Layer (SEAL)":= =0A> =0A> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/=0A> = =0A> The former is a revised specification of the use of the IPv4 ID field = and=0A> defines the cases in which the ID field does and does not contain u= seful=0A> information. The latter is a means for adding a 32-bit ID field d= uring=0A> encapsulation, where the ID appears in an extension header simila= r to the=0A> way the IPv6 fragment header currently appears.=0A> =0A> Point= being that the IPv4 ID was never intended for purposes such as=0A> ensurin= g uniqueness other than for the fragmentation and reassembly=0A> process. A= nd, for IPv6, there are already ways to add an ID to a packet if=0A> one is= needed.=0A> =0A> Thanks - Fred=0A> fred.l.templin@boeing.com=0A> _________= ______________________________________=0A> v6ops mailing list=0A> v6ops@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> =0A> =0A> The inf= ormation contained in this communication is highly confidential and=0A> is = intended solely for the use of the individual(s) to whom this=0A> communica= tion is directed. If you are not the intended recipient, you are=0A> hereby= notified that any viewing, copying, disclosure or distribution of=0A> this= information is prohibited. Please notify the sender, by electronic=0A> mai= l or telephone, of any unintended receipt and delete the original=0A> messa= ge without making any copies.=0A> =0A>=A0 Blue Cross Blue Shield of Michiga= n and Blue Care Network of Michigan are=0A> nonprofit corporations and inde= pendent licensees of the Blue Cross and=0A> Blue Shield Association.=0A____= ___________________________________________=0Av6ops mailing list=0Av6ops@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops=0A From phdgang@gmail.com Mon Feb 4 22:40: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 45B2621F8994 for ; Mon, 4 Feb 2013 22:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FQyPt4J0P+S for ; Mon, 4 Feb 2013 22:40:26 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id A99AD21F8934 for ; Mon, 4 Feb 2013 22:40:26 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id hg5so1657805qab.13 for ; Mon, 04 Feb 2013 22:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RIF+RxiLZ3aB9Kf1fNa98EDTsqlWWPKdAgseTMJPCWI=; b=vaRqo+qyzZMvGXJ8LWT4JJFJdhTtjUZ9EC1zDZxZ7hjllPb1eszZJF1x8Ss5E29xzm GvxWjd4++f8smIqv2knKDPE+Jsl8Ap15h7k4YR0mpaX2BFpAROyfW1NCJDlyQFdP+Qxc H1UNVizap+U6TO02mkTH+X3h/fUVdh067F5IJ5pvlTOvejoPFuBf57JZK/TZd/zWhIRm 9i+tP40yla68fHtgf4O01aIYuvT2MPrd+3lxwxg1Uf3QDYjJqh6BP9gVngdj2hMCQe5r /CRcqcRgb1XW3J2zLvXss8WVVdbkOpR9/NNgpV0y/upOi6DMw4gEDSJdK3q3Wp/CS2M9 4jHQ== MIME-Version: 1.0 X-Received: by 10.224.196.196 with SMTP id eh4mr19304272qab.68.1360046426169; Mon, 04 Feb 2013 22:40:26 -0800 (PST) Received: by 10.49.48.12 with HTTP; Mon, 4 Feb 2013 22:40:26 -0800 (PST) In-Reply-To: <510FB937.40208@globis.net> References: <510FB937.40208@globis.net> Date: Tue, 5 Feb 2013 14:40:26 +0800 Message-ID: From: GangChen To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, Ron Bonica , Fred Baker Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience 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, 05 Feb 2013 06:40:27 -0000 Hello Ray, 2013/2/4, Ray Hunter : > I have read this draft, and I don't particularly see in its current form > how it significantly advances our knowledge of operational experience of > NAT64 in a way that could be applied by other operators. > > When I compare it something like rfc3974 rfc5037 or rfc6586 I don't see > any detail of what was tested, tips or lists of features that worked as > expected, gotchas, common pitfalls to be avoided, configuration > information, additional algorithms, or open issues that the IETF or > manufacturers still need to address. What have been documented in the current draft is coming from several operators. That may slightly different from documenting experiences of particular testing. We may have different practices/experiments/configuration data, but have common understanding on NAT64 deployment. Therefore, the draft promotes specific behavior into the generalized statements/recommendations. This was clarified during past discussions http://www.ietf.org/mail-archive/web/v6ops/current/msg14678.html. We have changed the title to "NAT64 Deployment Considerations" in order to echo this point. Best Regards Gang > > Fred Baker wrote: >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience. 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 phdgang@gmail.com Mon Feb 4 22:42: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 ACC6721F854D for ; Mon, 4 Feb 2013 22:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQxeTAMn4LMT for ; Mon, 4 Feb 2013 22:42:26 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2299621F8545 for ; Mon, 4 Feb 2013 22:42:26 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id b12so2924618qca.4 for ; Mon, 04 Feb 2013 22:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SFefbrH/91vfQ/miwJnbR5rHC5J6DX/W3rt6nXEJSKI=; b=Edpu3ic7j4kKsLp8QKCwUc7V2eWB5oZ9Oiup2s4njOBSLvmu5sfmZFOT3VmG9oe0kl 4MJAR5XZUf9pAml0JxurVzIJD9FnWe0Yvb7MI7weAfoLL/6g8X1HslB5Nya8eDCARPPE 2ClBDbG0rQU9CHuFtGiRsmRqyz7L6cXxKn9v7EPu/HGaVVETflRdBNb32tNBe/GvWpum HnCmVR/P49t+tXQFpl+RQycDimpgZXXf207TnFOFto/oSIoVJaw4gTgsCdPUcOUwq0gY uYrxgILOOf76rNJODDNxdOWOMsCd4816Syi9UqylqX/cjOvq9Z1NgwDwKUk4rJgKXacB Tj7g== MIME-Version: 1.0 X-Received: by 10.49.71.204 with SMTP id x12mr22087407qeu.47.1360046545588; Mon, 04 Feb 2013 22:42:25 -0800 (PST) Received: by 10.49.48.12 with HTTP; Mon, 4 Feb 2013 22:42:25 -0800 (PST) In-Reply-To: References: <510FB937.40208@globis.net> Date: Tue, 5 Feb 2013 14:42:25 +0800 Message-ID: From: GangChen To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: Ray Hunter , IETF v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience 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, 05 Feb 2013 06:42:26 -0000 Hello Randy, 2013/2/5, Randy Bush : >> I have read this draft, and I don't particularly see in its current >> form how it significantly advances our knowledge of operational >> experience of NAT64 in a way that could be applied by other operators. > > marketing department of damaged operator will like it. > > but i doubt it is worth the fight over this one. those who drink the > koolaid will continue to do so, and the others not. as it adds no new > value or information, it will not influence their decisions. The goal of the document intents to include current NAT64 practices in a whole picture. I can't speak whether the document could influence other operator's decisions. Whereas, I have communicated with several ICP/ISPs on the considerations of current draft. They think it's easy for them to get information from a document to say what's should be aware/care, what's potential impacts if they decide to adopt NAT64 Their position quite conforms with the statement and believe those experiences worth to be documented to be informational for other operators serve as common understanding. The document is trying to consolidate those understanding systematically Best Regards Gang > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Mon Feb 4 23:01: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 0323221F8A1E for ; Mon, 4 Feb 2013 23:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nffS99s6FOLD for ; Mon, 4 Feb 2013 23:01:23 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89D21F8A1D for ; Mon, 4 Feb 2013 23:01:23 -0800 (PST) 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 r1571JC5069179 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 07:01:20 GMT (envelope-from joelja@bogus.com) Message-ID: <5110AE3A.6020201@bogus.com> Date: Mon, 04 Feb 2013 23:01:14 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Ackermann, Michael" , "Templin, Fred L" , IETF v6ops list References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 05 Feb 2013 07:01:20 +0000 (UTC) Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 07:01:24 -0000 On 2/4/13 9:53 AM, Ackermann, Michael wrote: > Thanks for your comments Fred! > > The first draft you reference seems to highlight the need for an IPID field larger than 16 bits (v4) or 32 bits (v6), due to the much faster networks we have today. We agree and that is very lightly referenced in our RFC. The reason for only lightly, is that we chose to focus on the need for IPID at all, since many at the IETF did not agree this was an issue when we first introduced it. Our original proposal suggested going to 64 bits as part of the solution, but for now we have backed off on solutions and are focused on convincing the IETF that the elimination of IPID as a diagnostic facility, would be bad for end user organizations. To be clear IPv6 never had an analogous facility except in the fragmentation header, so that state of affairs has been on the books for about 18 years. > > The second draft you referenced is one I was not aware of but is very impressive and well written! I know it was focused on tunnels and encapsulation, but among many other things it seems to promote the value of uniquely identifying packets, in particular ones that could be duplicate, improper or even malicious. If I am interpreting properly, then we are in full agreement. > > Our main issue is that information such as provided by IPID can be critical to reliably running sophisticated networks today. > > Thanks again! > > Mike > > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Monday, February 04, 2013 11:51 AM > To: IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > Hi, > > Two drafts the authors should be aware of are "Updated Specification of the IPv4 ID Field": > > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ > > and "The Subnetwork Encapsulation and Adapation Layer (SEAL)": > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > > The former is a revised specification of the use of the IPv4 ID field and defines the cases in which the ID field does and does not contain useful information. The latter is a means for adding a 32-bit ID field during encapsulation, where the ID appears in an extension header similar to the way the IPv6 fragment header currently appears. > > Point being that the IPv4 ID was never intended for purposes such as ensuring uniqueness other than for the fragmentation and reassembly process. And, for IPv6, there are already ways to add an ID to a packet if one is needed. > > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From touch@isi.edu Mon Feb 4 23:27: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 55CFA21F8605 for ; Mon, 4 Feb 2013 23:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.885 X-Spam-Level: X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ4RBeFm0aaK for ; Mon, 4 Feb 2013 23:27:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E164D21F8510 for ; Mon, 4 Feb 2013 23:27:32 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r157Q1dh001149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Feb 2013 23:26:10 -0800 (PST) Message-ID: <5110B40A.3080008@isi.edu> Date: Mon, 04 Feb 2013 23:26:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: joel jaeggli References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> In-Reply-To: <5110AE3A.6020201@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 07:27:33 -0000 Hi, all, On 2/4/2013 11:01 PM, joel jaeggli wrote: > On 2/4/13 9:53 AM, Ackermann, Michael wrote: >> Thanks for your comments Fred! >> >> The first draft you reference seems to highlight the need for an IPID >> field larger than 16 bits (v4) or 32 bits (v6), due to the much faster >> networks we have today. We agree and that is very lightly referenced >> in our RFC. The reason for only lightly, is that we chose to focus >> on the need for IPID at all, since many at the IETF did not agree this >> was an issue when we first introduced it. Our original proposal >> suggested going to 64 bits as part of the solution, but for now we >> have backed off on solutions and are focused on convincing the IETF >> that the elimination of IPID as a diagnostic facility, would be bad >> for end user organizations. > > To be clear IPv6 never had an analogous facility except in the > fragmentation header, so that state of affairs has been on the books for > about 18 years. It's also important to note that IPv4 networks have tolerated traffic with trivially repeating IDs for many years (from cellphones, in specific). We just convinced the IETF to catch up with that reality and to recognize that IPv4 IDs are unique only when fragmentation has already occurred or is possible, i.e., in a very similar way to IPv6. Any suggestion that these IDs need to be re-established for atomic packets (not fragmented, not fragmentable) is a step backwards. IMO, if you think it is important to have a diagnostic identifier, you really should create your own with the semantics you seek. ... >> Our main issue is that information such as provided by IPID can be >> critical to reliably running sophisticated networks today. How critical can it be if the ID is already not present or not unique in a lot of traffic? Joe From zhenkaiw@gmail.com Tue Feb 5 01:24: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 7697F21F87BB for ; Tue, 5 Feb 2013 01:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6nygthESEO7 for ; Tue, 5 Feb 2013 01:24:13 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 95ADD21F85D9 for ; Tue, 5 Feb 2013 01:24:13 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id o6so7682338oag.18 for ; Tue, 05 Feb 2013 01:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pevc0MUORgDiWrJrbYjq9PrvWqnlJqCCjGOZgEINWi0=; b=KjXb/qfDJ5rsTJ74ceOGkzg0LDoxYPTHN9JgIWWLQUMfr8PEeaAl0fYLkEETfDiK8W UT6okvAfEQF0DcDviuYT2FA+bIOHsBiLGqCxqvWdw5aaZeopTjehitYq3BE4x2EYKAhh svy5nqNdcNNiv+3aptvPXGGQejAnJc1+7Hnc36UTeaUTu052dd8xKmmOyYFF4pB1wcZU GGPSgzP0kF0+VXO3CW3AZUXCgUeIfouMctqQByMb+HCsUrRgHLj37uO8bzHv1tzEjpN3 WogZZNxzD8VUxW4hwVd+O0sznPhHOvLAnYXPmO6OwnDfe+lA9sodV1D9r7KID0OKIPLf GAtQ== MIME-Version: 1.0 X-Received: by 10.60.4.226 with SMTP id n2mr18779781oen.63.1360056253106; Tue, 05 Feb 2013 01:24:13 -0800 (PST) Received: by 10.182.80.42 with HTTP; Tue, 5 Feb 2013 01:24:12 -0800 (PST) In-Reply-To: <8C48B86A895913448548E6D15DA7553B767174@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B767174@xmb-rcd-x09.cisco.com> Date: Tue, 5 Feb 2013 17:24:12 +0800 Message-ID: From: Zhenkai Wang To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=e89a8ff1c714d7485004d4f6c568 Cc: "" Subject: Re: [v6ops] China Mobile's Statement about IPR related to draft-ietf-v6ops-464xlat-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, 05 Feb 2013 09:24:17 -0000 --e89a8ff1c714d7485004d4f6c568 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mr Fred: After we reasonably know the China Mobile=92s IPRs meeting the condition of Section 6 of the RFC 3979 "Intellectual Property Rights in IETF Technology", we will make disclosure update in accordance with the RFC 3979 for the http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09. The patent application CN200910085886.3 is still in the SIPO's examination process and the patent 200910085887.8 was granted at 2012.12.26, more details can be read from the SIPO=92s website. Best regards, ------------------------------ Wang Zhenkai IP Counsel | China Mobile Research Institute Office: +86 15801696688-35235 | Mobile: +8613810187794 | NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of China Mobile, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. 2013/2/3 Fred Baker (fred) > Mr Wang: > > I speak here as one of the chairs of v6ops. This is a formal question fro= m > the IETF to China Mobile, and the answer may affect how the IETF treats t= he > posted internet draft.. > > The question before the house is not whether China Mobile puts effort int= o > what it does; we assume that China Mobile does, just as we all do. The > question regards the substance of the IPR claim - what claims have been > allowed or filed for in the patent - and whether the claims apply to the > current version of the draft. The statements of IPR were on the -00 and -= 01 > versions of the draft, which changed materially before reaching its curre= nt > status. > > The draft proposes no new technology; if that were not true, this working > group could not, by charter, consider it. It depends on several other > technologies, notably > > https://tools.ietf.org/html/rfc6052 > 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. > Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=3D41849 byt= es) > (Updates RFC4291) (Status: PROPOSED STANDARD) > > https://tools.ietf.org/html/rfc6144 > 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. > Yin. April 2011. (Format: TXT=3D67181 bytes) (Status: INFORMATIONAL) > > https://tools.ietf.org/html/rfc6145 > 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April > 2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC2765) (Updated by > RFC6791) (Status: PROPOSED STANDARD) > > https://tools.ietf.org/html/rfc6146 > 6146 Stateful NAT64: Network Address and Protocol Translation from > IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van > Beijnum. April 2011. (Format: TXT=3D107954 bytes) (Status: PROPOSED > STANDARD) > > https://tools.ietf.org/html/rfc6147 > 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 > Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. va= n > Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Status: PROPOSED > STANDARD) > > plus several that are listed as "informative" in reading the document. (I > note that 6144 was overlooked in the bibliography of > draft-ietf-v6ops-464xlat). Hence, this draft is not about technology per > se, it is about the use of existing technology in a 3GPP network. Is Chin= a > Mobile's patent about the use of the technologies in a 3GPP network, or i= s > it on the technologies themselves? What is the substance of the IPR claim= ? > Does it apply to http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09? > > Fred Baker > co-chair, IETF IPv6 Operations Working Group > > On Jan 29, 2013, at 7:08 PM, Zhenkai Wang wrote: > > > Hello IETF, > > > > As a company, China Mobile has spent lots of efforts like expenditure o= f > man workforce, time, et al. on some technologies. We underline that > Intellectual property Rights (IPRs) are an important part of technologies= , > and also respect IPRs like other companies in the industry. > > > > The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is a > compliance with the rules of the IETF which are defined in RFC 3979, > "Intellectual Property Rights in IETF Technology." The licensing > declaration for this Document =91c) Reasonable and Non-Discriminatory Lic= ense > to All Implementers with Possible Royalty/Fee=92 made by China Mobile was= in > accordance with our corporate strategy, as well as industry practice. > > > > Best regards, > > > > Wang Zhengkai > > > > Wang Zhenkai > > IP Counsel | China Mobile Research Institute > > Office: +86 15801696688-35235 | Mobile: +8613810187794 | > > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. > > > > Confidentiality Notice: The information contained in this e-mail and an= y > accompanying attachment(s) is intended only for the use of the intended > recipient and may be confidential and/or privileged of China Mobile, its > subsidiaries and/or its affiliates. If any reader of this communication i= s > not the intended recipient, unauthorized use, forwarding, printing, > storing, disclosure or copying is strictly prohibited, and may be unlawfu= l. > If you have received this communication in error, please immediately noti= fy > the sender by return e-mail, and delete the original message and all copi= es > from your system. Thank you. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > --e89a8ff1c714d7485004d4f6c568 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Mr Fred: 

After we reasonably know the China Mobile’s IPRs meeting the condition of Section 6 of the = RFC 3979 "Intellectual Property Rights in IETF Technology", we will make disclosure update in accordance with the RFC 3979 for the http://tools.ietf.org/html/draft-ietf-v6= ops-464xlat-09.

The patent application CN200910085886.3 is still in the SIPO's examination process and the patent 200910085887.8 was gra= nted at 2012.12.26, more details can be read from the SIPO’s website.

 Best regards,


Wang Zhenkai

 IP Counsel | China Mobile Research Institute

Office: +86 15801696688-35235 | Mobile: +8613810187= 794 |

NO.32 Xuanwumen West Street,Xicheng D= istrict,Beijing 100053.China.
 
Confidentiality Notice: The information contained in this e-mail and = any accompanying attachment(s) is intended only for the use of the intended= recipient and may be confidential and/or privileged of China Mobile, its s= ubsidiaries and/or its affiliates. If any reader of this communication is n= ot the intended recipient, unauthorized use, forwarding, printing, storing,= disclosure or copying is strictly prohibited, and may be unlawful. If you = have received this communication in error, please immediately notify the se= nder by return e-mail, and delete the original message and all copies from = your system. Thank you.


2013/2/3 Fred Baker (fred) <fred@cisco.com= >
Mr Wang:

I speak here as one of the chairs of v6ops. This is a formal question from = the IETF to China Mobile, and the answer may affect how the IETF treats the= posted internet draft..

The question before the house is not whether China Mobile puts effort into = what it does; we assume that China Mobile does, just as we all do. The ques= tion regards the substance of the IPR claim - what claims have been allowed= or filed for in the patent - and whether the claims apply to the current v= ersion of the draft. The statements of IPR were on the -00 and -01 versions= of the draft, which changed materially before reaching its current status.=

The draft proposes no new technology; if that were not true, this working g= roup could not, by charter, consider it. It depends on several other techno= logies, notably

https://t= ools.ietf.org/html/rfc6052
6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M.
     Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TX= T=3D41849 bytes)
     (Updates RFC4291) (Status: PROPOSED STANDARD)

https://t= ools.ietf.org/html/rfc6144
6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K.
     Yin. April 2011. (Format: TXT=3D67181 bytes) (Status: I= NFORMATIONAL)

https://t= ools.ietf.org/html/rfc6145
6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April
     2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC2765) (= Updated by
     RFC6791) (Status: PROPOSED STANDARD)

https://t= ools.ietf.org/html/rfc6146
6146 Stateful NAT64: Network Address and Protocol Translation from
     IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, = I. van
     Beijnum. April 2011. (Format: TXT=3D107954 bytes) (Stat= us: PROPOSED
     STANDARD)

https://t= ools.ietf.org/html/rfc6147
6147 DNS64: DNS Extensions for Network Address Translation from IPv6
     Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Ma= tthews, I. van
     Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Statu= s: PROPOSED
     STANDARD)

plus several that are listed as "informative" in reading the docu= ment. (I note that 6144 was overlooked in the bibliography of draft-ietf-v6= ops-464xlat). Hence, this draft is not about technology per se, it is about= the use of existing technology in a 3GPP network. Is China Mobile's pa= tent about the use of the technologies in a 3GPP network, or is it on the t= echnologies themselves? What is the substance of the IPR claim? Does it app= ly to http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09?=

Fred Baker
co-chair, IETF IPv6 Operations Working Group

On Jan 29, 2013, at 7:08 PM, Zhenkai Wang <zhenkaiw@gmail.com> wrote:

> Hello IETF,
>
> As a company, China Mobile has spent lots of efforts like expenditure = of man workforce, time, et al. on some technologies. We underline that Inte= llectual property Rights (IPRs) are an important part of technologies, and = also respect IPRs like other companies in the industry.
>
> The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is a co= mpliance with the rules of the IETF which are defined in RFC 3979, "In= tellectual Property Rights in IETF Technology." The licensing declarat= ion for this Document ‘c) Reasonable and Non-Discriminatory License t= o All Implementers with Possible Royalty/Fee’ made by China Mobile wa= s in accordance with our corporate strategy, as well as industry practice.<= br> >
> Best regards,
>
> Wang Zhengkai
>
> Wang Zhenkai
>  IP Counsel | China Mobile Research Institute
> Office: +86 15801696688-35235 | Mobile: +8613810187794 |
> NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China.
>
> Confidentiality Notice: The information contained in this e-mail and a= ny accompanying attachment(s) is intended only for the use of the intended = recipient and may be confidential and/or privileged of China Mobile, its su= bsidiaries and/or its affiliates. If any reader of this communication is no= t the intended recipient, unauthorized use, forwarding, printing, storing, = disclosure or copying is strictly prohibited, and may be unlawful. If you h= ave received this communication in error, please immediately notify the sen= der by return e-mail, and delete the original message and all copies from y= our system. Thank you.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--e89a8ff1c714d7485004d4f6c568-- From ietfc@btconnect.com Tue Feb 5 02:24: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 7CF5821F868F; Tue, 5 Feb 2013 02:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ppy9+an5H1e; Tue, 5 Feb 2013 02:24:13 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id B95CB21F8682; Tue, 5 Feb 2013 02:24:13 -0800 (PST) Received: from mail141-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Feb 2013 10:24:12 +0000 Received: from mail141-tx2 (localhost [127.0.0.1]) by mail141-tx2-R.bigfish.com (Postfix) with ESMTP id B90052E0A1B; Tue, 5 Feb 2013 10:24:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz9371I542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h304l1155h) Received: from mail141-tx2 (localhost.localdomain [127.0.0.1]) by mail141-tx2 (MessageSwitch) id 1360059851298299_32241; Tue, 5 Feb 2013 10:24:11 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.235]) by mail141-tx2.bigfish.com (Postfix) with ESMTP id 444BA40007C; Tue, 5 Feb 2013 10:24:11 +0000 (UTC) Received: from AMXPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.69) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Feb 2013 10:24:08 +0000 Received: from DBXPRD0611HT003.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.242.9.163) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 5 Feb 2013 10:24:00 +0000 Message-ID: <024901ce038a$7fdec880$4001a8c0@gateway.2wire.net> From: t.petch To: joel jaeggli , IPv6 Ops WG , Working Group Chairs References: <51100E9D.6050803@bogus.com> Date: Tue, 5 Feb 2013 10:20:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] X-OriginatorOrg: btconnect.com Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 10:24:15 -0000 publish as BCP. Tom Petch ----- Original Message ----- From: "joel jaeggli" To: "IPv6 Ops WG" ; "Working Group Chairs" Sent: Monday, February 04, 2013 7:40 PM > To emphasize Fred's request, please share you opinion on whether this > document should be published intact (as a BCP), with with a lower state > (informational), or not at all, given the IPR disclosure associated with it. > > The document can be reviewed here: > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > > the known IPR disclosure is here: > > https://datatracker.ietf.org/ipr/search/?option=document_search&document _search=draft-ietf-v6ops-464xlat > > if you have registered your opinion on this subject already you will be > counted. > > The deadline for commentary is Monday Feb 11th 2012. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fibrib@gmail.com Tue Feb 5 02:26: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 BE65621F8801; Tue, 5 Feb 2013 02:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7v-FxdPIkRh; Tue, 5 Feb 2013 02:26:39 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2AF21F8803; Tue, 5 Feb 2013 02:26:39 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wc20so7499610obb.29 for ; Tue, 05 Feb 2013 02:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BZKCCUAND59pyR3aPAISXC4h5OJ/OzyMYyEPm4f93IM=; b=wh7be+358XTlWiocMgJDC2xaQvNtPuwvUGNPk0RgzJ5+1bwbFSACJqHIuNp91sr59i gqvXIn+h2qwt/xPaxEmsVNm0D50wJyxrKqtHm8WYFJP/TReE14bmiTVWh4P4ZbmFy/kJ b1T6O6UdoXmw2MyyhJ/S34UVdkJGje5YQed4Xefj/pbo4QsODC4v4RjU7DMzGmO3cnz/ XaRWNMYzpRn5GnObAP5NodH9EAtnS+6ZPYnl8x8z+RlXqpvchfqlDEyFc9vl5lVOVaZ5 EkE6hdL84LuR4cRn1AV//LFiQy9FZl6Npmz8osUgrc8juSu/HZqZ8NXKHCRS7yii/0u6 n7ww== MIME-Version: 1.0 X-Received: by 10.60.27.228 with SMTP id w4mr5683625oeg.104.1360059998633; Tue, 05 Feb 2013 02:26:38 -0800 (PST) Received: by 10.76.154.8 with HTTP; Tue, 5 Feb 2013 02:26:38 -0800 (PST) In-Reply-To: <024901ce038a$7fdec880$4001a8c0@gateway.2wire.net> References: <51100E9D.6050803@bogus.com> <024901ce038a$7fdec880$4001a8c0@gateway.2wire.net> Date: Tue, 5 Feb 2013 19:26:38 +0900 Message-ID: From: Maoke To: "t.petch" Content-Type: multipart/alternative; boundary=e89a8fb1ea64177e4204d4f7a505 Cc: Working Group Chairs , IPv6 Ops WG Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 10:26:39 -0000 --e89a8fb1ea64177e4204d4f7a505 Content-Type: text/plain; charset=ISO-8859-1 2013/2/5 t.petch > publish as BCP. > +1 - Maoke Chen > > Tom Petch > > ----- Original Message ----- > From: "joel jaeggli" > To: "IPv6 Ops WG" ; "Working Group Chairs" > > Sent: Monday, February 04, 2013 7:40 PM > > > > To emphasize Fred's request, please share you opinion on whether this > > document should be published intact (as a BCP), with with a lower > state > > (informational), or not at all, given the IPR disclosure associated > with it. > > > > The document can be reviewed here: > > > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > > > > the known IPR disclosure is here: > > > > > https://datatracker.ietf.org/ipr/search/?option=document_search&document > _search=draft-ietf-v6ops-464xlat > > > > if you have registered your opinion on this subject already you will > be > > counted. > > > > The deadline for commentary is Monday Feb 11th 2012. > > > > _______________________________________________ > > 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 > --e89a8fb1ea64177e4204d4f7a505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2013/2/5 t.petch <<= a href=3D"mailto:ietfc@btconnect.com" target=3D"_blank">ietfc@btconnect.com= >
publish as BCP.

+1

- Maoke Chen
=A0

Tom Petch

----- Original Message -----
From: "joel jaeggli" <joel= ja@bogus.com>
To: "IPv6 Ops WG" <v6ops@iet= f.org>; "Working Group Chairs"
<wgchairs@ietf.org>
Sent: Monday, February 04, 2013 7:40 PM


> To emphasize Fred's request, please share you opinion on whether t= his
> document should be published intact (as a BCP), with with a lower
state
> (informational), or not at all, given the IPR disclosure associated with it.
>
> The document can be reviewed here:
>
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 >
> the known IPR disclosure is here:
>
>
http= s://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document<= br> _search=3Ddraft-ietf-v6ops-464xlat
>
> if you have registered your opinion on this subject already you will be
> counted.
>
> The deadline for commentary is Monday Feb 11th 2012.
>
> _______________________________________________
> 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

--e89a8fb1ea64177e4204d4f7a505-- From nick@inex.ie Tue Feb 5 02:43: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 17C3721F880B for ; Tue, 5 Feb 2013 02:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKlkurv-1O8Z for ; Tue, 5 Feb 2013 02:43:55 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8F121F8803 for ; Tue, 5 Feb 2013 02:43:48 -0800 (PST) X-Envelope-To: Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r15AfDZx062633 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 5 Feb 2013 10:41:14 GMT (envelope-from nick@inex.ie) Message-ID: <5110E25D.70801@inex.ie> Date: Tue, 05 Feb 2013 10:43:41 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <51100E9D.6050803@bogus.com> In-Reply-To: <51100E9D.6050803@bogus.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 10:43:56 -0000 On 04/02/2013 19:40, joel jaeggli wrote: > To emphasize Fred's request, please share you opinion on whether this > document should be published intact (as a BCP), with with a lower state > (informational), or not at all, given the IPR disclosure associated with it. As there IPR associated with this, my opinion is that it should not be published as a BCP. I'm specifically concerned about the cultural and legal differences in interpretation of RFC classifications in Roman Law derived areas (US / Europe / many other countries) vs China, where differences in technical standard classifications can have legal significance. Nick From ayourtch@cisco.com Tue Feb 5 02:56: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 83EC821F88F7 for ; Tue, 5 Feb 2013 02:56:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h271IZ-nT-bO for ; Tue, 5 Feb 2013 02:56:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7D03121F88ED for ; Tue, 5 Feb 2013 02:56:35 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15AuY7t006502 for ; Tue, 5 Feb 2013 11:56:34 +0100 (CET) Received: from dhcp-10-55-83-125.cisco.com (dhcp-10-55-83-125.cisco.com [10.55.83.125]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15AuWfi011843; Tue, 5 Feb 2013 11:56:33 +0100 (CET) Date: Tue, 5 Feb 2013 11:56:37 +0100 (CET) From: Andrew Yourtchenko To: Joe Touch In-Reply-To: <5110B40A.3080008@isi.edu> Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 10:56:36 -0000 Joe, as someone who repeatedly used the (trivially incrementing, non-necessarily-unique) IP ID to solve customer issues, I feel compelled to chime in with my 2 cents... On Mon, 4 Feb 2013, Joe Touch wrote: >> To be clear IPv6 never had an analogous facility except in the >> fragmentation header, so that state of affairs has been on the books for >> about 18 years. > > It's also important to note that IPv4 networks have tolerated traffic with > trivially repeating IDs for many years (from cellphones, in specific). As soon as it is not a constant number in all the packets, it can be good enough. > > We just convinced the IETF to catch up with that reality and to recognize > that IPv4 IDs are unique only when fragmentation has already occurred or is > possible, i.e., in a very similar way to IPv6. Any suggestion that these IDs > need to be re-established for atomic packets (not fragmented, not > fragmentable) is a step backwards. > > IMO, if you think it is important to have a diagnostic identifier, you really > should create your own with the semantics you seek. ...and convince everyone worldwide to put it into their endpoints. (*) The convenience of the IPv4 ID was that it was already there and it was reasonably well understood, had very few uses beyond frag/reasm, and was most frequently not touched by a lot of middleboxes that did the "fast switching" of the packets. Moreover, due to "insecure" mechanisms with which it was generated, sometimes you could infer about the other traffic the endpoint was generating. Handy. > > ... >>> Our main issue is that information such as provided by IPID can be >>> critical to reliably running sophisticated networks today. > > How critical can it be if the ID is already not present or not unique in a > lot of traffic? Does not matter. The use case for this is having two sniffer traces with 200 packets on one side, and 199 packets on the other side - and being able to quickly match by ID which packet did not make it; or by a series of mismatching IDs be able to say when a middlebox went into a "full proxy" mode as opposed to shuffling the packets around in fastpath with minor modifications. It did not have to be perfect to be good enough to save the day. That said - for IPv6 and ID, I think Elvis has left the building. Assuming everyone could make any changes to basic format or handling at this point is a bit unrealistic. I suppose all this means I agree with you, even for the entirely different set of reasons. :-) @authors: The above said, I think there is a good value in rephrasing the draft as "These are the use cases that were solved by the way IP ID was handled in IPv4. What can we come up with in IPv6 in order to get same or better ways to troubleshoot?", as opposed to asking for IP ID or its IPv6 twin immediately. In other words, do not come with a precompiled solution, but rather with a problem statement. And, use this draft to accumulate the use cases that were made simpler to debug with the IPv4 ID. Maybe there is a way to make it even better with IPv6... The solution you propose in the draft is not something I would advocate for - because if the header generation/consumption is optional, it will necessarily be done by a different code paths, and especially for this case I foresee more of heisenbugs than help for diagnostics. --a > > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ales.vizdal@t-mobile.cz Tue Feb 5 03:28: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 B162D21F86C8; Tue, 5 Feb 2013 03:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6i1mI-lARHy; Tue, 5 Feb 2013 03:28:18 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id CE6FA21F8619; Tue, 5 Feb 2013 03:28:16 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 799E9285804; Tue, 5 Feb 2013 12:28:14 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 5 Feb 2013 12:28:14 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: joel jaeggli , IPv6 Ops WG , Working Group Chairs Date: Tue, 5 Feb 2013 12:29:11 +0100 Thread-Topic: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4DD4k0rJYuCkoNSZGsDMy4HsPb1AAg/pVQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA87323@SRVHKE02.rdm.cz> References: <51100E9D.6050803@bogus.com> In-Reply-To: <51100E9D.6050803@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 11:28:18 -0000 I support this draft to be published as a BCP. Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= joel > jaeggli > Sent: Monday, February 04, 2013 8:40 PM > To: IPv6 Ops WG; Working Group Chairs > Subject: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination o= f Stateful > andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xl= at-09.txt) >=20 > To emphasize Fred's request, please share you opinion on whether this > document should be published intact (as a BCP), with with a lower state > (informational), or not at all, given the IPR disclosure associated with = it. >=20 > The document can be reviewed here: >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 >=20 > the known IPR disclosure is here: >=20 > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&documen= t_search=3Ddr > aft-ietf-v6ops-464xlat >=20 > if you have registered your opinion on this subject already you will be > counted. >=20 > The deadline for commentary is Monday Feb 11th 2012. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Tue Feb 5 03:28: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 452D921F87DC for ; Tue, 5 Feb 2013 03:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o0czlcSVAj8 for ; Tue, 5 Feb 2013 03:28:51 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 68E6921F885C for ; Tue, 5 Feb 2013 03:28:46 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r15BQCNh063122 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 11:26:12 GMT (envelope-from nick@inex.ie) Message-ID: <5110ECE7.3010900@inex.ie> Date: Tue, 05 Feb 2013 11:28:39 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Yourtchenko References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> In-Reply-To: X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 11:28:52 -0000 On 05/02/2013 10:56, Andrew Yourtchenko wrote: > The above said, I think there is a good value in rephrasing the draft as > "These are the use cases that were solved by the way IP ID was handled in > IPv4. What can we come up with in IPv6 in order to get same or better ways > to troubleshoot?", as opposed to asking for IP ID or its IPv6 twin > immediately. +1 Nick From ietfc@btconnect.com Tue Feb 5 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 E13A721F87A6 for ; Tue, 5 Feb 2013 04:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzQcGFE4IDMt for ; Tue, 5 Feb 2013 04:31:25 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 95C8521F87E1 for ; Tue, 5 Feb 2013 04:31:24 -0800 (PST) Received: from mail82-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Feb 2013 12:31:23 +0000 Received: from mail82-db3 (localhost [127.0.0.1]) by mail82-db3-R.bigfish.com (Postfix) with ESMTP id B6204420485; Tue, 5 Feb 2013 12:31:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(z5574mzbb2dI98dI9371Ic89bh542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahz8dhz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h304l1155h) Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3 (MessageSwitch) id 1360067481743003_26064; Tue, 5 Feb 2013 12:31:21 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.237]) by mail82-db3.bigfish.com (Postfix) with ESMTP id A5F76C004E; Tue, 5 Feb 2013 12:31:21 +0000 (UTC) Received: from AMSPRD0710HT003.eurprd07.prod.outlook.com (157.56.249.85) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Feb 2013 12:31:19 +0000 Received: from DBXPRD0411HT005.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.160.166) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 5 Feb 2013 12:31:18 +0000 Message-ID: <00f301ce039c$480b3a80$4001a8c0@gateway.2wire.net> From: t.petch To: Zhenkai Wang References: <8C48B86A895913448548E6D15DA7553B767174@xmb-rcd-x09.cisco.com> Date: Tue, 5 Feb 2013 12:27:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.165] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops@ietf.org Subject: Re: [v6ops] China Mobile's Statement about IPR related todraft-ietf-v6ops-464xlat-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, 05 Feb 2013 12:31:26 -0000 Thank you for the additional information. You posted a response to this list on 31st January which referred to a disclosure http://datatracker.ietf.org/ipr/1730/ which in turn refers to Application Number =EF=BC=9A200910088351.1 Publication Number =EF=BC=9ACN= 101931658 A The two numbers you give below seem to refer to a different Application, and so potentially, a different IPR Claim. Can you clarify this for us? Tom Petch ----- Original Message ----- From: "Zhenkai Wang" To: "Fred Baker (fred)" Cc: Sent: Tuesday, February 05, 2013 9:24 AM Mr Fred: After we reasonably know the China Mobile=E2=80=99s IPRs meeting the cond= ition of Section 6 of the RFC 3979 "Intellectual Property Rights in IETF Technology", we will make disclosure update in accordance with the RFC 3979 for the http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09. The patent application CN200910085886.3 is still in the SIPO's examination process and the patent 200910085887.8 was granted at 2012.12.26, more details can be read from the SIPO=E2=80=99s website. Best regards, ------------------------------ Wang Zhenkai IP Counsel | China Mobile Research Institute Office: +86 15801696688-35235 | Mobile: +8613810187794 | NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. 2013/2/3 Fred Baker (fred) > Mr Wang: > > I speak here as one of the chairs of v6ops. This is a formal question from > the IETF to China Mobile, and the answer may affect how the IETF treats the > posted internet draft.. > > The question before the house is not whether China Mobile puts effort into > what it does; we assume that China Mobile does, just as we all do. The > question regards the substance of the IPR claim - what claims have been > allowed or filed for in the patent - and whether the claims apply to the > current version of the draft. The statements of IPR were on the -00 and -01 > versions of the draft, which changed materially before reaching its current > status. > > The draft proposes no new technology; if that were not true, this working > group could not, by charter, consider it. It depends on several other > technologies, notably > > https://tools.ietf.org/html/rfc6052 > 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. > Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=3D41849 bytes) > (Updates RFC4291) (Status: PROPOSED STANDARD) > > https://tools.ietf.org/html/rfc6144 > 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. > Yin. April 2011. (Format: TXT=3D67181 bytes) (Status: INFORMATIONAL) > > https://tools.ietf.org/html/rfc6145 > 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April > 2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC2765) (Updated by > RFC6791) (Status: PROPOSED STANDARD) > > https://tools.ietf.org/html/rfc6146 > 6146 Stateful NAT64: Network Address and Protocol Translation from > IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van > Beijnum. April 2011. (Format: TXT=3D107954 bytes) (Status: PROPOSE= D > STANDARD) > > https://tools.ietf.org/html/rfc6147 > 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 > Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van > Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Status: PROPOSED > STANDARD) > > plus several that are listed as "informative" in reading the document. (I > note that 6144 was overlooked in the bibliography of > draft-ietf-v6ops-464xlat). Hence, this draft is not about technology per > se, it is about the use of existing technology in a 3GPP network. Is China > Mobile's patent about the use of the technologies in a 3GPP network, or is > it on the technologies themselves? What is the substance of the IPR claim? > Does it apply to http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09? > > Fred Baker > co-chair, IETF IPv6 Operations Working Group > > On Jan 29, 2013, at 7:08 PM, Zhenkai Wang wrote: > > > Hello IETF, > > > > As a company, China Mobile has spent lots of efforts like expenditure of > man workforce, time, et al. on some technologies. We underline that > Intellectual property Rights (IPRs) are an important part of technologies, > and also respect IPRs like other companies in the industry. > > > > The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is a > compliance with the rules of the IETF which are defined in RFC 3979, > "Intellectual Property Rights in IETF Technology." The licensing > declaration for this Document =E2=80=98c) Reasonable and Non-Discrimina= tory License > to All Implementers with Possible Royalty/Fee=E2=80=99 made by China Mo= bile was in > accordance with our corporate strategy, as well as industry practice. > > > > Best regards, > > > > Wang Zhengkai > > > > Wang Zhenkai > > IP Counsel | China Mobile Research Institute > > Office: +86 15801696688-35235 | Mobile: +8613810187794 | > > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. From brian.e.carpenter@gmail.com Tue Feb 5 04: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 4F06D21F87B3 for ; Tue, 5 Feb 2013 04:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyiOVpKQfiFc for ; Tue, 5 Feb 2013 04:48:09 -0800 (PST) Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2AA21F855C for ; Tue, 5 Feb 2013 04:48:08 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so91220wey.28 for ; Tue, 05 Feb 2013 04:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PnIvGfL1LnvoP6cfBij4jk2l1XSfqOfUt56S1uRayFM=; b=OUiLwURtFFwVMepOHNWGQlLXmVpTWdpbzC75Va1CuN7NB1PPNa8NCqEy8JnNH22EaG 7J6FoHJF145bu7A/6O9wd+Yr2G4Hay2JgY+U/gq8ghwTxCslAdGYvG3RllsgNFpxyOkK 9mJQxCy8d3o0Qp1rk1Rb9nz/3V2A7ERUoxdOjQwO68RKJQgGmg8YYPX/Q0DQOtQ0sUqc 4yKUrSoR94Z9l501fMj1KNGR/kEMI4gjhj1or37jnLu3Z9YpIURnswLuCsVdwz1sETDk jIbNAr9n73H4mPK7bhFqDpY25R3F7Rg3eyKCeU9ZV1n8I8NahErxlNuPmRspcud4PgTZ xa3A== X-Received: by 10.180.101.99 with SMTP id ff3mr17041597wib.21.1360068487528; Tue, 05 Feb 2013 04:48:07 -0800 (PST) Received: from [128.232.110.79] (c079.al.cl.cam.ac.uk. [128.232.110.79]) by mx.google.com with ESMTPS id b10sm1099037wix.7.2013.02.05.04.48.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 04:48:06 -0800 (PST) Message-ID: <5110FF8A.6000703@gmail.com> Date: Tue, 05 Feb 2013 12:48:10 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" References: <201301251345.r0PDj0f07997@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112E53A38@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Feb 2013 12:48:10 -0000 IMHO documenting this apparently successful approach as an Informational RFC is a fine thing to do. I don't see much point in debating this particular set of choices; in fact this could be a non-IETF Independent Submission RFC. I did wonder what the policy is for ICMPv6. RFC 4890? Brian On 25/01/2013 16:08, Eric Vyncke (evyncke) wrote: > Some explanations about this new draft... (which should also be of inte= rest to OPSEC WG) >=20 > IPv6 CPE have always the issue of the default security policy especiall= y around allowing inbound connections: > - Some say allow (fully open) to restore end-to-end > - Some say block (fully closed/valve like) to mimick the IPv4 NAPT stat= eful behavior. >=20 > RFC6092 describe a simple security policy for IPv6 CPE. Together with M= ark Townsley and Andrew Yourtchenko, we wrote the advanced-security draft= something in the line of fully open but use IPS in line (what is called = Universal Threat Mitigation) but this is expensive and the I-D did not ga= ther momentum. >=20 > This I-D is based on Swisscom deployment which is 'balanced' between op= en and close. It is simply allowing all traffic inbound EXCEPT for well-k= nown TCP/UDP ports linked to malware or vulnerable services. >=20 > The authors are the Swisscom engineers who initiated this balanced secu= rity and Ragnar from Altibox (a Norvegian ISP). >=20 > Hope this helps >=20 > -=C3=A9ric >=20 >> -----Original Message----- >> From: Fred Baker (fred) >> Sent: vendredi 25 janvier 2013 14:45 >> To: v6ops@ietf.org >> Cc: draft-v6ops-vyncke-balanced-ipv6-security@tools.ietf.org >> Subject: new draft: draft-v6ops-vyncke-balanced-ipv6-security >> >> >> A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops= - >> vyncke-balanced-ipv6-security. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From shane@castlepoint.net Tue Feb 5 06:17: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 CA78C21F859D for ; Tue, 5 Feb 2013 06:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwLY3gkVwEnz for ; Tue, 5 Feb 2013 06:17:33 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 31FDE21F8598 for ; Tue, 5 Feb 2013 06:17:33 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id A99B3300021 for ; Tue, 5 Feb 2013 14:17:32 +0000 (UTC) Received: from mbp.castlepoint.net (216-160-173-97.hlrn.qwest.net [216.160.173.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 6F90A300013 for ; Tue, 5 Feb 2013 07:17:32 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <5110ECE7.3010900@inex.ie> Date: Tue, 5 Feb 2013 07:17:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DE9D268-7785-4191-9460-6136A3A388AD@castlepoint.net> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <5110ECE7.3010900@inex.ie> To: IETF v6ops list X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Feb 5 07:17:32 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5111147c42077644249128 X-DSPAM-Factors: 27, On+#+#+#+10, 0.40000, solved+by, 0.40000, 2013+at, 0.40000, doesn't+#+in, 0.40000, to+#+#+#+to, 0.40000, numbers+#+#+good, 0.40000, were+#+#+the, 0.40000, made+#+#+#+your, 0.40000, UDP+#+#+#+really, 0.40000, ID+was, 0.40000, use+#+#+#+can, 0.40000, case+#+#+#+the, 0.40000, v6ops+mailing, 0.40000, Nick+Hilliard, 0.40000, way+#+#+was, 0.40000, that+#+solved, 0.40000, Feb+#+2013, 0.40000, twin+#+1, 0.40000, solved+#+#+#+IP, 0.40000, the+#+#+These, 0.40000, doesn't+help, 0.40000, 10+#+#+#+wrote, 0.40000, wrote+#+#+said, 0.40000, guarantee+#+#+not, 0.40000, to+#+same, 0.40000, These+#+#+use, 0.40000, your+#+#+s, 0.40000 Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 14:17:33 -0000 Question to the authors of this draft: why are TCP sequence numbers = insufficient for your use case(s)? Or, can TCP sequence numbers be made = "good enough" for your use case(s)? I realize the answer above doesn't help in the case of traffic = encapsulated in UDP; but, is that really critical to your use case(s)? = Given UDP does not provide any "ordering" guarantee/semantics, I'm not = sure that any such sequence numbers, at the Transport layer, would be = useful ... -shane On Feb 5, 2013, at 4:28 AM, Nick Hilliard wrote: > On 05/02/2013 10:56, Andrew Yourtchenko wrote: >> The above said, I think there is a good value in rephrasing the draft = as >> "These are the use cases that were solved by the way IP ID was = handled in >> IPv4. What can we come up with in IPv6 in order to get same or better = ways >> to troubleshoot?", as opposed to asking for IP ID or its IPv6 twin >> immediately. >=20 > +1 >=20 > Nick >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From evyncke@cisco.com Tue Feb 5 07:22: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 CDCD021F8552 for ; Tue, 5 Feb 2013 07:22:20 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyxhafVkvdvn for ; Tue, 5 Feb 2013 07:22:20 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DE81421F8550 for ; Tue, 5 Feb 2013 07:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1791; q=dns/txt; s=iport; t=1360077740; x=1361287340; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LXfYIyE7S1LIv/NMfPu+RCkVeeHbY+7hci9EnL6Srt4=; b=mU4LeB8oH4vYKKPzBJ9302y/3nT9yi9KHLYK71nzsSSSZAFgkHiGGYLj Q7u87W9KTOLx7oAYtHusyPk4FrUK7kZK/eJ49cEBBdY0wntFeC57Wh9jO bq36vNeEF8BcxjpoSMDdrsRLxDU9+MSvzsNUswsqs3if+0wy+TKUVP852 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHAjEVGtJV2Z/2dsb2JhbABEv2AWc4IfAQEBBAEBAWsLDAQCAQgRBAEBAQodBycLFAkIAgQBDQUIiAkMqiCQKASQemEDiDCKOJQLgn6CJA X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="173598775" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 05 Feb 2013 15:22:19 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r15FMJZK019269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 15:22:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 09:22:19 -0600 From: "Eric Vyncke (evyncke)" To: Shane Amante , IETF v6ops list Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuaGdae5cvHnEaCJh2EA8FKvphnJL+AgAAEcwCAAV8MgIAByViAgAARbACAANwoAIAABu4AgAA61oCAAAjzgIAALy6A//+tZDA= Date: Tue, 5 Feb 2013 15:21:27 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E112E632E4@xmb-aln-x02.cisco.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <5110ECE7.3010900@inex.ie> <3DE9D268-7785-4191-9460-6136A3A388AD@castlepoint.net> In-Reply-To: <3DE9D268-7785-4191-9460-6136A3A388AD@castlepoint.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.69] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-elkins-v6ops-ipv6-ipid-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 15:22:20 -0000 Or even atomic fragments (used in NAT64 scenario): where the fragmentation = header is always added with the flags set as being the first and last fragm= ent. Then, nothing to change except on the sender -=E9ric > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: mardi 5 f=E9vrier 2013 15:18 > To: IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > Question to the authors of this draft: why are TCP sequence numbers > insufficient for your use case(s)? Or, can TCP sequence numbers be made > "good enough" for your use case(s)? >=20 > I realize the answer above doesn't help in the case of traffic encapsulat= ed > in UDP; but, is that really critical to your use case(s)? Given UDP does > not provide any "ordering" guarantee/semantics, I'm not sure that any suc= h > sequence numbers, at the Transport layer, would be useful ... >=20 > -shane >=20 >=20 > On Feb 5, 2013, at 4:28 AM, Nick Hilliard wrote: > > On 05/02/2013 10:56, Andrew Yourtchenko wrote: > >> The above said, I think there is a good value in rephrasing the draft > >> as "These are the use cases that were solved by the way IP ID was > >> handled in IPv4. What can we come up with in IPv6 in order to get > >> same or better ways to troubleshoot?", as opposed to asking for IP ID > >> or its IPv6 twin immediately. > > > > +1 > > > > Nick > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Tue Feb 5 07:30:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1921F874E for ; Tue, 5 Feb 2013 07:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8clngYHpES3F for ; Tue, 5 Feb 2013 07:30:55 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3707D21F8716 for ; Tue, 5 Feb 2013 07:30:55 -0800 (PST) X-Envelope-To: Received: from crumpet.local ([IPv6:2001:1bb8:2004:200::180]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r15FSPQl021530 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 5 Feb 2013 15:28:25 GMT (envelope-from nick@inex.ie) Message-ID: <511125AC.9080802@inex.ie> Date: Tue, 05 Feb 2013 15:30:52 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <5110ECE7.3010900@inex.ie> <3DE9D268-7785-4191-9460-6136A3A388AD@castlepoint.net> <97EB7536A2B2C549846804BBF3FD47E112E632E4@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112E632E4@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 15:30:56 -0000 On 05/02/2013 15:21, Eric Vyncke (evyncke) wrote: > Or even atomic fragments (used in NAT64 scenario): where the fragmentation header is always added with the flags set as being the first and last fragment. Then, nothing to change except on the sender or (finally a use!) ipsec AH? Nick > -éric > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Shane Amante >> Sent: mardi 5 février 2013 15:18 >> To: IETF v6ops list >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >> >> Question to the authors of this draft: why are TCP sequence numbers >> insufficient for your use case(s)? Or, can TCP sequence numbers be made >> "good enough" for your use case(s)? >> >> I realize the answer above doesn't help in the case of traffic encapsulated >> in UDP; but, is that really critical to your use case(s)? Given UDP does >> not provide any "ordering" guarantee/semantics, I'm not sure that any such >> sequence numbers, at the Transport layer, would be useful ... >> >> -shane >> >> >> On Feb 5, 2013, at 4:28 AM, Nick Hilliard wrote: >>> On 05/02/2013 10:56, Andrew Yourtchenko wrote: >>>> The above said, I think there is a good value in rephrasing the draft >>>> as "These are the use cases that were solved by the way IP ID was >>>> handled in IPv4. What can we come up with in IPv6 in order to get >>>> same or better ways to troubleshoot?", as opposed to asking for IP ID >>>> or its IPv6 twin immediately. >>> >>> +1 >>> >>> Nick >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie From cpignata@cisco.com Tue Feb 5 07:36: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 6898421F8803 for ; Tue, 5 Feb 2013 07:36:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viZUeGnRWKvh for ; Tue, 5 Feb 2013 07:36:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 79FC421F8734 for ; Tue, 5 Feb 2013 07:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4187; q=dns/txt; s=iport; t=1360078608; x=1361288208; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/UsQ23S1hV/B9U4p/M6ugiX8L3lJ2DEtsdt9TQFr2kY=; b=G4HxwLnR+jS2x7Dovu+3eldXV4XhxwqZtCeSQ5IDJOkNIUZ5N6a0AHZb 1VpiM+jPOOtCYRZl9+rOPWqsXM/iBAAHxxTSKqiCd/fSWIyn6a6/prGQT yaHkSE6rrK/Q0KVwCNsYYfdbGnElsaKfTg4AMSspNb1vRnh9ssKKNiteP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABomEVGtJV2Z/2dsb2JhbABEDr9SFnOCHwEBAQQBAQE3NAsSAQgYChQ3CyUCBAENBQgBEod2DKomkCyNI4NXYQOSLjqUC4JAPoFvNQ X-IronPort-AV: E=Sophos;i="4.84,602,1355097600"; d="scan'208";a="173561752" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 05 Feb 2013 15:36:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r15FalmI010797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 15:36:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 09:36:47 -0600 From: "Carlos Pignataro (cpignata)" To: "Andrew Yourtchenko (ayourtch)" , Joe Touch Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOA494dpK/lUOAuEyb2D6L/4uSwJhrdtmA Date: Tue, 5 Feb 2013 15:35:54 +0000 Message-ID: <95067C434CE250468B77282634C96ED32291ED99@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.117.115.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D4AC6644083794F96FBBDA6F527A835@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 15:36:49 -0000 I very much agree with Andrew here, including the conclusion of the need for a problem statement. This thread reminded me of this other one http://www.ietf.org/mail-archive/web/v6ops/current/msg10266.html Thanks, -- Carlos. On 2/5/13 5:56 AM, "Andrew Yourtchenko (ayourtch)" wrote: >Joe, > >as someone who repeatedly used the (trivially incrementing, >non-necessarily-unique) IP ID to solve customer issues, I feel >compelled to chime in with my 2 cents... > >On Mon, 4 Feb 2013, Joe Touch wrote: > >>> To be clear IPv6 never had an analogous facility except in the >>> fragmentation header, so that state of affairs has been on the books >>>for >>> about 18 years. >> >> It's also important to note that IPv4 networks have tolerated traffic >>with=20 >> trivially repeating IDs for many years (from cellphones, in specific). > >As soon as it is not a constant number in all the packets, it can be good >enough. > >> >> We just convinced the IETF to catch up with that reality and to >>recognize=20 >> that IPv4 IDs are unique only when fragmentation has already occurred >>or is=20 >> possible, i.e., in a very similar way to IPv6. Any suggestion that >>these IDs=20 >> need to be re-established for atomic packets (not fragmented, not >> fragmentable) is a step backwards. >> >> IMO, if you think it is important to have a diagnostic identifier, you >>really=20 >> should create your own with the semantics you seek. > >...and convince everyone worldwide to put it into their endpoints. (*) > >The convenience of the IPv4 ID was that it was already there and it was >reasonably well understood, had very few uses beyond frag/reasm, and was >most frequently not touched by a lot of middleboxes that did the "fast >switching" of the packets. Moreover, due to "insecure" mechanisms with >which it was generated, sometimes you could infer about the other traffic >the endpoint was generating. Handy. > >> >> ... >>>> Our main issue is that information such as provided by IPID can be >>>> critical to reliably running sophisticated networks today. >> >> How critical can it be if the ID is already not present or not unique >>in a=20 >> lot of traffic? > >Does not matter. The use case for this is having two sniffer traces with >200 packets on one side, and 199 packets on the other side - and being >able to quickly match by ID which packet did not make it; or by a series >of mismatching IDs be able to say when a middlebox went into a "full >proxy" mode as opposed to shuffling the packets around in fastpath with >minor modifications. > >It did not have to be perfect to be good enough to save the day. > >That said - for IPv6 and ID, I think Elvis has left the building. >Assuming everyone could make any changes to basic format or handling at >this point is a bit unrealistic. > >I suppose all this means I agree with you, even for the entirely >different=20 >set of reasons. :-) > >@authors: > >The above said, I think there is a good value in rephrasing the draft as >"These are the use cases that were solved by the way IP ID was handled in >IPv4.=20 >What can we come up with in IPv6 in order to get same or better ways to >troubleshoot?", as opposed to asking for IP ID or its IPv6 twin >immediately. > >In other words, do not come with a precompiled solution, but rather with >a=20 >problem statement. And, use this draft to accumulate the use cases that >were made simpler to debug with the IPv4 ID. Maybe there is a way to make >it even better with IPv6... > >The solution you propose in the draft is not something I would advocate >for - because if the header generation/consumption is optional, it will >necessarily be done by a different code paths, and especially for this >case I foresee more of heisenbugs than help for diagnostics. > >--a > >> >> Joe >> _______________________________________________ >> 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 nalini.elkins@insidethestack.com Tue Feb 5 07: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 BEB4321F87CB for ; Tue, 5 Feb 2013 07:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZwXqnp11WCs for ; Tue, 5 Feb 2013 07:56:24 -0800 (PST) Received: from nm17.access.bullet.mail.mud.yahoo.com (nm17.access.bullet.mail.mud.yahoo.com [66.94.237.218]) by ietfa.amsl.com (Postfix) with ESMTP id C400221F8615 for ; Tue, 5 Feb 2013 07:56:23 -0800 (PST) Received: from [66.94.237.199] by nm17.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 15:56:23 -0000 Received: from [66.94.237.120] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 15:56:23 -0000 Received: from [127.0.0.1] by omp1025.access.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 15:56:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 289885.40928.bm@omp1025.access.mail.mud.yahoo.com Received: (qmail 85073 invoked by uid 60001); 5 Feb 2013 15:56:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360079782; bh=JWHuJptJUvcNzILSaNWfYKwA+coPOU7SeskRMzmZQxA=; 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=giNJUtsJksJlel+gHeqv+6Pgpr3Trd8MUSCvXdXJz5amV7DuxOoJ2E1aiOM3VVC/MI5B95Hm++ZMMfIiFYUeXGF/PO1x7WKcczeKIgEX5alYGxgi/j3fMwf8mdxfP0hsO8xA2eSRWisOL7KiF2MjAoYk/Y7YYqRllhrmsuCRKhI= X-YMail-OSG: Ei5QVygVM1nyIFckiCDA71pxScFChipWsVM6uT_vhe0RdLe Uhfvb9afp9qF0HlhILReOu_qVbwf8wxcpYTFiIUBYN86LDTHTP7eIMScRLqq 1WiL.9xWKo1exgMiHLOgfesZWKGIWtkP592ViBKd1LNHcM3ChqMX_vWkuzkI RMr5_kEd.iMzbQNuSavlRZBQ0crDM8A2wIa3lZk9UMIvq_TxP.LlwajRI_Zz RaQaQKFDBB5rJVhgqteZ5lYLN1Vr7o1QHtLdm6VZInThlUbyvDZc7DH3OswQ L2wZrrmaT04oRdueB0J9bhi7kAmCjSRvO6b7V3DfbzqKQOv8yb.k8bT0TYPQ ut0mVPxJPj98FypWQWPWFOv08eeCgd2ULqf0Ff.o9U6vTtiOILtcDAk_bnq9 rAjnO_G1WJtHmNHvwEG3JrPq.PMMYeSVrMPX5txhew4UDPD5aWGv0ZLQjvOJ SFC_qVM7T5cNdsBSVfUV0V8UE_6Ys7_m.4kD2lGgyuNAtLgPiv.s4361WddX eg3jarsa2LxQcBMNWbwUIY.JoO0TN8e5Rs0stHIuBWZ.C4xqmc9plKL0qknK BCjwl1GfvYncQ7y1TAAZerFHz6vi9y6O4hMF98uR7uQ-- Received: from [50.0.137.66] by web2816.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 07:56:22 PST X-Rocket-MIMEInfo: 001.001, RnJhZ21lbnRhdGlvbiBoZWFkZXIgYWx3YXlzIGFkZGVkIGlzIGEgZmluZSBzb2x1dGlvbi4gwqAgSSBiZWxpZXZlIHRoYXQgd2hhdCB3ZSBzZWVrIGlzIHN1cHBvcnQgZnJvbSBvdGhlciBJRVRGZXJzIG9uIHRoZSBldmVudHVhbCBzb2x1dGlvbiBhbmQgdGhlbiBpZiB3ZSBhbGwgYWdyZWUgb24gdGhpcyBhbmQgdGhlcmUgYXJlIG5vdCBzZWN1cml0eSBpbXBsaWNhdGlvbnMgdGhlbiB3ZSBjYW4gc3RhcnQgdG8gYXNrIHRoZSBzdGFjayB2ZW5kb3JzIHRvIGltcGxlbWVudCB0aGlzLiDCoArCoApUaGFua3MsCgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <5110ECE7.3010900@inex.ie> <3DE9D268-7785-4191-9460-6136A3A388AD@castlepoint.net> <97EB7536A2B2C549846804BBF3FD47E112E632E4@xmb-aln-x02.cisco.com> Message-ID: <1360079782.71129.YahooMailNeo@web2816.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 07:56:22 -0800 (PST) From: Nalini Elkins To: "Eric Vyncke \(evyncke\)" , Shane Amante , IETF v6ops list In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112E632E4@xmb-aln-x02.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-elkins-v6ops-ipv6-ipid-needed@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:56:24 -0000 Fragmentation header always added is a fine solution. =A0 I believe that wh= at we seek is support from other IETFers on the eventual solution and then = if we all agree on this and there are not security implications then we can= start to ask the stack vendors to implement this. =A0=0A=A0=0AThanks,=0A= =0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insideth= estack.com=0A=0A=0A=0A----- Original Message -----=0AFrom: Eric Vyncke (evy= ncke) =0ATo: Shane Amante ; IETF = v6ops list =0ACc: "draft-elkins-v6ops-ipv6-ipid-needed@tool= s.ietf.org" =0ASent: Tu= esday, February 5, 2013 7:21 AM=0ASubject: RE: [v6ops] new draft: draft-elk= ins-v6ops-ipv6-ipid-needed=0A=0AOr even atomic fragments (used in NAT64 sce= nario): where the fragmentation header is always added with the flags set a= s being the first and last fragment. Then, nothing to change except on the = sender=0A=0A-=E9ric=0A=0A> -----Original Message-----=0A> From: v6ops-bounc= es@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=0A> Shane Amante= =0A> Sent: mardi 5 f=E9vrier 2013 15:18=0A> To: IETF v6ops list=0A> Subject= : Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A> Quest= ion to the authors of this draft: why are TCP sequence numbers=0A> insuffic= ient for your use case(s)?=A0 Or, can TCP sequence numbers be made=0A> "goo= d enough" for your use case(s)?=0A> =0A> I realize the answer above doesn't= help in the case of traffic encapsulated=0A> in UDP; but, is that really c= ritical to your use case(s)?=A0 Given UDP does=0A> not provide any "orderin= g" guarantee/semantics, I'm not sure that any such=0A> sequence numbers, at= the Transport layer, would be useful ...=0A> =0A> -shane=0A> =0A> =0A> On = Feb 5, 2013, at 4:28 AM, Nick Hilliard wrote:=0A> > On 05/02= /2013 10:56, Andrew Yourtchenko wrote:=0A> >> The above said, I think there= is a good value in rephrasing the draft=0A> >> as "These are the use cases= that were solved by the way IP ID was=0A> >> handled in IPv4. What can we = come up with in IPv6 in order to get=0A> >> same or better ways to troubles= hoot?", as opposed to asking for IP ID=0A> >> or its IPv6 twin immediately.= =0A> >=0A> > +1=0A> >=0A> > Nick=0A> >=0A> > ______________________________= _________________=0A> > v6ops mailing list=0A> > v6ops@ietf.org=0A> > https= ://www.ietf.org/mailman/listinfo/v6ops=0A> >=0A> =0A> =0A> ________________= _______________________________=0A> v6ops mailing list=0A> v6ops@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/v6ops=0A From nalini.elkins@insidethestack.com Tue Feb 5 08:15: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 0584321F858E for ; Tue, 5 Feb 2013 08:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpU6jEJBnWBJ for ; Tue, 5 Feb 2013 08:15:45 -0800 (PST) Received: from nm17.access.bullet.mail.mud.yahoo.com (nm17.access.bullet.mail.mud.yahoo.com [66.94.237.218]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1E621F857D for ; Tue, 5 Feb 2013 08:15:45 -0800 (PST) Received: from [66.94.237.198] by nm17.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 16:15:44 -0000 Received: from [66.94.237.99] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 16:15:44 -0000 Received: from [127.0.0.1] by omp1004.access.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 16:15:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 837264.27918.bm@omp1004.access.mail.mud.yahoo.com Received: (qmail 91924 invoked by uid 60001); 5 Feb 2013 16:15:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360080944; bh=0l1B28Ad+orW58V1xRnnDvW3yX9oo0szIvnCg12+YH4=; 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=YZl+QOVOl9L2rcYVc6ix3ySep7xS/VWkkarEtpJRL2wFes9IK0/uz9gO+i9+4NDD6sgYqUBuzr40gQAUWHie46Dl+C4PziYnYZs/4+rPqGo328X2GTNFVfp6NnrodjIF3iQSWpKG5+RpQ8zHIzF2A5F86eNmSJOKcvAp0OfkdBM= X-YMail-OSG: P3sClz4VM1mszEc3jbAZzz3YeAjWaIBnAC2BnRhVLc7EWDo u5T_eK0OJeA_bY2mrHeQCi9UxhaMKCb.P9R1gvDLriQZr3QMPun.qyI1fJ6Z OXKeGjE.VjNY8GUtx_yTA5R5I5pHesFUdOACB3rwsQkMUg8mvZhrmMLg4U8y BbtBwyigf4GdK.Y6e20ahVVNgtsKhS9Hk34CeTAXNNnJAHWJMPwSK5tin075 yTgOjB6fnXLfiPLXlypCpv6A543m7IaCJzuw0UMq27ZEdpkOKpBNqHVIeFPM z_4FQLEGgMmxnK5n7LND0PROqOMDM8nNCcIPTJcVyWfJv229B1T2E5eUIGDP 7JUwTZ4kHdFoQ6y_0n5smqLwvbCVi_EZc_I1mQ6oSV8RL7qJTsJG4BrD7RLE bdlVOj2BGKBlP3Rmk8q3MunT4KfWbfltbxpr.tJAuJJDsphqcmxP0_jfDCx2 gqehKV880tkf9YoEh7rbWm5ns.bnQp0U7kJMyTSiRc8xMzB0rbnelieA6LcE TcdXWMl2dVTjgY60AB8LoQrrwC4nTuQDLQslJeRPgSeJHbWI3rp_GgEJ_RDK rhv4IApf1L9axUf76lWmDYKto_56VNGhbopcCfMxuRh1h.c6n9t9lRs372CT LvfDrpmwjddrndJ19rC2mysx_efPeTmkNyHyN4Bkrq4R.WWXn1TeWS1nn3nD 8_.De4I13J8KJxJRayqGS_pFI_gXjX4Ilr50wbilYKT0PsjhTb4bkc4itFdb 9M75UQFO.G2TcWnoV Received: from [50.0.137.66] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 08:15:43 PST X-Rocket-MIMEInfo: 001.001, UGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuCsKgClRoYW5rcywKCgpOYWxpbmkgRWxraW5zCkluc2lkZSBQcm9kdWN0cywgSW5jLgooODMxKSA2NTktODM2MAp3d3cuaW5zaWRldGhlc3RhY2suY29tCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBTaGFuZSBBbWFudGUgPHNoYW5lQGNhc3RsZXBvaW50Lm5ldD4KVG86IElFVEYgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc.IApTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA1LCAyMDEzIDY6MTcgQU0KU3ViamVjdDogUmU6IFsBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <5110ECE7.3010900@inex.ie> <3DE9D268-7785-4191-9460-6136A3A388AD@castlepoint.net> Message-ID: <1360080943.88810.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 08:15:43 -0800 (PST) From: Nalini Elkins To: Shane Amante , IETF v6ops list In-Reply-To: <3DE9D268-7785-4191-9460-6136A3A388AD@castlepoint.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-346525549-1360080943=:88810" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:15:46 -0000 ---1551098171-346525549-1360080943=:88810 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Please see my comments inline.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInsi= de Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A____= ____________________________=0A From: Shane Amante = =0ATo: IETF v6ops list =0ASent: Tuesday, February 5, 2013 = 6:17 AM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-need= ed=0A =0A> =A0Question to the authors of this draft: why are TCP sequence n= umbers insufficient for your use case(s)?=A0 Or, can TCP sequence numbers b= e made "good enough" for your use case(s)?=0A=0AThe reason TCP sequence num= bers (and hashing, for that matter) is not good enough is because there can= be valid duplicate TCP packets. =A0 These duplicates will have the same TC= P sequence and ack numbers. =A0Yes, TTL can be different but sometimes not.= =A0In diagnosing problems of congestion, it is important to know how many = duplicates there are so that you can see how bad the network flow is. =A0 I= have also worked on devices which provided packet traces and duplicated (f= alsely!) only certain packets.=0A=0AThe situation is often that by the time= my company is called in or, other of my compadres, the problem is quite se= rious. =A0Emotions are running high and the more evidence I have that certa= in packets are true duplicates and others coming from a 'spoofing' device i= n the middle of the path, etc, the better. =A0IPID has been quite helpful h= ere.=0A=0AAlso, changing how TCP sequence numbers are sent hardly seems eas= ier than a solution around IPID!=0A=0A>=A0I realize the answer above doesn'= t help in the case of traffic encapsulated in UDP; but, is that really crit= ical to your use case(s)?=A0 Given UDP does not provide any "ordering" guar= antee/semantics, I'm not sure that any such sequence numbers, at the Transp= ort layer, would be useful ...=0A=0AActually, we have had cases where we us= ed IPID to diagnose UDP traffic problems. =A0 In large end user companies, = UDP is used sometimes to encapsulate quite complex protocols such as High P= erformance Routing (HPR). (http://publib.boulder.ibm.com/infocenter/zos/bas= ics/index.jsp?topic=3D/com.ibm.zos.znetwork/znetwork_218.htm) =A0This is an= implementation used by IBM Enterprise Extender. =A0 Such packets do need t= o be in a sequence, etc. =A0The embedded protocol (RTP) is what does the se= quencing.=0A=0AUDP is rightfully used as it is lightweight and HPR is a ver= y comprehensive and complex protocol. =A0Having said that, sequencing and p= acket loss in HPR is extremely difficult to diagnose. =A0Again, we are look= ing for time savings here. =A0We have found IPID helpful to see where packe= ts are being lost and 'driving HPR crazy'!=0A=0A-shane=0A=0A=0AOn Feb 5, 20= 13, at 4:28 AM, Nick Hilliard wrote:=0A> On 05/02/2013 10:56= , Andrew Yourtchenko wrote:=0A>> The above said, I think there is a good va= lue in rephrasing the draft as=0A>> "These are the use cases that were solv= ed by the way IP ID was handled in=0A>> IPv4. What can we come up with in I= Pv6 in order to get same or better ways=0A>> to troubleshoot?", as opposed = to asking for IP ID or its IPv6 twin=0A>> immediately.=0A> =0A> +1=0A> =0A>= Nick=0A> =0A> _______________________________________________=0A> v6ops ma= iling list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6o= ps=0A> =0A=0A=0A_______________________________________________=0Av6ops mai= ling list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops ---1551098171-346525549-1360080943=:88810 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Please see my comment= s inline.
 
Thanks,

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

From:= Shane Amante <shane@castlepoint.net>
To: IETF v6ops list <v6ops@ietf.org&g= t;
Sent: Tuesday, Feb= ruary 5, 2013 6:17 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

>  Question to the authors of this draft: why are TCP sequence= numbers insufficient for your use case(s)?  Or, can TCP sequence numb= ers be made "good enough" for your use case(s)?

The reason TCP sequence numbers (and hashing, for that matte= r) is not good enough is because there can be valid duplicate TCP packets. =   These duplicates will have the same TCP sequence and ack numbers. &n= bsp;Yes, TTL can be different but sometimes not.  In diagnosing proble= ms of congestion, it is important to know how many duplicates there are so = that you can see how bad the network flow is.   I have also worked on = devices which provided packet traces and duplicated (falsely!) only certain packets.

The situation is often = that by the time my company is called in or, other of my compadres, the pro= blem is quite serious.  Emotions are running high and the more evidenc= e I have that certain packets are true duplicates and others coming from a = 'spoofing' device in the middle of the path, etc, the better.  IPID ha= s been quite helpful here.

Also, = changing how TCP sequence numbers are sent hardly seems easier than a solut= ion around IPID!

&= gt; I realize the answer above doesn't help in the case of traffic enc= apsulated in UDP; but, is that really critical to your use case(s)?  G= iven UDP does not provide any "ordering" guarantee/semantics, I'm not sure = that any such sequence numbers, at the Transport layer, would be useful ...=

Actually, we have had cases wher= e we used IPID to diagnose UDP traffic problems.   In large end user c= ompanies, UDP is used sometimes to encapsulate quite complex protocols such= as High Performance Routing (HPR). (http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=3D/co= m.ibm.zos.znetwork/znetwork_218.htm)  This is an implementation used b= y IBM Enterprise Extender.   Such packets do need to be in a sequence,= etc.  The embedded protocol (RTP) is what does the sequencing.
<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;" class=3D"yui_3_7_2_19_1360079170981_68">
UDP is rightfully used as it is lightwe= ight and HPR is a very comprehensive and complex protocol.  Having sai= d that, sequencing and packet loss in HPR is extremely difficult to diagnos= e.  Again, we are looking for time savings here.  We have found I= PID helpful to see where packets are being lost and 'driving HPR crazy'!

-shane

On Feb 5, 2013, at 4:28 AM, Nick Hilliard <nick@inex.ie> wrote:
>= ; On 05/02/2013 10:56, Andrew Yourtchenko wrote:
>> The above said= , I think there is a good value in rephrasing the draft as
>> "The= se are the use cases that were solved by the way IP ID was handled in
&g= t;> IPv4. What can we come up with in IPv6 in order to get same or bette= r ways
>> to troubleshoot?", as opposed to asking for IP ID or its= IPv6 twin
>> immediately.
>
> +1
>
> Ni= ck
>
> _______________________________________________
>= v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> =


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

---1551098171-346525549-1360080943=:88810-- From nalini.elkins@insidethestack.com Tue Feb 5 08:16: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 6178521F8906 for ; Tue, 5 Feb 2013 08:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaDMgEvTCmTh for ; Tue, 5 Feb 2013 08:16:20 -0800 (PST) Received: from nm6-vm0.access.bullet.mail.sp2.yahoo.com (nm6-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.114]) by ietfa.amsl.com (Postfix) with ESMTP id 730AF21F88B0 for ; Tue, 5 Feb 2013 08:16:20 -0800 (PST) Received: from [98.139.44.99] by nm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:16:16 -0000 Received: from [98.139.44.90] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:16:16 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:16:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 612921.87533.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 50262 invoked by uid 60001); 5 Feb 2013 16:16:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360080975; bh=nJMC2Dc7+QK2FSoUpiqTjT1+QdJelq27/hrsTHPn/ow=; 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=6JFh4CKBFsGn6CSlu1qNDtHRGgcNuusLJgQ5ao7ghLKs/FiwsBppACMt9n5qV7bgU73J2iPtq+a4F+vpXnJuvMRcofhWBYYgoTX4tr8TOR1r0LIF5cebuy+ThTnI9EVortTZhmg8zEUJLQvo0Fxq+uvo/l3v3qFESBGHHXdkVoQ= X-YMail-OSG: ewCgB5YVM1n4et2fOym1gk2FiNRyCcdhrcC.arMURomp2cy SPQNP9I9UyZOEjX_gPvx1hIZzuqCEN4IIStSzOuCoRSghotAsMLiCTPfze3D UCSYWfZCyAlZpZUPvHUZp7Gv4nFXXdRnAx99Q_OgSqmlWKjAeVlPzHmVTm1b l6xjQZH36IdWMmYSXSvpcLYy6ZdOj0aO6jvVoyO9vR4J2o1oNTZIPuoZJ6Xc CgoTFZnVgGRQ5lt03PhH.Ca3yFVjbpALNPpIKpKNMqJSznTI2RjpGuo.yCKN HrOdEd8.WXjVioESpRtj9EOmjcHBq6pl1Xv_2dVG8KqgnUrO1mKlXmKygZe5 zW.M9ugTeYexBYghz01BGaJcx02aQESl5_fuVbjZA3MYuek86vEtefTJWJR5 mZh1XUGMz0aaq2rGRqwVZg6YUKgLCdW3l8E0gk3CdCmGFpql0W7ItV2ZM.Sy LeSyCJiCnsvDh_.gAdbqrF0QAc4UBa.veYOPJLj4pX0haJLvwJ3O8lcSInUE ba3CzTJlYGNnI4cbTu093cqK6ChUtTqXwfHRdvV45byqpQuw9ZjbQgzStM6s VQyeKOfTq62zxEzSsRKPO3C6BgEiBvbWkKOSznNzvURXUJkI42dlU Received: from [50.0.137.66] by web2810.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 08:16:15 PST X-Rocket-MIMEInfo: 001.001, R3JlYXQgaWRlYSEgwqBUaGFua3MgZm9yIHRoZSBzdWdnZXN0aW9uLgrCoApUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogTmljayBIaWxsaWFyZCA8bmlja0BpbmV4LmllPgpUbzogQW5kcmV3IFlvdXJ0Y2hlbmtvIDxheW91cnRjaEBjaXNjby5jb20.IApDYzogSUVURiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4gClNlbnQ6IFQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <5110ECE7.3010900@inex.ie> Message-ID: <1360080975.14360.YahooMailNeo@web2810.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 08:16:15 -0800 (PST) From: Nalini Elkins To: Nick Hilliard , Andrew Yourtchenko In-Reply-To: <5110ECE7.3010900@inex.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="778264460-1228284886-1360080975=:14360" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:16:21 -0000 --778264460-1228284886-1360080975=:14360 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Great idea! =A0Thanks for the suggestion.=0A=A0=0AThanks,=0A=0A=0ANalini El= kins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A= =0A=0A=0A________________________________=0A From: Nick Hilliard =0ATo: Andrew Yourtchenko =0ACc: IETF v6ops list <= v6ops@ietf.org> =0ASent: Tuesday, February 5, 2013 3:28 AM=0ASubject: Re: [= v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A =0AOn 05/02/2013 1= 0:56, Andrew Yourtchenko wrote:=0A> The above said, I think there is a good= value in rephrasing the draft as=0A> "These are the use cases that were so= lved by the way IP ID was handled in=0A> IPv4. What can we come up with in = IPv6 in order to get same or better ways=0A> to troubleshoot?", as opposed = to asking for IP ID or its IPv6 twin=0A> immediately.=0A=0A+1=0A=0ANick=0A= =0A_______________________________________________=0Av6ops mailing list=0Av= 6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops --778264460-1228284886-1360080975=:14360 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Great idea!  Tha= nks for the suggestion.
 
Thanks= ,

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

From: Nick Hilliard <nick@inex.ie>
To: Andrew Yourtchenko <ayourtch@= cisco.com>
Cc: IETF= v6ops list <v6ops@ietf.org>
Sent: Tuesday, February 5, 2013 3:28 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-= ipid-needed

=0AOn 05/02/2013 10:56, Andrew Yourtchen= ko wrote:
> The above said, I think there is a good value in rephrasi= ng the draft as
> "These are the use cases that were solved by the wa= y IP ID was handled in
> IPv4. What can we come up with in IPv6 in or= der to get same or better ways
> to troubleshoot?", as opposed to ask= ing for IP ID or its IPv6 twin
> immediately.

+1

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

--778264460-1228284886-1360080975=:14360-- From mackermann@bcbsm.com Tue Feb 5 08:19: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 BDEC921F85A1 for ; Tue, 5 Feb 2013 08:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1yJ3T6DECbm for ; Tue, 5 Feb 2013 08:19:19 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id E3EC721F855C for ; Tue, 5 Feb 2013 08:19:14 -0800 (PST) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id D6D63136D3F for ; Tue, 5 Feb 2013 10:19:13 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id B84AC136D0D; Tue, 5 Feb 2013 10:19:12 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 181314F8051; Tue, 5 Feb 2013 11:17:50 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 044CB4F804D; Tue, 5 Feb 2013 11:17:50 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Tue, 5 Feb 2013 11:19:11 -0500 From: "Ackermann, Michael" To: joel jaeggli , "Templin, Fred L" , IETF v6ops list Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8CAATMIAIAAQkCg Date: Tue, 5 Feb 2013 16:19:11 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> In-Reply-To: <5110AE3A.6020201@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] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 16:19:20 -0000 Thanks Joel. Your comment highlights our more general issue, which is that large = enterprises are not very active at IETF, so would not see issues such as = this until they deploy IPV6 in production and have a problem where = facilities could be shown to be missing or inadequate. And yes, ideally = speaking, that is way to late in the process. =20 This issue is somewhat separate from our RFC, but is a situation we seek = to address by getting more large organizations involved in IETF. We = believe that would be a win/win situation, benefiting not only the large = organizations themselves, but IETF and networking in general as well=21=20 I hope you agree? Thanks again=21 Mike -----Original Message----- From: joel jaeggli =5Bmailto:joelja=40bogus.com=5D=20 Sent: Tuesday, February 05, 2013 2:01 AM To: Ackermann, Michael; Templin, Fred L; IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed On 2/4/13 9:53 AM, Ackermann, Michael wrote: > Thanks for your comments Fred=21 > > The first draft you reference seems to highlight the need for an IPID = field larger than 16 bits (v4) or 32 bits (v6), due to the much faster = networks we have today. We agree and that is very lightly referenced in = our RFC. The reason for only lightly, is that we chose to focus on the = need for IPID at all, since many at the IETF did not agree this was an = issue when we first introduced it. Our original proposal suggested going = to 64 bits as part of the solution, but for now we have backed off on = solutions and are focused on convincing the IETF that the elimination of = IPID as a diagnostic facility, would be bad for end user organizations. To be clear IPv6 never had an analogous facility except in the = fragmentation header, so that state of affairs has been on the books for = about 18 years. > > The second draft you referenced is one I was not aware of but is very = impressive and well written=21 I know it was focused on tunnels and = encapsulation, but among many other things it seems to promote the value = of uniquely identifying packets, in particular ones that could be = duplicate, improper or even malicious. If I am interpreting properly, = then we are in full agreement. > > Our main issue is that information such as provided by IPID can be = critical to reliably running sophisticated networks today. > > Thanks again=21 > > Mike > > > > -----Original Message----- > From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf=20 > Of Templin, Fred L > Sent: Monday, February 04, 2013 11:51 AM > To: IETF v6ops list > Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed > > Hi, > > Two drafts the authors should be aware of are =22Updated Specification = of the IPv4 ID Field=22: > > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ > > and =22The Subnetwork Encapsulation and Adapation Layer (SEAL)=22: > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > > The former is a revised specification of the use of the IPv4 ID field = and defines the cases in which the ID field does and does not contain = useful information. The latter is a means for adding a 32-bit ID field = during encapsulation, where the ID appears in an extension header similar = to the way the IPv6 fragment header currently appears. > > Point being that the IPv4 ID was never intended for purposes such as = ensuring uniqueness other than for the fragmentation and reassembly = process. And, for IPv6, there are already ways to add an ID to a packet if = one is needed. > > Thanks - Fred > fred.l.templin=40boeing.com > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. > =20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nalini.elkins@insidethestack.com Tue Feb 5 08:22:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441DC21F8939 for ; Tue, 5 Feb 2013 08:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcB6QdBBBl09 for ; Tue, 5 Feb 2013 08:22:01 -0800 (PST) Received: from nm23.access.bullet.mail.sp2.yahoo.com (nm23.access.bullet.mail.sp2.yahoo.com [98.139.44.150]) by ietfa.amsl.com (Postfix) with ESMTP id 129C421F8778 for ; Tue, 5 Feb 2013 08:21:59 -0800 (PST) Received: from [98.139.44.106] by nm23.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:21:59 -0000 Received: from [98.139.44.64] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:21:58 -0000 Received: from [127.0.0.1] by omp1001.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:21:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 806577.45107.bm@omp1001.access.mail.sp2.yahoo.com Received: (qmail 29751 invoked by uid 60001); 5 Feb 2013 16:21:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360081318; bh=OMGNWyZ+JUeqILSDNXxymt2FlkZggvzs/xyQq/9gFFE=; 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=wI5MhtXJKcm4mYKct+jevNey/c0KqYWfA629m7B0TQoSEsy+d89fFWLYlTNJaM25kw8qXz6maUKioSWax/VoBFSx6KZuJ00g+KIXYRpUCKKbrU8P2r7fuTFHNcHXmc/nW+gnYV6GKKbQciWKcCM4ZdZbQgAWxUCl37I89icXVac= X-YMail-OSG: QeTulZQVM1lfD0h8wUmfs5P8BApPkv3EuA4d0dZ4cj_H7NK 23PKdQ7cYuEpOJPWEUZc9A.tna9nvDJS.9UoiVjZNTaS14JWO5M.Zkm3Xf7Q GWoPL5S5xyZA2.S2BWPm5GpD6tzVP2XHAtjn13U82kesFNCFmLYldMooPiGo S3LTx1embPIDUtuK904NJR_OsU2lm2o46EW7P1xcOx6y2TFA2bTyOkQWAosD QlAaWKeWnGdxzBE0naFybyTLNTy7lPx0iffCMqzM2JWfrElkyq_Y7uf4R27F KiIyyQioK.ZR0Hqvs9_brSwC7tGCsJqscZ8w3HhIEB25EqRDh4gE7UpQI.dc _CcONmbIoA.tEllt8LQ6h.2p1SXX4MUHol6clTHEwsQ2PfoXb_v80pzdCqf0 5pRPSZ8coYx24evV9f1PKAyU1zfVMF.UDGFiB6X6CBM74OFudl6Tf8BDEJnN Gh_l_aTmd9LAMPTSAV4xXybZRlAhRe7t6KkMn1V535md.HR8jH4N7ddSqNpd 2a5sGdYTAAi7yPPvPJG.VCWIssJeZuSdMzr29uR6z2dLKygyOrxp0izFmvL5 f7I93sH0yMDHGihcnBikSOSf1WtwhRWLrHl.IhFTF Received: from [50.0.137.66] by web2807.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 08:21:57 PST X-Rocket-MIMEInfo: 001.001, QW5kcmV3LAoKSSB3b25kZXIgaWYgcG9zc2libGUgc29sdXRpb25zIGNhbiBiZSB3b3JrZWQgb3V0IGF0IGEgYnJhaW5zdG9ybWluZyBzZXNzaW9uIGF0IHRoZSBJRVRGIGluIE9ybGFuZG8uIMKgV2Ugd291bGQgbGlrZSB0byBnZXQgYSBncm91cCB0b2dldGhlciB0byB0aGluayBhYm91dCBzb2x1dGlvbnMgYmVjYXVzZSBJIGNhbiB0ZWxsIHlvdSwgd2UgaW50ZXJuYWxseSBoYXZlIGdvbmUgYXJvdW5kIHdpdGggZWFjaCBvdGhlciBvbiBkaWZmZXJlbnQgc29sdXRpb25zIGFuZCB0aGVpciBkcmF3YmFja3MhIAEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> Message-ID: <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 08:21:57 -0800 (PST) From: Nalini Elkins To: Andrew Yourtchenko , Joe Touch In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1742927040-929280582-1360081317=:11297" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:22:02 -0000 ---1742927040-929280582-1360081317=:11297 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Andrew,=0A=0AI wonder if possible solutions can be worked out at a brainsto= rming session at the IETF in Orlando. =A0We would like to get a group toget= her to think about solutions because I can tell you, we internally have gon= e around with each other on different solutions and their drawbacks! =A0Per= formance, security and implementation difficulties being some of the proble= ms involved.=0A=0AI will ask the chairs if we can have a BOF, if this is no= t possible, then maybe we can all find a venue with beer and chips availabl= e! =A0 I will post.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products= , Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______________= _________________=0A From: Andrew Yourtchenko =0ATo: Jo= e Touch =0ACc: IETF v6ops list =0ASent: Tu= esday, February 5, 2013 2:56 AM=0ASubject: Re: [v6ops] new draft: draft-elk= ins-v6ops-ipv6-ipid-needed=0A =0AJoe,=0A=0Aas someone who repeatedly used t= he (trivially incrementing, non-necessarily-unique) IP ID to solve customer= issues, I feel compelled to chime in with my 2 cents...=0A=0AOn Mon, 4 Feb= 2013, Joe Touch wrote:=0A=0A>> To be clear IPv6 never=A0 had an analogous = facility except in the=0A>> fragmentation header, so that state of affairs = has been on the books for=0A>> about 18 years.=0A> =0A> It's also important= to note that IPv4 networks have tolerated traffic with trivially repeating= IDs for many years (from cellphones, in specific).=0A=0AAs soon as it is n= ot a constant number in all the packets, it can be good enough.=0A=0A> =0A>= We just convinced the IETF to catch up with that reality and to recognize = that IPv4 IDs are unique only when fragmentation has already occurred or is= possible, i.e., in a very similar way to IPv6. Any suggestion that these I= Ds need to be re-established for atomic packets (not fragmented, not fragme= ntable) is a step backwards.=0A> =0A> IMO, if you think it is important to = have a diagnostic identifier, you really should create your own with the se= mantics you seek.=0A=0A...and convince everyone worldwide to put it into th= eir endpoints. (*)=0A=0AThe convenience of the IPv4 ID was that it was alre= ady there and it was reasonably well understood, had very few uses beyond f= rag/reasm, and was most frequently not touched by a lot of middleboxes that= did the "fast switching" of the packets. Moreover, due to "insecure" mecha= nisms with which it was generated, sometimes you could infer about the othe= r traffic the endpoint was generating. Handy.=0A=0A> =0A> ...=0A>>> Our mai= n issue is that information such as provided by IPID can be=0A>>> critical = to reliably running sophisticated networks today.=0A> =0A> How critical can= it be if the ID is already not present or not unique in a lot of traffic?= =0A=0ADoes not matter. The use case for this is having two sniffer traces w= ith 200 packets on one side, and 199 packets on the other side - and being = able to quickly match by ID which packet did not make it; or by a series of= mismatching IDs be able to say when a middlebox went into a "full proxy" m= ode as opposed to shuffling the packets around in fastpath with minor modif= ications.=0A=0AIt did not have to be perfect to be good enough to save the = day.=0A=0AThat said - for IPv6 and ID, I think Elvis has left the building.= =0AAssuming everyone could make any changes to basic format or handling at = this point is a bit unrealistic.=0A=0AI suppose all this means I agree with= you, even for the entirely different set of reasons. :-)=0A=0A@authors:=0A= =0AThe above said, I think there is a good value in rephrasing the draft as= "These are the use cases that were solved by the way IP ID was handled in = IPv4. What can we come up with in IPv6 in order to get same or better ways = to troubleshoot?", as opposed to asking for IP ID or its IPv6 twin immediat= ely.=0A=0AIn other words, do not come with a precompiled solution, but rath= er with a problem statement. And, use this draft to accumulate the use case= s that were made simpler to debug with the IPv4 ID. Maybe there is a way to= make it even better with IPv6...=0A=0AThe solution you propose in the draf= t is not something I would advocate for - because if the header generation/= consumption is optional, it will necessarily be done by a different code pa= ths, and especially for this case I foresee more of heisenbugs than help fo= r diagnostics.=0A=0A--a=0A=0A> =0A> Joe=0A> _______________________________= ________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.= ietf.org/mailman/listinfo/v6ops=0A> =0A____________________________________= ___________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/ma= ilman/listinfo/v6ops ---1742927040-929280582-1360081317=:11297 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Andrew,
<= div style=3D"color: rgb(0, 0, 0); font-size: 13.333333969116211px; font-fam= ily: arial, helvetica, sans-serif; background-color: transparent; font-styl= e: normal;">
I wonder if possible = solutions can be worked out at a brainstorming session at the IETF in Orlan= do.  We would like to get a group together to think about solutions be= cause I can tell you, we internally have gone around with each other on dif= ferent solutions and their drawbacks!  Performance, security and imple= mentation difficulties being some of the problems involved.

I will ask t= he chairs if we can have a BOF, if this is not possible, then maybe we can = all find a venue with beer and chips available!   I will post.<= /div>
 
Thanks,

Nalini Elki= ns
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com
=
<= hr size=3D"1"> From: Andre= w Yourtchenko <ayourtch@cisco.com>
To: Joe Touch <touch@isi.edu>
Cc: IETF v6ops list <v6ops@ietf.org&g= t;
Sent: Tuesday, Feb= ruary 5, 2013 2:56 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed

=0AJoe,

as someone who repeatedly used the (triviall= y incrementing, non-necessarily-unique) IP ID to solve customer issues, I f= eel compelled to chime in with my 2 cents...

On Mon, 4 Feb 2013, Joe= Touch wrote:

>> To be clear IPv6 never  had an analogous= facility except in the
>> fragmentation header, so that state of = affairs has been on the books for
>> about 18 years.
>
&= gt; It's also important to note that IPv4 networks have tolerated traffic w= ith trivially repeating IDs for many years (from cellphones, in specific).<= br>
As soon as it is not a constant number in all the packets, it can be= good enough.

>
> We just convinced the IETF to catch up w= ith that reality and to recognize that IPv4 IDs are unique only when fragme= ntation has already occurred or is possible, i.e., in a very similar way to= IPv6. Any suggestion that these IDs need to be re-established for atomic p= ackets (not fragmented, not fragmentable) is a step backwards.
>
> IMO, i= f you think it is important to have a diagnostic identifier, you really sho= uld create your own with the semantics you seek.

...and convince eve= ryone worldwide to put it into their endpoints. (*)

The convenience = of the IPv4 ID was that it was already there and it was reasonably well und= erstood, had very few uses beyond frag/reasm, and was most frequently not t= ouched by a lot of middleboxes that did the "fast switching" of the packets= . Moreover, due to "insecure" mechanisms with which it was generated, somet= imes you could infer about the other traffic the endpoint was generating. H= andy.

>
> ...
>>> Our main issue is that infor= mation such as provided by IPID can be
>>> critical to reliably= running sophisticated networks today.
>
> How critical can it= be if the ID is already not present or not unique in a lot of traffic?

Does not matter. The use case for this is having two sniff= er traces with 200 packets on one side, and 199 packets on the other side -= and being able to quickly match by ID which packet did not make it; or by = a series of mismatching IDs be able to say when a middlebox went into a "fu= ll proxy" mode as opposed to shuffling the packets around in fastpath with = minor modifications.

It did not have to be perfect to be good enough= to save the day.

That said - for IPv6 and ID, I think Elvis has lef= t the building.
Assuming everyone could make any changes to basic format= or handling at this point is a bit unrealistic.

I suppose all this = means I agree with you, even for the entirely different set of reasons. :-)=

@authors:

The above said, I think there is a good value in r= ephrasing the draft as "These are the use cases that were solved by the way= IP ID was handled in IPv4. What can we come up with in IPv6 in order to get same or better ways to troubleshoot?", as opposed to asking f= or IP ID or its IPv6 twin immediately.

In other words, do not come w= ith a precompiled solution, but rather with a problem statement. And, use t= his draft to accumulate the use cases that were made simpler to debug with = the IPv4 ID. Maybe there is a way to make it even better with IPv6...
The solution you propose in the draft is not something I would advocate f= or - because if the header generation/consumption is optional, it will nece= ssarily be done by a different code paths, and especially for this case I f= oresee more of heisenbugs than help for diagnostics.

--a

>=
> Joe
> _______________________________________________
&g= t; v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> =
_______________________________________________
v6ops mailing listv6ops= @ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


=
---1742927040-929280582-1360081317=:11297-- From joelja@bogus.com Tue Feb 5 08:28:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D6721F87CE for ; Tue, 5 Feb 2013 08:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAIKBmhHsWxG for ; Tue, 5 Feb 2013 08:28:43 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A89D521F845E for ; Tue, 5 Feb 2013 08:28:43 -0800 (PST) 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 r15GSf2D075791 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 16:28:41 GMT (envelope-from joelja@bogus.com) Message-ID: <51113334.2080500@bogus.com> Date: Tue, 05 Feb 2013 08:28:36 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Nalini Elkins , Andrew Yourtchenko , Joe Touch References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> In-Reply-To: <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 05 Feb 2013 16:28:42 +0000 (UTC) Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 16:28:44 -0000 On 2/5/13 8:21 AM, Nalini Elkins wrote: > Andrew, > > I wonder if possible solutions can be worked out at a brainstorming > session at the IETF in Orlando. We would like to get a group together > to think about solutions because I can tell you, we internally have > gone around with each other on different solutions and their > drawbacks! Performance, security and implementation difficulties > being some of the problems involved. > > I will ask the chairs if we can have a BOF, if this is not possible, > then maybe we can all find a venue with beer and chips available! I > will post. BOF(s) are scheduled by the IESG. You are free to schedule an informal meeting of interested parties whenever you choose. > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Andrew Yourtchenko > *To:* Joe Touch > *Cc:* IETF v6ops list > *Sent:* Tuesday, February 5, 2013 2:56 AM > *Subject:* Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > Joe, > > as someone who repeatedly used the (trivially incrementing, > non-necessarily-unique) IP ID to solve customer issues, I feel > compelled to chime in with my 2 cents... > > On Mon, 4 Feb 2013, Joe Touch wrote: > > >> To be clear IPv6 never had an analogous facility except in the > >> fragmentation header, so that state of affairs has been on the > books for > >> about 18 years. > > > > It's also important to note that IPv4 networks have tolerated > traffic with trivially repeating IDs for many years (from cellphones, > in specific). > > As soon as it is not a constant number in all the packets, it can be > good enough. > > > > > We just convinced the IETF to catch up with that reality and to > recognize that IPv4 IDs are unique only when fragmentation has already > occurred or is possible, i.e., in a very similar way to IPv6. Any > suggestion that these IDs need to be re-established for atomic packets > (not fragmented, not fragmentable) is a step backwards. > > > > IMO, if you think it is important to have a diagnostic identifier, > you really should create your own with the semantics you seek. > > ...and convince everyone worldwide to put it into their endpoints. (*) > > The convenience of the IPv4 ID was that it was already there and it > was reasonably well understood, had very few uses beyond frag/reasm, > and was most frequently not touched by a lot of middleboxes that did > the "fast switching" of the packets. Moreover, due to "insecure" > mechanisms with which it was generated, sometimes you could infer > about the other traffic the endpoint was generating. Handy. > > > > > ... > >>> Our main issue is that information such as provided by IPID can be > >>> critical to reliably running sophisticated networks today. > > > > How critical can it be if the ID is already not present or not > unique in a lot of traffic? > > Does not matter. The use case for this is having two sniffer traces > with 200 packets on one side, and 199 packets on the other side - and > being able to quickly match by ID which packet did not make it; or by > a series of mismatching IDs be able to say when a middlebox went into > a "full proxy" mode as opposed to shuffling the packets around in > fastpath with minor modifications. > > It did not have to be perfect to be good enough to save the day. > > That said - for IPv6 and ID, I think Elvis has left the building. > Assuming everyone could make any changes to basic format or handling > at this point is a bit unrealistic. > > I suppose all this means I agree with you, even for the entirely > different set of reasons. :-) > > @authors: > > The above said, I think there is a good value in rephrasing the draft > as "These are the use cases that were solved by the way IP ID was > handled in IPv4. What can we come up with in IPv6 in order to get same > or better ways to troubleshoot?", as opposed to asking for IP ID or > its IPv6 twin immediately. > > In other words, do not come with a precompiled solution, but rather > with a problem statement. And, use this draft to accumulate the use > cases that were made simpler to debug with the IPv4 ID. Maybe there is > a way to make it even better with IPv6... > > The solution you propose in the draft is not something I would > advocate for - because if the header generation/consumption is > optional, it will necessarily be done by a different code paths, and > especially for this case I foresee more of heisenbugs than help for > diagnostics. > > --a > > > > > Joe > > _______________________________________________ > > 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 Fred.L.Templin@boeing.com Tue Feb 5 08: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 0888921F8900 for ; Tue, 5 Feb 2013 08:36:23 -0800 (PST) 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.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-kpL10mlK4C for ; Tue, 5 Feb 2013 08:36:22 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27121F88FC for ; Tue, 5 Feb 2013 08:36:22 -0800 (PST) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r15GaLTk013326 for ; Tue, 5 Feb 2013 10:36:21 -0600 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r15GZTPY012220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Feb 2013 10:36:19 -0600 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Tue, 5 Feb 2013 08:36:05 -0800 From: "Templin, Fred L" To: Nalini Elkins , "Ackermann, Michael" , IETF v6ops list Date: Tue, 5 Feb 2013 08:36:04 -0800 Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: Ac4DWCW2BxEYmb5vTSev3QTkWUhXIgAZY2EA Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <1360038032.64563.YahooMailNeo@web2809.biz.mail.ne1.yahoo.com> In-Reply-To: <1360038032.64563.YahooMailNeo@web2809.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-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 16:36:23 -0000 Hi Nalini, > -----Original Message----- > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > Sent: Monday, February 04, 2013 8:21 PM > To: Templin, Fred L; Ackermann, Michael; IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > Fred, >=20 > Thanks so much for your comments. =A0I have not yet finished completely > analyzing your RFC but I have some questions for you: >=20 > In your SEAL RFC, would=A0an IPID would only exist in the tunneled header > used to traverse the MPLS backbone network? SEAL deals with IP-in-IP encapsulation. With SEAL, there is an outer IP header, a mid-layer SEAL header and an inner IP header. The outer IP header and SEAL header are only present over the portion of the path that traverses the region of encapsulation (aka the "tunnel"). The inner IP header is present over the full end-to-end path. > Would every IPv6 packet then need this header? Only those IPv6 packets that are taken in for encapsulation. Note that if you wanted to require all IPv6 packets to include a fragment header, there is a draft that talks about "atomic IPv6 fragments": https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ Thanks - Fred fred.l.templin@boeing.com =20 > Thanks, >=20 >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com >=20 >=20 >=20 > ----- Original Message ----- > From: "Templin, Fred L" > To: "Ackermann, Michael" ; IETF v6ops list > > Cc: > Sent: Monday, February 4, 2013 10:17 AM > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > Hi Michael, >=20 > Forgot to mention that here is another one you would want to cite: >=20 > http://datatracker.ietf.org/doc/rfc4963/ >=20 > Thanks - Fred >=20 > > -----Original Message----- > > From: Ackermann, Michael [mailto:MAckermann@bcbsm.com] > > Sent: Monday, February 04, 2013 9:53 AM > > To: Templin, Fred L; IETF v6ops list > > Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > > > Thanks for your comments Fred! > > > > The first draft you reference seems to highlight the need for an IPID > > field larger than 16 bits (v4) or 32 bits (v6), due to the much faster > > networks we have today.=A0 We agree and that is very lightly reference= d > in > > our RFC.=A0 The reason for only lightly, is that we chose to focus on = the > > need for IPID at all, since many at the IETF did not agree this was an > > issue when we first introduced it.=A0 Our original proposal suggested > going > > to 64 bits as part of the solution, but for now we have backed off on > > solutions and are focused on convincing the IETF that the elimination o= f > > IPID as a diagnostic facility, would be bad for end user organizations. > > > > The second draft you referenced is one I was not aware of but is very > > impressive and well written!=A0 I know it was focused on tunnels and > > encapsulation, but among many other things it seems to promote the valu= e > > of uniquely identifying packets, in particular ones that could be > > duplicate, improper or even malicious.=A0 =A0 If I am interpreting prop= erly, > > then we are in full agreement. > > > > Our main issue is that information such as provided by IPID can be > > critical to reliably running sophisticated networks today. > > > > Thanks again! > > > > Mike > > > > > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > > Templin, Fred L > > Sent: Monday, February 04, 2013 11:51 AM > > To: IETF v6ops list > > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > > > Hi, > > > > Two drafts the authors should be aware of are "Updated Specification of > > the IPv4 ID Field": > > > > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ > > > > and "The Subnetwork Encapsulation and Adapation Layer (SEAL)": > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > > > > The former is a revised specification of the use of the IPv4 ID field > and > > defines the cases in which the ID field does and does not contain usefu= l > > information. The latter is a means for adding a 32-bit ID field during > > encapsulation, where the ID appears in an extension header similar to > the > > way the IPv6 fragment header currently appears. > > > > Point being that the IPv4 ID was never intended for purposes such as > > ensuring uniqueness other than for the fragmentation and reassembly > > process. And, for IPv6, there are already ways to add an ID to a packet > if > > one is needed. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > The information contained in this communication is highly confidential > and > > is intended solely for the use of the individual(s) to whom this > > communication is directed. If you are not the intended recipient, you > are > > hereby notified that any viewing, copying, disclosure or distribution o= f > > 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. > > > >=A0 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan > are > > nonprofit corporations and independent licensees of the Blue Cross and > > Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Feb 5 08:48: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 BCE4521F8599 for ; Tue, 5 Feb 2013 08:48:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APUTt9+XIhcN for ; Tue, 5 Feb 2013 08:48:37 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id C3CD321F846B for ; Tue, 5 Feb 2013 08:48:37 -0800 (PST) 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 r15Gn1EJ024759 for ; Tue, 5 Feb 2013 08:49:01 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r15Gn0hD024747 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Feb 2013 08:49:00 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 5 Feb 2013 08:48:36 -0800 From: "Templin, Fred L" To: Nalini Elkins , "Ackermann, Michael" , IETF v6ops list Date: Tue, 5 Feb 2013 08:48:36 -0800 Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: Ac4DWCW2BxEYmb5vTSev3QTkWUhXIgAZY2EAAACYGWA= Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <1360038032.64563.YahooMailNeo@web2809.biz.mail.ne1.yahoo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 16:48:38 -0000 Following up on my own: > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Tuesday, February 05, 2013 8:36 AM > To: Nalini Elkins; Ackermann, Michael; IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > Hi Nalini, >=20 > > -----Original Message----- > > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > > Sent: Monday, February 04, 2013 8:21 PM > > To: Templin, Fred L; Ackermann, Michael; IETF v6ops list > > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > > > Fred, > > > > Thanks so much for your comments. =A0I have not yet finished completely > > analyzing your RFC but I have some questions for you: > > > > In your SEAL RFC, would=A0an IPID would only exist in the tunneled head= er > > used to traverse the MPLS backbone network? >=20 > SEAL deals with IP-in-IP encapsulation. With SEAL, there is an > outer IP header, a mid-layer SEAL header and an inner IP header. > The outer IP header and SEAL header are only present over the > portion of the path that traverses the region of encapsulation > (aka the "tunnel"). The inner IP header is present over the full > end-to-end path. SEAL is also compatible with a transport mode of operation in which the end systems would need to negotiate the use of a SEAL header that travels end-to end. Sort of how IPsec supports both tunnel- and transport modes of operation. Thanks - Fred fred.l.templin@boeing.com > > Would every IPv6 packet then need this header? >=20 > Only those IPv6 packets that are taken in for encapsulation. >=20 > Note that if you wanted to require all IPv6 packets to include a > fragment header, there is a draft that talks about "atomic IPv6 > fragments": >=20 > https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ >=20 >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Thanks, > > > > > > Nalini Elkins > > Inside Products, Inc. > > (831) 659-8360 > > www.insidethestack.com > > > > > > > > ----- Original Message ----- > > From: "Templin, Fred L" > > To: "Ackermann, Michael" ; IETF v6ops list > > > > Cc: > > Sent: Monday, February 4, 2013 10:17 AM > > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > > > Hi Michael, > > > > Forgot to mention that here is another one you would want to cite: > > > > http://datatracker.ietf.org/doc/rfc4963/ > > > > Thanks - Fred > > > > > -----Original Message----- > > > From: Ackermann, Michael [mailto:MAckermann@bcbsm.com] > > > Sent: Monday, February 04, 2013 9:53 AM > > > To: Templin, Fred L; IETF v6ops list > > > Subject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > > > > > Thanks for your comments Fred! > > > > > > The first draft you reference seems to highlight the need for an IPID > > > field larger than 16 bits (v4) or 32 bits (v6), due to the much faste= r > > > networks we have today.=A0 We agree and that is very lightly referen= ced > > in > > > our RFC.=A0 The reason for only lightly, is that we chose to focus o= n > the > > > need for IPID at all, since many at the IETF did not agree this was a= n > > > issue when we first introduced it.=A0 Our original proposal suggeste= d > > going > > > to 64 bits as part of the solution, but for now we have backed off on > > > solutions and are focused on convincing the IETF that the elimination > of > > > IPID as a diagnostic facility, would be bad for end user > organizations. > > > > > > The second draft you referenced is one I was not aware of but is very > > > impressive and well written!=A0 I know it was focused on tunnels and > > > encapsulation, but among many other things it seems to promote the > value > > > of uniquely identifying packets, in particular ones that could be > > > duplicate, improper or even malicious.=A0 =A0 If I am interpreting > properly, > > > then we are in full agreement. > > > > > > Our main issue is that information such as provided by IPID can be > > > critical to reliably running sophisticated networks today. > > > > > > Thanks again! > > > > > > Mike > > > > > > > > > > > > -----Original Message----- > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behal= f > > Of > > > Templin, Fred L > > > Sent: Monday, February 04, 2013 11:51 AM > > > To: IETF v6ops list > > > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > > > > > Hi, > > > > > > Two drafts the authors should be aware of are "Updated Specification > of > > > the IPv4 ID Field": > > > > > > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ > > > > > > and "The Subnetwork Encapsulation and Adapation Layer (SEAL)": > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > > > > > > The former is a revised specification of the use of the IPv4 ID field > > and > > > defines the cases in which the ID field does and does not contain > useful > > > information. The latter is a means for adding a 32-bit ID field durin= g > > > encapsulation, where the ID appears in an extension header similar to > > the > > > way the IPv6 fragment header currently appears. > > > > > > Point being that the IPv4 ID was never intended for purposes such as > > > ensuring uniqueness other than for the fragmentation and reassembly > > > process. And, for IPv6, there are already ways to add an ID to a > packet > > if > > > one is needed. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > The information contained in this communication is highly confidentia= l > > 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. > > > > > >=A0 Blue Cross Blue Shield of Michigan and Blue Care Network of Michig= an > > are > > > nonprofit corporations and independent licensees of the Blue Cross an= d > > > Blue Shield Association. > > _______________________________________________ > > 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 nalini.elkins@insidethestack.com Tue Feb 5 08:49: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 5873921F88E3 for ; Tue, 5 Feb 2013 08:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0acHHsZJviU for ; Tue, 5 Feb 2013 08:49:53 -0800 (PST) Received: from nm25-vm0.access.bullet.mail.sp2.yahoo.com (nm25-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.184]) by ietfa.amsl.com (Postfix) with ESMTP id 58AA821F889D for ; Tue, 5 Feb 2013 08:49:53 -0800 (PST) Received: from [98.139.44.96] by nm25.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:49:50 -0000 Received: from [98.139.44.90] by tm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:49:50 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 16:49:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 839092.88699.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 88446 invoked by uid 60001); 5 Feb 2013 16:49:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360082990; bh=8H0fSQand0u7d9EcUh5MlGnQ0HcnDUyU7Jq3nPHkwcI=; 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=TAglk68W49CrKkSxlW5jzWBbAeZwdy9C1nyfAKIzMnrPbrXZzU84PqgI3G4odxoZEokYUoAWQVZttz7ViClArIdF3Cd6BLMWa7u8rRC3r1x/AnCv+t+Q8bDIMVwTcn2b+qW1UEtX+CmFZgD98f+5kagdvTzR/y5WdgaHCr147co= X-YMail-OSG: 9gM34IwVM1nIKC8zPZaCQwJH5QDJTr.4oiToX5Gb2Vzr1Ae mi1ZUO7SzCM8W2XnKGMETRvTIVXTOHOAxAbmlVv5qgv7vaQJplAgqmGJqCuK 1YMKuBuNY8yA7fuGpPZLojzxEJrJWICVwc2p_tKK9KJVpjj8n3UIjA7jQ7_P uxLYFs7qAVSZLelWb9wuHQ7jKcWhO9S8HLMcGw4xNpJpKdl2FD8meOjX.0U9 pGl_6887cFGoZpyYDLbALUq0qbhrmHLzY0JBObBwHtOfK74C129QUg7hfZHQ 91W8ol46Mejgly_yOVh2XCb1g.b_9_AMCkK6yJYEkk1zbqLzQdlWpDb1gjfF 9NKgoilK2SOLvBtIPbiyN9xHGmQ7zPvrvI73pWt2GrWIP7kFHqR4YfT7iy.e vFrxFGDdpI5SUuRR.pHTZLwnJ7Ozct4NgNu0visTa3U.POZm.lgiy04JD0Ub n0UyzUGkuhIdaW5ct1DTX4Z2PnwI0.uXYjyUCh_9yXBSaQep0jzE4kLQGoen IN3HrFU193oq2wXu84_vmF0VL.XJ10Is3nc_7M4f8LegmCZyE9j1FoEjaR0V HQSumnWM_pI_8eBWLHQrFwZMXATkWyy27T2xPVnyQQiTTF9DoT1DD.w-- Received: from [50.0.137.66] by web2810.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 08:49:49 PST X-Rocket-MIMEInfo: 001.001, VGhhbmtzLCBGcmVkLiDCoAoKVGhlIGF0b21pYyBmcmFnbWVudHMgUkZDIG1heSBiZSB3aGF0IHNob3VsZCBiZSBwdXNoZWQgZm9yIGFkb3B0aW9uLiDCoEF0IHRoZSBzdGFnZSB3ZSBhcmUgbm93LCB0aGlzIG1heSBiZSBvbmUgb2YgdGhlIG9ubHkgdmlhYmxlIHNvbHV0aW9ucy4KwqAKCgpOYWxpbmkgRWxraW5zCkluc2lkZSBQcm9kdWN0cywgSW5jLgooODMxKSA2NTktODM2MAp3d3cuaW5zaWRldGhlc3RhY2suY29tCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiAiVGVtcGxpbiwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <1360038032.64563.YahooMailNeo@web2809.biz.mail.ne1.yahoo.com> Message-ID: <1360082989.88278.YahooMailNeo@web2810.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 08:49:49 -0800 (PST) From: Nalini Elkins To: "Templin, Fred L" , "Ackermann, Michael" , IETF v6ops list In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="778264460-1460189678-1360082989=:88278" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:49:54 -0000 --778264460-1460189678-1360082989=:88278 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Fred. =A0=0A=0AThe atomic fragments RFC may be what should be pushe= d for adoption. =A0At the stage we are now, this may be one of the only via= ble solutions.=0A=A0=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) = 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______________________________= __=0A From: "Templin, Fred L" =0ATo: Nalini Elki= ns ; "Ackermann, Michael" ; IETF v6ops list =0ASent: Tuesday, February 5, 201= 3 8:36 AM=0ASubject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-ne= eded=0A =0AHi Nalini,=0A=0A> -----Original Message-----=0A> From: Nalini El= kins [mailto:nalini.elkins@insidethestack.com]=0A> Sent: Monday, February 0= 4, 2013 8:21 PM=0A> To: Templin, Fred L; Ackermann, Michael; IETF v6ops lis= t=0A> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed= =0A> =0A> Fred,=0A> =0A> Thanks so much for your comments. =A0I have not ye= t finished completely=0A> analyzing your RFC but I have some questions for = you:=0A> =0A> In your SEAL RFC, would=A0an IPID would only exist in the tun= neled header=0A> used to traverse the MPLS backbone network?=0A=0ASEAL deal= s with IP-in-IP encapsulation. With SEAL, there is an=0Aouter IP header, a = mid-layer SEAL header and an inner IP header.=0AThe outer IP header and SEA= L header are only present over the=0Aportion of the path that traverses the= region of encapsulation=0A(aka the "tunnel"). The inner IP header is prese= nt over the full=0Aend-to-end path.=0A=0A> Would every IPv6 packet then nee= d this header?=0A=0AOnly those IPv6 packets that are taken in for encapsula= tion.=0A=0ANote that if you wanted to require all IPv6 packets to include a= =0Afragment header, there is a draft that talks about "atomic IPv6=0Afragme= nts":=0A=0Ahttps://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fra= gments/=0A=0A=0AThanks - Fred=0Afred.l.templin@boeing.com=0A=0A> Thanks,=0A= > =0A> =0A> Nalini Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> = www.insidethestack.com=0A> =0A> =0A> =0A> ----- Original Message -----=0A> = From: "Templin, Fred L" =0A> To: "Ackermann, Mic= hael" ; IETF v6ops list=0A> =0A> Cc:= =0A> Sent: Monday, February 4, 2013 10:17 AM=0A> Subject: Re: [v6ops] new d= raft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A> Hi Michael,=0A> =0A> For= got to mention that here is another one you would want to cite:=0A> =0A> ht= tp://datatracker.ietf.org/doc/rfc4963/=0A> =0A> Thanks - Fred=0A> =0A> > --= ---Original Message-----=0A> > From: Ackermann, Michael [mailto:MAckermann@= bcbsm.com]=0A> > Sent: Monday, February 04, 2013 9:53 AM=0A> > To: Templin,= Fred L; IETF v6ops list=0A> > Subject: RE: [v6ops] new draft: draft-elkins= -v6ops-ipv6-ipid-needed=0A> >=0A> > Thanks for your comments Fred!=0A> >=0A= > > The first draft you reference seems to highlight the need for an IPID= =0A> > field larger than 16 bits (v4) or 32 bits (v6), due to the much fast= er=0A> > networks we have today.=A0=A0 We agree and that is very lightly re= ferenced=0A> in=0A> > our RFC.=A0=A0 The reason for only lightly, is that w= e chose to focus on the=0A> > need for IPID at all, since many at the IETF = did not agree this was an=0A> > issue when we first introduced it.=A0=A0 Ou= r original proposal suggested=0A> going=0A> > to 64 bits as part of the sol= ution, but for now we have backed off on=0A> > solutions and are focused on= convincing the IETF that the elimination of=0A> > IPID as a diagnostic fac= ility, would be bad for end user organizations.=0A> >=0A> > The second draf= t you referenced is one I was not aware of but is very=0A> > impressive and= well written!=A0=A0 I know it was focused on tunnels and=0A> > encapsulati= on, but among many other things it seems to promote the value=0A> > of uniq= uely identifying packets, in particular ones that could be=0A> > duplicate,= improper or even malicious.=A0 =A0 If I am interpreting properly,=0A> > th= en we are in full agreement.=0A> >=0A> > Our main issue is that information= such as provided by IPID can be=0A> > critical to reliably running sophist= icated networks today.=0A> >=0A> > Thanks again!=0A> >=0A> > Mike=0A> >=0A>= >=0A> >=0A> > -----Original Message-----=0A> > From: v6ops-bounces@ietf.or= g [mailto:v6ops-bounces@ietf.org] On Behalf=0A> Of=0A> > Templin, Fred L=0A= > > Sent: Monday, February 04, 2013 11:51 AM=0A> > To: IETF v6ops list=0A> = > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> >= =0A> > Hi,=0A> >=0A> > Two drafts the authors should be aware of are "Updat= ed Specification of=0A> > the IPv4 ID Field":=0A> >=0A> > https://datatrack= er.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/=0A> >=0A> > and "The Sub= network Encapsulation and Adapation Layer (SEAL)":=0A> >=0A> > https://data= tracker.ietf.org/doc/draft-templin-intarea-seal/=0A> >=0A> > The former is = a revised specification of the use of the IPv4 ID field=0A> and=0A> > defin= es the cases in which the ID field does and does not contain useful=0A> > i= nformation. The latter is a means for adding a 32-bit ID field during=0A> >= encapsulation, where the ID appears in an extension header similar to=0A> = the=0A> > way the IPv6 fragment header currently appears.=0A> >=0A> > Point= being that the IPv4 ID was never intended for purposes such as=0A> > ensur= ing uniqueness other than for the fragmentation and reassembly=0A> > proces= s. And, for IPv6, there are already ways to add an ID to a packet=0A> if=0A= > > one is needed.=0A> >=0A> > Thanks - Fred=0A> > fred.l.templin@boeing.co= m=0A> > _______________________________________________=0A> > v6ops mailing= list=0A> > v6ops@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/v6op= s=0A> >=0A> >=0A> > The information contained in this communication is high= ly confidential=0A> and=0A> > is intended solely for the use of the individ= ual(s) to whom this=0A> > communication is directed. If you are not the int= ended recipient, you=0A> are=0A> > hereby notified that any viewing, copyin= g, disclosure or distribution of=0A> > this information is prohibited. Plea= se notify the sender, by electronic=0A> > mail or telephone, of any uninten= ded receipt and delete the original=0A> > message without making any copies= .=0A> >=0A> >=A0 Blue Cross Blue Shield of Michigan and Blue Care Network o= f Michigan=0A> are=0A> > nonprofit corporations and independent licensees o= f the Blue Cross and=0A> > Blue Shield Association.=0A> ___________________= ____________________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> = https://www.ietf.org/mailman/listinfo/v6ops --778264460-1460189678-1360082989=:88278 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Fred.  <= /span>

The atom= ic fragments RFC may be what should be pushed for adoption.  At the st= age we are now, this may be one of the only viable solutions.
<= div>
 


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

= From: "Templin, Fred L" &= lt;Fred.L.Templin@boeing.com>
= To: Nalini Elkins <nalini.elkins@insidethestack.com>; "Ack= ermann, Michael" <MAckermann@bcbsm.com>; IETF v6ops list <v6ops@ie= tf.org>
Sent: Tues= day, February 5, 2013 8:36 AM
Sub= ject: RE: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=

=0AHi Nalini,

> -----Original Message----= -
> From: Nalini Elkins [mailto:nalini.e= lkins@insidethestack.com]
> Sent: Monday, February 04, 2013 8:21 = PM
> To: Templin, Fred L; Ackermann, Michael; IETF v6ops list
>= Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
>= ;
> Fred,
>
> Thanks so much for your comments.  I= have not yet finished completely
> analyzing your RFC but I have som= e questions for you:
>
> In your SEAL RFC, would an IPID = would only exist in the tunneled header
> used to traverse the MPLS b= ackbone network?

SEAL deals with IP-in-IP encapsulation. With SEAL, = there is an
outer IP header, a mid-layer SEAL header and an inner IP hea= der.
The outer IP header and SEAL header are only present over the
po= rtion of the path that traverses the region of encapsulation
(aka the "tunnel"). The inner IP = header is present over the full
end-to-end path.

> Would every= IPv6 packet then need this header?

Only those IPv6 packets that are= taken in for encapsulation.

Note that if you wanted to require all = IPv6 packets to include a
fragment header, there is a draft that talks a= bout "atomic IPv6
fragments":

https://= datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/

=
Thanks - Fred
fred.l.templin@boeing.com
> Thanks,
>
>
> Nalini Elkins
> Inside Produc= ts, Inc.
> (831) 659-8360
> www.insidethestack.com
>
>
&= gt;
> ----- Original Message -----
> From: "Templin, Fred L" <= Fred.L.Templin@boeing.com>
> To: "Ackermann, Mi= chael" <MAckermann@bcbsm.com>; IETF v6ops list
> <<= a ymailto=3D"mailto:v6ops@ietf.org" href=3D"mailto:v6ops@ietf.org">v6ops@ie= tf.org>
> Cc:
> Sent: Monday, February 4, 2013 10:17 AM<= br>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=
>
> Hi Michael,
>
> Forgot to mention that here = is another one you would want to cite:
>
> http://datatracker.= ietf.org/doc/rfc4963/
>
> Thanks - Fred
>
> > = -----Original Message-----
> > From: Ackermann, Michael [mailto:MAckermann@bcbsm.com]
> >= ; Sent: Monday, February 04, 2013 9:53 AM
> > To: Templin, Fred L;= IETF v6ops list
> > Subject: RE: [v6ops] new draft: draft-elkins-= v6ops-ipv6-ipid-needed
> >
> > Thanks for your comments F= red!
> >
> > The first draft you reference seems to highl= ight the need for an IPID
> > field larger than 16 bits (v4) or 32= bits (v6), due to the much faster
> > networks we have today.&nbs= p;  We agree and that is very lightly referenced
> in
> &g= t; our RFC.   The reason for only lightly, is that we chose to fo= cus on the
> > need for IPID at all, since many at the IETF did no= t agree this was an
> > issue when we first introduced it. &n= bsp; Our original proposal suggested
> going
> > to 64 bits = as part of the solution, but for now we have backed off on
> > solutions and are focused on convincing the IETF that the elimination= of
> > IPID as a diagnostic facility, would be bad for end user o= rganizations.
> >
> > The second draft you referenced is = one I was not aware of but is very
> > impressive and well written= !   I know it was focused on tunnels and
> > encapsulati= on, but among many other things it seems to promote the value
> > = of uniquely identifying packets, in particular ones that could be
> &= gt; duplicate, improper or even malicious.    If I am interpretin= g properly,
> > then we are in full agreement.
> >
>= ; > Our main issue is that information such as provided by IPID can be> > critical to reliably running sophisticated networks today.
&= gt; >
> > Thanks again!
> >
> > Mike
> = >
> >
> >
> > -----Original Message-----
> > From: v6ops-bounces@ietf.org [mailt= o:v6ops-bounces@ietf.org] On Behalf
> Of
> > Te= mplin, Fred L
> > Sent: Monday, February 04, 2013 11:51 AM
>= > To: IETF v6ops list
> > Subject: Re: [v6ops] new draft: draf= t-elkins-v6ops-ipv6-ipid-needed
> >
> > Hi,
> ><= br>> > Two drafts the authors should be aware of are "Updated Specifi= cation of
> > the IPv4 ID Field":
> >
> > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-i= d-update/
> >
> > and "The Subnetwork Encapsulation a= nd Adapation Layer (SEAL)":
> >
> > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/<= /a>
> >
> > The former is a revised specification of the = use of the IPv4 ID field
> and
> > defines the cases in whic= h the ID field does and does not contain useful
> > information. T= he latter is a means for adding a 32-bit ID field during
> > encap= sulation, where the ID appears in an extension header similar to
> th= e
> > way the IPv6 fragment header currently appears.
> >=
> > Point being that the IPv4 ID was never intended for purposes = such as
> > ensuring uniqueness other than for the fragmentation a= nd reassembly
> > process. And, for IPv6, there are already ways t= o add an ID to a packet
> if
> > one is needed.
> >=
> > Thanks - Fred
> > fred.l.templin@boeing.com
> > ___________________= ____________________________
> > v6ops mailing list
> > <= a ymailto=3D"mailto:v6ops@ietf.org" href=3D"mailto:v6ops@ietf.org">v6ops@ie= tf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
&= gt; >
> >
> > The information contained in this commun= ication 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
> &= gt; hereby notified that any viewing, copying, disclosure or distribution o= f
> > this information is prohibited. Please notify the sender, by= electronic
> > mail or telephone, of any unintended receipt and d= elete the original
> > message without making any copies.
> ><= br>> >  Blue Cross Blue Shield of Michigan and Blue Care Network= of Michigan
> are
> > nonprofit corporations and independen= t licensees of the Blue Cross and
> > Blue Shield Association.
= > _______________________________________________
> v6ops mailing = list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=



--778264460-1460189678-1360082989=:88278-- From touch@isi.edu Tue Feb 5 08:51: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 2DC4921F8933 for ; Tue, 5 Feb 2013 08:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5dOkgkO7Aod for ; Tue, 5 Feb 2013 08:51:10 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA8421F8910 for ; Tue, 5 Feb 2013 08:51:10 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15Gotfd012519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 08:50:59 -0800 (PST) Message-ID: <51113872.6010603@isi.edu> Date: Tue, 05 Feb 2013 08:50:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nalini Elkins References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> In-Reply-To: <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 16:51:11 -0000 FWIW, there are two obvious solutions that work for both IPv4 and IPv6: 1) send fragmented (or fragmentable) packets presuming you have control over a source 2) compare either full packets or hashes of the full packets "convenience" of an existing field that is not always available isn't a solution. Joe From nalini.elkins@insidethestack.com Tue Feb 5 08: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 D029721F88E3 for ; Tue, 5 Feb 2013 08:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMQHr9fU5Mjl for ; Tue, 5 Feb 2013 08:56:19 -0800 (PST) Received: from nm8.access.bullet.mail.mud.yahoo.com (nm8.access.bullet.mail.mud.yahoo.com [66.94.237.209]) by ietfa.amsl.com (Postfix) with ESMTP id 17D5121F86E7 for ; Tue, 5 Feb 2013 08:56:19 -0800 (PST) Received: from [66.94.237.127] by nm8.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 16:56:18 -0000 Received: from [66.94.237.125] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 16:56:18 -0000 Received: from [127.0.0.1] by omp1030.access.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 16:56:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 638398.10587.bm@omp1030.access.mail.mud.yahoo.com Received: (qmail 80569 invoked by uid 60001); 5 Feb 2013 16:56:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360083378; bh=1r7qZ01Gsu9GqCaF1bA4dDRQ5xBtl/ti9g6wWavvOOk=; 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=YGeMJqCbwVRMkPg6KqOtYHiv1o8YX8XQBYFEpkgnbo9sCr5uEjS/7/3hp4m+7Dj7mfQcE7zKtDuq9TGTIfDTcQvOefoEZ/cPhqDUUB0yzCeYYjeV/bzbhK0RVpaMdcV6ylVdsW083YLOIbB6lrhC2hj6q9EOmiBnW3bA98zbqoQ= X-YMail-OSG: vZErITwVM1nkuDLST0LFRaV5uhp2gp4Uxi14vEVML6EguQg Ybn424.dqq.cSumbrOMsVLKzGZ7EO2Hkf3rZGXyWru2qYjpiAIxN.yyHMH5B vP171v3TzOES8h6gjJW1x4qCh4jH7yudvnsCPuNyQ3WZHzcGkIweRsWQLq5d jfSaHC6hcx2XDW04gX9cb3kW_Gsl1bnnAywNIenecggRw2h4Z4sUy_8B6ZCD _7U0.n0P9hxBN88wZDIDJZ8wZZSUPEO7T3mFPBhA.tAFzhrwSgHHzR7yf2ti cSMOLK_qeRpuzbYS54fRbywBtVw86fafYNZsAJqNNLBKhDnky.Np31fRb_Xk xpdrTfS.oXeu4ydpOkgLZMr3LFB7tAYgdArSLfEu3kWb01h4SawvA_JI42UP O6phXrche_rnzYZGX92HDzUjfei_NcPp6FxijrpAgrzkbIy03WCPpF5E_GAy IiMsoNxBJTSHHb0yELmIF276SZnkCTRR9scD7k4zod37L8yw2quQYPANmDFT IW.CvdrqcZaVJj9p2ndFOy_ecaGP19.vV7Tn9tj0f9H.OK2C5Q96YakikCyY ph70fbPgymUxCMe9DxlzGUoHvJIhjb6n6385MFkm2 Received: from [50.0.137.66] by web2813.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 08:56:18 PST X-Rocket-MIMEInfo: 001.001, Q29tcGFyaW5nIGhhc2hlcyBvciBwYWNrZXRzIGlzIG5vdCByZWFsbHkgYSB3b3JrYWJsZSBzb2x1dGlvbiBiZWNhdXNlIHRoZXJlIGNhbiBiZSB0cnVlIGR1cGxpY2F0ZSBwYWNrZXRzLiDCoEEgaGFzaCB3aWxsIG9ubHkgc2hvdyBpZiB0aGUgcGFja2V0cyBhcmUgdGhlIHNhbWUuIMKgIFVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLiDCoCBTb21ldGltZXMgdGhlIHByb2JsZW0gd2UgYXJlIHRyeWluZyB0byBkaWFnbm9zZSBpcyBob3cgbWFueSBkdXBsaWNhdGVzIHRoZXJlIGFyZS4gwqBUaGlzIGlzIGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> Message-ID: <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 08:56:18 -0800 (PST) From: Nalini Elkins To: Joe Touch In-Reply-To: <51113872.6010603@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1995203455-1729937817-1360083378=:11374" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:56:19 -0000 ---1995203455-1729937817-1360083378=:11374 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Comparing hashes or packets is not really a workable solution because there= can be true duplicate packets. =A0A hash will only show if the packets are= the same. =A0 Unless I am missing something. =A0 Sometimes the problem we = are trying to diagnose is how many duplicates there are. =A0This is an indi= cation of congestion. =A0 Some devices create 'false' duplicates. =A0That i= s a packet trace taken at that point will show that the packet is the same = but it is only the device or the trace mechanism tracing incorrectly. =A0Be= lieve me, this is not an infrequent problem.=0A=A0=0AThanks,=0A=0A=0ANalini= Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com= =0A=0A=0A=0A________________________________=0A From: Joe Touch =0ATo: Nalini Elkins =0ACc: Andrew Y= ourtchenko ; IETF v6ops list =0ASent: = Tuesday, February 5, 2013 8:50 AM=0ASubject: Re: [v6ops] new draft: draft-e= lkins-v6ops-ipv6-ipid-needed=0A =0AFWIW, there are two obvious solutions th= at work for both IPv4 and IPv6:=0A=0A1) send fragmented (or fragmentable) p= ackets=0A=A0=A0=A0 presuming you have control over a source=0A=0A2) compare= either full packets or hashes of the full packets=0A=0A"convenience" of an= existing field that is not always available isn't a solution.=0A=0AJoe ---1995203455-1729937817-1360083378=:11374 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Comparing hashes or p= ackets is not really a workable solution because there can be true duplicat= e packets.  A hash will only show if the packets are the same.   = Unless I am missing something.   Sometimes the problem we are trying t= o diagnose is how many duplicates there are.  This is an indication of= congestion.   Some devices create 'false' duplicates.  That is a= packet trace taken at that point will show that the packet is the same but= it is only the device or the trace mechanism tracing incorrectly.  Be= lieve me, this is not an infrequent problem.
&n= bsp;
Thanks,

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

From: Joe Touch <to= uch@isi.edu>
To: Na= lini Elkins <nalini.elkins@insidethestack.com>
Cc: Andrew Yourtchenko <ayourtch@cisco.co= m>; IETF v6ops list <v6ops@ietf.org>
Sent: Tuesday, February 5, 2013 8:50 AM
Subject: Re: [v6ops] new draft: = draft-elkins-v6ops-ipv6-ipid-needed

=0AFWIW, there a= re two obvious solutions that work for both IPv4 and IPv6:

1) send f= ragmented (or fragmentable) packets
    presuming you hav= e control over a source

2) compare either full packets or hashes of = the full packets

"convenience" of an existing field that is not alwa= ys available isn't a solution.

Joe


=
---1995203455-1729937817-1360083378=:11374-- From lee.howard@twcable.com Tue Feb 5 08:59: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 B35ED21F855C; Tue, 5 Feb 2013 08:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-R+h9JIV2Q5; Tue, 5 Feb 2013 08:59:38 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E014821F8526; Tue, 5 Feb 2013 08:59:37 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,609,1355115600"; d="scan'208";a="21689503" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 05 Feb 2013 11:59:16 -0500 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 5 Feb 2013 11:59:35 -0500 From: "Howard, Lee" To: t.petch , joel jaeggli , IPv6 Ops WG , Working Group Chairs Date: Tue, 5 Feb 2013 11:59:37 -0500 Thread-Topic: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4DwizKCaKPyVoMTjeqA1/zaxmheQ== Message-ID: In-Reply-To: <024901ce038a$7fdec880$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:59:38 -0000 Are you suggesting that 464xlat is a BCP, or that, if one is going to deploy 464xlat, this is the best practice on how to do so? Is there enough operational experience (among a diversity of operators) to know that this is a Best Current Practice? Or is this more of an operational report back to the IETF? Lee On 2/5/13 5:20 AM, "t.petch" wrote: >publish as BCP. > >Tom Petch > >----- Original Message ----- >From: "joel jaeggli" >To: "IPv6 Ops WG" ; "Working Group Chairs" > >Sent: Monday, February 04, 2013 7:40 PM > > >> To emphasize Fred's request, please share you opinion on whether this >> document should be published intact (as a BCP), with with a lower >state >> (informational), or not at all, given the IPR disclosure associated >with it. >> >> The document can be reviewed here: >> >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 >> >> the known IPR disclosure is here: >> >> >https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document >_search=3Ddraft-ietf-v6ops-464xlat >> >> if you have registered your opinion on this subject already you will >be >> counted. >> >> The deadline for commentary is Monday Feb 11th 2012. >> >> _______________________________________________ >> 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 touch@isi.edu Tue Feb 5 09: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 579E221F873B for ; Tue, 5 Feb 2013 09:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.743 X-Spam-Level: X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IalECRHDsioH for ; Tue, 5 Feb 2013 09:07:51 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 697B921F8700 for ; Tue, 5 Feb 2013 09:07:51 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15H7ak2017600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 09:07:39 -0800 (PST) Message-ID: <51113C5B.3000101@isi.edu> Date: Tue, 05 Feb 2013 09:07:39 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nalini Elkins References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> In-Reply-To: <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 17:07:52 -0000 On 2/5/2013 8:56 AM, Nalini Elkins wrote: > Comparing hashes or packets is not really a workable solution because > there can be true duplicate packets. A hash will only show if the > packets are the same. Unless I am missing something. You are correct. However, since the ID in IPv4 can (and is) repeated quickly, and because some sources just use a constant value, there's no loss of information. I.e., just because you see the same packet with the same ID doesn't mean it's a duplicate. > Sometimes the > problem we are trying to diagnose is how many duplicates there are. That's not always possible. > This is an indication of congestion. Duplication is an indication of many things, but congestion is indicated most accurately by loss, not duplication. > Some devices create 'false' > duplicates. That is a packet trace taken at that point will show that > the packet is the same but it is only the device or the trace mechanism > tracing incorrectly. Believe me, this is not an infrequent problem. If you see a lot of packets that are exactly the same in content and header then you probably do have a problem. In the end, such analysis is already based on statistics, so adjusting the statistics to account for the possibility of legitimate duplicate content shouldn't be a big deal. Joe > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* Nalini Elkins > *Cc:* Andrew Yourtchenko ; IETF v6ops list > > *Sent:* Tuesday, February 5, 2013 8:50 AM > *Subject:* Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > FWIW, there are two obvious solutions that work for both IPv4 and IPv6: > > 1) send fragmented (or fragmentable) packets > presuming you have control over a source > > 2) compare either full packets or hashes of the full packets > > "convenience" of an existing field that is not always available isn't a > solution. > > Joe > > From ayourtch@cisco.com Tue Feb 5 09:07: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 1EB9D21F88E5 for ; Tue, 5 Feb 2013 09:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf3gz-hgojvs for ; Tue, 5 Feb 2013 09:07:58 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1A31321F886A for ; Tue, 5 Feb 2013 09:07:57 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15H7tUs015996 for ; Tue, 5 Feb 2013 18:07:55 +0100 (CET) Received: from dhcp-10-55-83-125.cisco.com (dhcp-10-55-83-125.cisco.com [10.55.83.125]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15H7tA6027501; Tue, 5 Feb 2013 18:07:55 +0100 (CET) Date: Tue, 5 Feb 2013 18:08:01 +0100 (CET) From: Andrew Yourtchenko To: Nalini Elkins In-Reply-To: <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-833604554-1360084082=:24184" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 17:07:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-833604554-1360084082=:24184 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Nalini, On Tue, 5 Feb 2013, Nalini Elkins wrote: > Andrew, > > I wonder if possible solutions can be worked out at a brainstorming session at the IETF in Orlando.  We would like to get a group > together to think about solutions because I can tell you, we internally have gone around with each other on different solutions and > their drawbacks!  Performance, security and implementation difficulties being some of the problems involved. > > I will ask the chairs if we can have a BOF, if this is not possible, then maybe we can all find a venue with beer and chips > available!   I will post. I won't make it to Orlando, but I still think that we should try to squeeze as much of a problem space in terms of problem definition, and the qualities a potential solution should have, before going to define the solutions themselves. My quick sketch at how a potential solution's photorobot should look like, includes at least the following two traits: 1) be a property of every packet 2) be always present (i.e. not require a separate 'switch it on' knob that would trigger a different code path) 3) be frugal in terms of any packet space it occupies (0 bytes being the best) Probably there's a couple more - and then the rest of the traits should come out from the distilled use cases that the IP ID was used for. Such a list could then make a framework for evaluation of the potential solutions. --a --0-833604554-1360084082=:24184-- From ayourtch@cisco.com Tue Feb 5 09:22: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 2EC6321F846C for ; Tue, 5 Feb 2013 09:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll+gOZtNsSw2 for ; Tue, 5 Feb 2013 09:22:24 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B42B921F8468 for ; Tue, 5 Feb 2013 09:22:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15HMKwV017189 for ; Tue, 5 Feb 2013 18:22:20 +0100 (CET) Received: from dhcp-10-55-83-125.cisco.com (dhcp-10-55-83-125.cisco.com [10.55.83.125]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15HMJcm010787; Tue, 5 Feb 2013 18:22:19 +0100 (CET) Date: Tue, 5 Feb 2013 18:22:22 +0100 (CET) From: Andrew Yourtchenko To: Nalini Elkins In-Reply-To: <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-480988788-1360084947=:24184" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 17:22:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-480988788-1360084947=:24184 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Nalini, Joe, This two-mail exchange vividly illustrates why it's beneficial to describe the problem better, and the properties of the ideal solution (starting with that of IP ID, but not necessarily limited to it), but not jump to solutions themselves straight away. Otherwise it's too easy to get into a situation of a fish and a gull arguing about the sea water. --a On Tue, 5 Feb 2013, Nalini Elkins wrote: > Comparing hashes or packets is not really a workable solution because there can be true duplicate packets.  A hash will only show if > the packets are the same.   Unless I am missing something.   Sometimes the problem we are trying to diagnose is how many duplicates > there are.  This is an indication of congestion.   Some devices create 'false' duplicates.  That is a packet trace taken at that > point will show that the packet is the same but it is only the device or the trace mechanism tracing incorrectly.  Believe me, this > is not an infrequent problem. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ___________________________________________________________________________________________________________________________________________ > From: Joe Touch > To: Nalini Elkins > Cc: Andrew Yourtchenko ; IETF v6ops list > Sent: Tuesday, February 5, 2013 8:50 AM > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > FWIW, there are two obvious solutions that work for both IPv4 and IPv6: > > 1) send fragmented (or fragmentable) packets >     presuming you have control over a source > > 2) compare either full packets or hashes of the full packets > > "convenience" of an existing field that is not always available isn't a solution. > > Joe > > > > --0-480988788-1360084947=:24184-- From nalini.elkins@insidethestack.com Tue Feb 5 09:25: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 B9DF521F89A4 for ; Tue, 5 Feb 2013 09:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmqcPQtCC4Lv for ; Tue, 5 Feb 2013 09:25:48 -0800 (PST) Received: from nm27.access.bullet.mail.sp2.yahoo.com (nm27.access.bullet.mail.sp2.yahoo.com [98.139.44.154]) by ietfa.amsl.com (Postfix) with ESMTP id A96C321F881D for ; Tue, 5 Feb 2013 09:25:46 -0800 (PST) Received: from [98.139.44.107] by nm27.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 17:25:44 -0000 Received: from [98.139.44.80] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 17:25:44 -0000 Received: from [127.0.0.1] by omp1017.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 17:25:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 501647.69167.bm@omp1017.access.mail.sp2.yahoo.com Received: (qmail 68325 invoked by uid 60001); 5 Feb 2013 17:25:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360085144; bh=zu64mytgKAKLEKGsv3ri00AjXDuQvbUdoClMKF7IlqU=; 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=GEij6LDCkHYRjEA8t3WvgFHaUNc+D7TUUvHq7CD63UbTaQya1yZQTlJGvBzPsPkfbqMFVRBNS9MRkUOo6e5mctoUFU6x203iT/irQqvZPhfau980CPq1eSTAY37ByPdnmYHZ2BmSpOwZnvVD7dSrN40TtHs8vAfTUWaF4hEXIls= X-YMail-OSG: FclbQ3wVM1mtsZUlyg8FP13_fysa90rZHmA5mC8_Fl40U3O NaDoTgr5LTSP_8o3goTWqI0ROEXJkcBBY2XSlPVo71SdtOnbozrtvGjDK5c5 2CW6Hl0gCdHkroaNqT1IWyRc6_nzqh2SHUjoQC5iKybe5aZeRKVku96cwWS0 GUwjItTywtzUrmI22OPrxOE.z0qyJ0D.du.PORTUjr_nMMvGc8K8SZCeHNF_ 5H8HmCzI_IHxDzLayuX5mQgPcDSJTFX35HVd9Xcfo2PxE9LQFux1rz5gffuM A1JDurWWfWcZyHJj_VintlK54.ufq22w.xrOCorllIhCPSFupOEGtLGrhiI8 TUwprUsTrV8MpxpsLAIFSvOLURiSfJZnc1ffIAhOV0wkGVtXsoj0mr7TIpO5 BoCIG6yOZy9gw7uQ7LorZDHVmY7s2Np6ujHKGMlqkiDfNLIAu1cTCMChSxQD sR7JRhT0eiikFq0FpS8ilAqsE_VuZ6JETtdU.Zz3h3d6o5DXWSgqtlD.Ulo1 7RfzWc2bN2cLH9ARdZkFlshKYLsd7ECuex.bzuihVRSVVNXt7eesSSy0aK_2 gJdI5qk6l4Ly6gztxFX_F7dAkOUeG4fFjI3f7448pOA-- Received: from [50.0.137.66] by web2815.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 09:25:43 PST X-Rocket-MIMEInfo: 001.001, QW5kcmV3LAoKSSBsaWtlIHRoZSBpZGVhIG9mIHRydWx5IGRlZmluaW5nIHRoZSBwcm9ibGVtIHNwYWNlIHZlcnkgbXVjaCEgwqAgSSBoYXZlIHRvIHNheSwgdGhlIG9uZSBwcm9ibGVtIEkgaGFkIHdpdGggYWRkaW5nIGEgZnJhZ21lbnRhdGlvbiBoZWFkZXIgdG8gZWFjaCBwYWNrZXQgaXMgdGhlIG51bWJlciBvZiBieXRlcyBpdCB3b3VsZCB0YWtlIGFkZCB0byBlYWNoIHBhY2tldC4gwqBJIGtub3cgcGVvcGxlIGFyZSBhbHJlYWR5IHRhbGtpbmcgb2YgcG90ZW50aWFsIHBlcmZvcm1hbmNlIGltcGFjdHMgb2YBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> Message-ID: <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 09:25:43 -0800 (PST) From: Nalini Elkins To: Andrew Yourtchenko In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="702752695-1785518728-1360085143=:44876" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:25:49 -0000 --702752695-1785518728-1360085143=:44876 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Andrew,=0A=0AI like the idea of truly defining the problem space very much!= =A0 I have to say, the one problem I had with adding a fragmentation heade= r to each packet is the number of bytes it would take add to each packet. = =A0I know people are already talking of potential performance impacts of th= e additional bytes just in the IPv6 main header! =A0 We may not have any ch= oice at this point, but the fewer bytes added the better.=0A=0AI can certai= nly host a webcast where anyone interested can join in and comment on what = qualities a possible solution should have. =A0 Is that a possibility for yo= u? =A0Then, we don't even need to wait for Orlando!=0A=A0=0AThanks,=0A=0A= =0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethest= ack.com=0A=0A=0A=0A________________________________=0A From: Andrew Yourtch= enko =0ATo: Nalini Elkins =0ACc: IETF v6ops list =0ASent: Tuesday, February 5,= 2013 9:08 AM=0ASubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipi= d-needed=0A =0ANalini,=0A=0AOn Tue, 5 Feb 2013, Nalini Elkins wrote:=0A=0A>= Andrew,=0A> =0A> I wonder if possible solutions can be worked out at a bra= instorming session at the IETF in Orlando. =A0We would like to get a group= =0A> together to think about solutions because I can tell you, we internall= y have gone around with each other on different solutions and=0A> their dra= wbacks! =A0Performance, security and implementation difficulties being some= of the problems involved.=0A> =0A> I will ask the chairs if we can have a = BOF, if this is not possible, then maybe we can all find a venue with beer = and chips=0A> available! =A0 I will post.=0A=0AI won't make it to Orlando, = but I still think that we should try to squeeze as much of a problem space = in terms of problem definition, and the qualities a potential solution shou= ld have, before going to define the solutions themselves.=0A=0AMy quick ske= tch at how a potential solution's photorobot should look like, includes at = least the following two traits:=0A=0A1) be a property of every packet=0A2) = be always present (i.e. not require a separate 'switch it on' knob that wou= ld trigger a different code path)=0A3) be frugal in terms of any packet spa= ce it occupies (0 bytes being the best)=0A=0AProbably there's a couple more= - and then the rest of the traits should come out from the distilled use c= ases that the IP ID was used for.=0A=0ASuch a list could then make a framew= ork for evaluation of the potential solutions.=0A=0A--a --702752695-1785518728-1360085143=:44876 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Andrew,
<= div style=3D"color: rgb(0, 0, 0); font-size: 13.333333969116211px; font-fam= ily: arial, helvetica, sans-serif; background-color: transparent; font-styl= e: normal;">
I like the idea of tr= uly defining the problem space very much!   I have to say, the one pro= blem I had with adding a fragmentation header to each packet is the number = of bytes it would take add to each packet.  I know people are already = talking of potential performance impacts of the additional bytes just in th= e IPv6 main header!   We may not have any choice at this point, but th= e fewer bytes added the better.

=
I can certainly host a webcast where anyone interested c= an join in and comment on what qualities a possible solution should have. &= nbsp; Is that a possibility for you?  Then, we don't even need to wait= for Orlando!
 
Thanks,

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

From: Andrew Yourtchenko <ayourtch@cisco.com>
To: Nalini Elkins <nalini.elkins@insidethestack= .com>
Cc: IETF v6op= s list <v6ops@ietf.org>
Se= nt: Tuesday, February 5, 2013 9:08 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6o= ps-ipv6-ipid-needed

=0ANalini,

On Tue, 5 Feb = 2013, Nalini Elkins wrote:

> Andrew,
>
> I wonder if= possible solutions can be worked out at a brainstorming session at the IET= F in Orlando.  We would like to get a group
> together to think = about solutions because I can tell you, we internally have gone around with= each other on different solutions and
> their drawbacks!  Perfo= rmance, security and implementation difficulties being some of the problems= involved.
>
> I will ask the chairs if we can have a BOF, if = this is not possible, then maybe we can all find a venue with beer and chip= s
> available!   I will post.

I won't make it to Orlando,= but I still think that we should try to squeeze as much of a problem space= in terms of problem definition, and the qualities a potential solution sho= uld have, before going to define the solutions themselves.

My quick = sketch at how a potential solution's photorobot should look like, includes at least the following two traits:
1) be a property of every packet
2) be always present (i.e. not re= quire a separate 'switch it on' knob that would trigger a different code pa= th)
3) be frugal in terms of any packet space it occupies (0 bytes being= the best)

Probably there's a couple more - and then the rest of the= traits should come out from the distilled use cases that the IP ID was use= d for.

Such a list could then make a framework for evaluation of the= potential solutions.

--a

= --702752695-1785518728-1360085143=:44876-- From ietfc@btconnect.com Tue Feb 5 09:30: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 6007D21F8A47 for ; Tue, 5 Feb 2013 09:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX3g1oe-zJpC for ; Tue, 5 Feb 2013 09:30:52 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5B10F21F846C for ; Tue, 5 Feb 2013 09:30:52 -0800 (PST) Received: from mail235-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 5 Feb 2013 17:30:42 +0000 Received: from mail235-ch1 (localhost [127.0.0.1]) by mail235-ch1-R.bigfish.com (Postfix) with ESMTP id 6C1B6194018E; Tue, 5 Feb 2013 17:30:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zzbb2dI98dI9371I542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h304l1155h) Received: from mail235-ch1 (localhost.localdomain [127.0.0.1]) by mail235-ch1 (MessageSwitch) id 1360085440476920_25950; Tue, 5 Feb 2013 17:30:40 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail235-ch1.bigfish.com (Postfix) with ESMTP id 68B571D80053; Tue, 5 Feb 2013 17:30:40 +0000 (UTC) Received: from DB3PRD0710HT004.eurprd07.prod.outlook.com (157.56.253.85) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 5 Feb 2013 17:30:39 +0000 Received: from DBXPRD0411HT005.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.75.39) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 5 Feb 2013 17:30:38 +0000 Message-ID: <006101ce03c6$19284300$4001a8c0@gateway.2wire.net> From: t.petch To: "Howard, Lee" , joel jaeggli , IPv6 Ops WG References: Date: Tue, 5 Feb 2013 17:27:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.165] X-OriginatorOrg: btconnect.com Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:30:53 -0000 ----- Original Message ----- From: "Howard, Lee" To: "t.petch" ; "joel jaeggli" ; "IPv6 Ops WG" ; "Working Group Chairs" Sent: Tuesday, February 05, 2013 4:59 PM Are you suggesting that 464xlat is a BCP, or that, if one is going to deploy 464xlat, this is the best practice on how to do so? Is there enough operational experience (among a diversity of operators) to know that this is a Best Current Practice? Or is this more of an operational report back to the IETF? Lee I am saying that the discussions on this list have ended up with an I-D with the proposed status of BCP. I may not agree with everything that has been said - and much has been said - but I believe that the I-D as it currently stands should be published as is. Tom Petch Lee On 2/5/13 5:20 AM, "t.petch" wrote: >publish as BCP. > >Tom Petch > >----- Original Message ----- >From: "joel jaeggli" >To: "IPv6 Ops WG" ; "Working Group Chairs" > >Sent: Monday, February 04, 2013 7:40 PM > > >> To emphasize Fred's request, please share you opinion on whether this >> document should be published intact (as a BCP), with with a lower >state >> (informational), or not at all, given the IPR disclosure associated >with it. >> >> The document can be reviewed here: >> >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 >> >> the known IPR disclosure is here: >> >> >https://datatracker.ietf.org/ipr/search/?option=document_search&documen t >_search=draft-ietf-v6ops-464xlat >> >> if you have registered your opinion on this subject already you will >be >> counted. >> >> The deadline for commentary is Monday Feb 11th 2012. >> >> _______________________________________________ >> 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 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 ayourtch@cisco.com Tue Feb 5 09:51: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 AEB1021F87CE for ; Tue, 5 Feb 2013 09:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z-1s82VbgWd for ; Tue, 5 Feb 2013 09:51:18 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2191E21F8691 for ; Tue, 5 Feb 2013 09:51:16 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15HpFIs019637 for ; Tue, 5 Feb 2013 18:51:15 +0100 (CET) Received: from dhcp-10-55-83-125.cisco.com (dhcp-10-55-83-125.cisco.com [10.55.83.125]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15HpEao005915; Tue, 5 Feb 2013 18:51:15 +0100 (CET) Date: Tue, 5 Feb 2013 18:51:21 +0100 (CET) From: Andrew Yourtchenko To: Nalini Elkins In-Reply-To: <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-273765156-1360086682=:24184" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 17:51:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-273765156-1360086682=:24184 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Nalini, I took a stab at the initial version of the list here: https://docs.google.com/document/d/1TnONzdbicxwktuFzfjsZADdFSSNghK0GBzvPKAFneOc/edit?usp=sharing I marked the doc as world-editable, and it has chat. So, both synchronous (with chat for coordination) and asynchronous editing is possible, and it's open for anyone regardless of the timezone, so should ease the logistics. Let's see if this approach works in lieu of fully synchronous things like meetings and webcasts. --a On Tue, 5 Feb 2013, Nalini Elkins wrote: > Andrew, > > I like the idea of truly defining the problem space very much!   I have to say, the one problem I had with adding a fragmentation > header to each packet is the number of bytes it would take add to each packet.  I know people are already talking of potential > performance impacts of the additional bytes just in the IPv6 main header!   We may not have any choice at this point, but the fewer > bytes added the better. > > I can certainly host a webcast where anyone interested can join in and comment on what qualities a possible solution should have. > Is that a possibility for you?  Then, we don't even need to wait for Orlando! > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ___________________________________________________________________________________________________________________________________________ > From: Andrew Yourtchenko > To: Nalini Elkins > Cc: IETF v6ops list > Sent: Tuesday, February 5, 2013 9:08 AM > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > Nalini, > > On Tue, 5 Feb 2013, Nalini Elkins wrote: > > > Andrew, > > > > I wonder if possible solutions can be worked out at a brainstorming session at the IETF in Orlando.  We would like to get a group > > together to think about solutions because I can tell you, we internally have gone around with each other on different solutions > and > > their drawbacks!  Performance, security and implementation difficulties being some of the problems involved. > > > > I will ask the chairs if we can have a BOF, if this is not possible, then maybe we can all find a venue with beer and chips > > available!   I will post. > > I won't make it to Orlando, but I still think that we should try to squeeze as much of a problem space in terms of problem > definition, and the qualities a potential solution should have, before going to define the solutions themselves. > > My quick sketch at how a potential solution's photorobot should look like, includes at least the following two traits: > > 1) be a property of every packet > 2) be always present (i.e. not require a separate 'switch it on' knob that would trigger a different code path) > 3) be frugal in terms of any packet space it occupies (0 bytes being the best) > > Probably there's a couple more - and then the rest of the traits should come out from the distilled use cases that the IP ID was > used for. > > Such a list could then make a framework for evaluation of the potential solutions. > > --a > > > --0-273765156-1360086682=:24184-- From touch@isi.edu Tue Feb 5 10:22: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 09A4B21F85B3 for ; Tue, 5 Feb 2013 10:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.699 X-Spam-Level: X-Spam-Status: No, score=-104.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWyraVBObyHp for ; Tue, 5 Feb 2013 10:22:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 93C1021F88AE for ; Tue, 5 Feb 2013 10:21:57 -0800 (PST) Received: from [128.9.184.192] ([128.9.184.192]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r15IKv0H009830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 10:20:57 -0800 (PST) Message-ID: <51114D8A.4010901@isi.edu> Date: Tue, 05 Feb 2013 10:20:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Yourtchenko References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 18:22:32 -0000 Hi, Andrew, I completely agree; I look forward to a description of the problem. Joe On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote: > Nalini, Joe, > > This two-mail exchange vividly illustrates why it's beneficial to > describe the problem better, and the properties of the ideal solution > (starting with that of IP ID, but not necessarily limited to it), but > not jump to solutions themselves straight away. > > Otherwise it's too easy to get into a situation of a fish and a gull > arguing about the sea water. > > --a > > > On Tue, 5 Feb 2013, Nalini Elkins wrote: > >> Comparing hashes or packets is not really a workable solution because >> there can be true duplicate packets. A hash will only show if >> the packets are the same. Unless I am missing something. Sometimes >> the problem we are trying to diagnose is how many duplicates >> there are. This is an indication of congestion. Some devices create >> 'false' duplicates. That is a packet trace taken at that >> point will show that the packet is the same but it is only the device >> or the trace mechanism tracing incorrectly. Believe me, this >> is not an infrequent problem. >> >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> ___________________________________________________________________________________________________________________________________________ >> >> From: Joe Touch >> To: Nalini Elkins >> Cc: Andrew Yourtchenko ; IETF v6ops list >> >> Sent: Tuesday, February 5, 2013 8:50 AM >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >> >> FWIW, there are two obvious solutions that work for both IPv4 and IPv6: >> >> 1) send fragmented (or fragmentable) packets >> presuming you have control over a source >> >> 2) compare either full packets or hashes of the full packets >> >> "convenience" of an existing field that is not always available isn't >> a solution. >> >> Joe >> >> >> >> From touch@isi.edu Tue Feb 5 10:25: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 45C8821F863C for ; Tue, 5 Feb 2013 10:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.817 X-Spam-Level: X-Spam-Status: No, score=-102.817 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6HkKOgMPZCk for ; Tue, 5 Feb 2013 10:25:46 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E62E721F868D for ; Tue, 5 Feb 2013 10:25:15 -0800 (PST) Received: from [128.9.184.192] ([128.9.184.192]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r15IP2X7011106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 10:25:02 -0800 (PST) Message-ID: <51114E80.1090804@isi.edu> Date: Tue, 05 Feb 2013 10:25:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Yourtchenko References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> In-Reply-To: <51114D8A.4010901@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 18:25:47 -0000 PS - I'm particularly interested in an explanation of why duplicate packets would be an indication of congestion, FWIW. Joe On 2/5/2013 10:20 AM, Joe Touch wrote: > Hi, Andrew, > > I completely agree; I look forward to a description of the problem. > > Joe > > On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote: >> Nalini, Joe, >> >> This two-mail exchange vividly illustrates why it's beneficial to >> describe the problem better, and the properties of the ideal solution >> (starting with that of IP ID, but not necessarily limited to it), but >> not jump to solutions themselves straight away. >> >> Otherwise it's too easy to get into a situation of a fish and a gull >> arguing about the sea water. >> >> --a >> >> >> On Tue, 5 Feb 2013, Nalini Elkins wrote: >> >>> Comparing hashes or packets is not really a workable solution because >>> there can be true duplicate packets. A hash will only show if >>> the packets are the same. Unless I am missing something. Sometimes >>> the problem we are trying to diagnose is how many duplicates >>> there are. This is an indication of congestion. Some devices create >>> 'false' duplicates. That is a packet trace taken at that >>> point will show that the packet is the same but it is only the device >>> or the trace mechanism tracing incorrectly. Believe me, this >>> is not an infrequent problem. >>> >>> Thanks, >>> >>> Nalini Elkins >>> Inside Products, Inc. >>> (831) 659-8360 >>> www.insidethestack.com >>> >>> ___________________________________________________________________________________________________________________________________________ >>> >>> >>> From: Joe Touch >>> To: Nalini Elkins >>> Cc: Andrew Yourtchenko ; IETF v6ops list >>> >>> Sent: Tuesday, February 5, 2013 8:50 AM >>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>> >>> FWIW, there are two obvious solutions that work for both IPv4 and IPv6: >>> >>> 1) send fragmented (or fragmentable) packets >>> presuming you have control over a source >>> >>> 2) compare either full packets or hashes of the full packets >>> >>> "convenience" of an existing field that is not always available isn't >>> a solution. >>> >>> Joe >>> >>> >>> >>> From nalini.elkins@insidethestack.com Tue Feb 5 11:26: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 179B521F8697 for ; Tue, 5 Feb 2013 11:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+OelN6dDZ9k for ; Tue, 5 Feb 2013 11:26:54 -0800 (PST) Received: from nm17-vm0.access.bullet.mail.sp2.yahoo.com (nm17-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.168]) by ietfa.amsl.com (Postfix) with ESMTP id 0073E21F868B for ; Tue, 5 Feb 2013 11:26:53 -0800 (PST) Received: from [98.139.44.100] by nm17.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:26:53 -0000 Received: from [98.139.44.92] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:26:53 -0000 Received: from [127.0.0.1] by omp1029.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:26:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 886720.58911.bm@omp1029.access.mail.sp2.yahoo.com Received: (qmail 86373 invoked by uid 60001); 5 Feb 2013 19:26:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360092413; bh=GbA9+U2GTPAOL8tHgsgZof9RlL+8SlZ1eAi4Uh/CnDM=; 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=A6UlRMJFb0WmjXCsaylykVFQ5zDA2xx+0G932djbzAy49bQH6TR2yFVWkzLSCCSQOAHBXm0vb2VCqxhcc10lAyeXBN/6qOcxKZ+PpyCPCMeZyNquDtwO3BXG9sRN5xqc7KlHrG8lK7j6d4GfyIJceCs6DxdPfxixkWzQLJ7edmI= X-YMail-OSG: 6wwOXQUVM1lCFChtCWAFlaKFZPc4OeznmfLal4DYODokUuN zumurXGOu4wSjoo4B_7vXNl6Y4rgtZQc6cBaeRti_h3nVUbNkAwiWFa.qmvd zjEvc2V3GNuKGh2p.DJcAziBBN6KV3s0T9oIc9jXlweWuosD.nmdlgn_TtTt Y_g01bJy8vdrUcBbZt8O1813pAJLcfMhgINitwxa7d4uu7ngwTJw6G1EXbZs LyMMExPuHjYa3t7DLbJcwhV5mVb1TwzrMOQIv4v27pxwQR5hGzYjemwq9Xqk JE4ph9HfwkOqU9JxK2ieXRY1gn_Fa.WQnyag4isz_pkV4d4UhxboLKx9yyZT isC3I0UF_xHs4KJZKCGKMEC0cPithTrJM2rptcvISB62GCe5ZAZf.STm3yBY LdL96l3vrQZtfKq9Ri4Ec4NyJVIX_960_Etx7Ma.JBf94qw.T926zEWP5HdU Imp1pnkIwDbDmOYnF4hB2i_FJmdPCAsphpxKyZefwL_VJUqyhuTIFkyjt9eJ 16UDRMQ7nMX7cogCwotWu9azocM302.7uOp5sE6IIh6XC_tmbZS7vQAhgNaU A8EvafnfGAIgq_BbcXURi7RxN0ib6Aoe0EYg0yoHLFErA4fZANwY03t7sCxM XEuC301MVJNmPLQK.JaLBQTFI548Hu_htRwVLN1W4CdD7G2cib3HuTWJeuxj BVRDGktfDO18_QMnOvrls9aVFcBiUuCNWJui78krET0lV8asvskwOmlHI0YX 0gIvOn8596DvI4EaAIeIfiBTRwBPNF1xhywR2cg-- Received: from [12.249.100.42] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 11:26:52 PST X-Rocket-MIMEInfo: 001.001, QW5kcmV3LAoKVGhpcyBpcyB3b25kZXJmdWwhISDCoCBUaGFuayB5b3Ugc28gbXVjaCEgwqAgTGV0IG1lIGdldCBteSBjcmV3IHRvIHRha2UgYSBsb29rIGFuZCBjb21tZW50IGFuZCB0aGVuLCBpZiB3ZSBuZWVkIGEgc3luY2hyb25vdXMgbWVldGluZywgdGhlbiB3ZSBjYW4gZG8gaXQuCsKgClRoYW5rcywKCgpOYWxpbmkgRWxraW5zCkluc2lkZSBQcm9kdWN0cywgSW5jLgooODMxKSA2NTktODM2MAp3d3cuaW5zaWRldGhlc3RhY2suY29tCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> Message-ID: <1360092412.86182.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 11:26:52 -0800 (PST) From: Nalini Elkins To: Andrew Yourtchenko In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-15183566-1360092412=:86182" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:26:55 -0000 ---153701192-15183566-1360092412=:86182 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Andrew,=0A=0AThis is wonderful!! =A0 Thank you so much! =A0 Let me get my c= rew to take a look and comment and then, if we need a synchronous meeting, = then we can do it.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products,= Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A________________= ________________=0A From: Andrew Yourtchenko =0ATo: Nal= ini Elkins =0ACc: IETF v6ops list =0ASent: Tuesday, February 5, 2013 9:51 AM=0ASubject: Re: [v6ops= ] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A =0ANalini,=0A=0AI took = a stab at the initial version of the list here:=0A=0Ahttps://docs.google.co= m/document/d/1TnONzdbicxwktuFzfjsZADdFSSNghK0GBzvPKAFneOc/edit?usp=3Dsharin= g=0A=0AI marked the doc as world-editable, and it has chat. So, both synchr= onous (with chat for coordination) and asynchronous editing is possible, an= d it's open for anyone regardless of the timezone, so should ease the logis= tics.=0A=0ALet's see if this approach works in lieu of fully synchronous th= ings like meetings and webcasts.=0A=0A--a=0A=0AOn Tue, 5 Feb 2013, Nalini E= lkins wrote:=0A=0A> Andrew,=0A> =0A> I like the idea of truly defining the = problem space very much! =A0 I have to say, the one problem I had with addi= ng a fragmentation=0A> header to each packet is the number of bytes it woul= d take add to each packet. =A0I know people are already talking of potentia= l=0A> performance impacts of the additional bytes just in the IPv6 main hea= der! =A0 We may not have any choice at this point, but the fewer=0A> bytes = added the better.=0A> =0A> I can certainly host a webcast where anyone inte= rested can join in and comment on what qualities a possible solution should= have. Is that a possibility for you? =A0Then, we don't even need to wait f= or Orlando!=0A> =0A> Thanks,=0A> =0A> Nalini Elkins=0A> Inside Products, In= c.=0A> (831) 659-8360=0A> www.insidethestack.com=0A> =0A> _________________= ___________________________________________________________________________= _______________________________________________=0A> From: Andrew Yourtchenk= o =0A> To: Nalini Elkins =0A> Cc: IETF v6ops list =0A> Sent: Tuesday, February 5= , 2013 9:08 AM=0A> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-= ipid-needed=0A> =0A> Nalini,=0A> =0A> On Tue, 5 Feb 2013, Nalini Elkins wro= te:=0A> =0A> > Andrew,=0A> >=0A> > I wonder if possible solutions can be wo= rked out at a brainstorming session at the IETF in Orlando. =A0We would lik= e to get a group=0A> > together to think about solutions because I can tell= you, we internally have gone around with each other on different solutions= =0A> and=0A> > their drawbacks! =A0Performance, security and implementation= difficulties being some of the problems involved.=0A> >=0A> > I will ask t= he chairs if we can have a BOF, if this is not possible, then maybe we can = all find a venue with beer and chips=0A> > available! =A0 I will post.=0A> = =0A> I won't make it to Orlando, but I still think that we should try to sq= ueeze as much of a problem space in terms of problem=0A> definition, and th= e qualities a potential solution should have, before going to define the so= lutions themselves.=0A> =0A> My quick sketch at how a potential solution's = photorobot should look like, includes at least the following two traits:=0A= > =0A> 1) be a property of every packet=0A> 2) be always present (i.e. not = require a separate 'switch it on' knob that would trigger a different code = path)=0A> 3) be frugal in terms of any packet space it occupies (0 bytes be= ing the best)=0A> =0A> Probably there's a couple more - and then the rest o= f the traits should come out from the distilled use cases that the IP ID wa= s=0A> used for.=0A> =0A> Such a list could then make a framework for evalua= tion of the potential solutions.=0A> =0A> --a=0A> =0A> =0A> ---153701192-15183566-1360092412=:86182 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Andrew,
<= div style=3D"color: rgb(0, 0, 0); font-size: 13.333333969116211px; font-fam= ily: arial, helvetica, sans-serif; background-color: transparent; font-styl= e: normal;">
This is wonderful!! &= nbsp; Thank you so much!   Let me get my crew to take a look and comme= nt and then, if we need a synchronous meeting, then we can do it.
 
Thanks,

Nalini Elkins=
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com
From: Andrew Y= ourtchenko <ayourtch@cisco.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com> =
Cc: IETF v6ops list &l= t;v6ops@ietf.org>
Sent: Tuesday, February 5, 2013 9:51 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-i= pid-needed

=0ANalini,

I took a stab at the in= itial version of the list here:

https://docs.google.com/document/d/1TnONzdbicxwktuFzfjsZA= DdFSSNghK0GBzvPKAFneOc/edit?usp=3Dsharing

I marked the doc as wo= rld-editable, and it has chat. So, both synchronous (with chat for coordina= tion) and asynchronous editing is possible, and it's open for anyone regard= less of the timezone, so should ease the logistics.

Let's see if thi= s approach works in lieu of fully synchronous things like meetings and webc= asts.

--a

On Tue, 5 Feb 2013, Nalini Elkins wrote:

>= ; Andrew,
>
> I like the idea of truly defining the problem sp= ace very much!   I have to say, the one problem I had with adding a fr= agmentation
> header to each packet is the number of bytes it would t= ake add to each packet.  I know people are already talking of potential
> performance impacts of the= additional bytes just in the IPv6 main header!   We may not have any = choice at this point, but the fewer
> bytes added the better.
>=
> I can certainly host a webcast where anyone interested can join i= n and comment on what qualities a possible solution should have. Is that a = possibility for you?  Then, we don't even need to wait for Orlando!>
> Thanks,
>
> Nalini Elkins
> Inside Produc= ts, Inc.
> (831) 659-8360
> www.insidethestack.com
>
> _____= ___________________________________________________________________________= ___________________________________________________________
> From: A= ndrew Yourtchenko <ayourtch@cisco.com>
> To: Nalini Elkins <nalini.elkins@insidethestack.com><= br>> Cc: IETF v6ops list <v6ops@ietf.org>
> Sent: Tuesday, Fe= bruary 5, 2013 9:08 AM
> Subject: Re: [v6ops] new draft: draft-elkins= -v6ops-ipv6-ipid-needed
>
> Nalini,
>
> On Tue, 5= Feb 2013, Nalini Elkins wrote:
>
> > Andrew,
> ><= br>> > I wonder if possible solutions can be worked out at a brainsto= rming session at the IETF in Orlando.  We would like to get a group> > together to think about solutions because I can tell you, we int= ernally have gone around with each other on different solutions
> and=
> > their drawbacks!  Performance, security and implementati= on difficulties being some of the problems involved.
> >
> &= gt; I will ask the chairs if we can have a BOF, if this is not possible, then = maybe we can all find a venue with beer and chips
> > available! &= nbsp; I will post.
>
> I won't make it to Orlando, but I still= think that we should try to squeeze as much of a problem space in terms of= problem
> definition, and the qualities a potential solution should = have, before going to define the solutions themselves.
>
> My = quick sketch at how a potential solution's photorobot should look like, inc= ludes at least the following two traits:
>
> 1) be a property = of every packet
> 2) be always present (i.e. not require a separate '= switch it on' knob that would trigger a different code path)
> 3) be = frugal in terms of any packet space it occupies (0 bytes being the best)>
> Probably there's a couple more - and then the rest of the tr= aits should come out from the distilled use cases that the IP ID was
> used for.
>
> Such a list could then make a frame= work for evaluation of the potential solutions.
>
> --a
>= ;
>
>

---153701192-15183566-1360092412=:86182-- From mackermann@bcbsm.com Tue Feb 5 11:28: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 7108021F86F0 for ; Tue, 5 Feb 2013 11:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzMooFZLAR5I for ; Tue, 5 Feb 2013 11:28:02 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id B439721F869F for ; Tue, 5 Feb 2013 11:28:02 -0800 (PST) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 0328917E381 for ; Tue, 5 Feb 2013 13:28:02 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id BE60217E361; Tue, 5 Feb 2013 13:28:00 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id D19FA4F804D; Tue, 5 Feb 2013 14:26:37 -0500 (EST) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id C5AE94F8049; Tue, 5 Feb 2013 14:26:37 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Tue, 5 Feb 2013 14:27:59 -0500 From: "Ackermann, Michael" To: Andrew Yourtchenko , Nalini Elkins Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8CAATMIAIAABu4AgAA61oCAAFrmgIAADN+AgAAE8oCAAAcpgP//vp4Q Date: Tue, 5 Feb 2013 19:27:59 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DF1BC@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 19:28:03 -0000 Andrew, What a great start and very well done=21=21=21 One comment. Regards to 2. I personally would like to see IPID always = present, but there are others that feel it should be able to be switched = on or off to save on overhead. =20 Great start on thanks=21 Mike=20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Andrew Yourtchenko Sent: Tuesday, February 05, 2013 12:51 PM To: Nalini Elkins Cc: IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed Nalini, I took a stab at the initial version of the list here: https://docs.google.com/document/d/1TnONzdbicxwktuFzfjsZADdFSSNghK0GBzvPKAF= neOc/edit?usp=3Dsharing I marked the doc as world-editable, and it has chat. So, both synchronous = (with chat for coordination) and asynchronous editing is possible, and = it's open for anyone regardless of the timezone, so should ease the = logistics. Let's see if this approach works in lieu of fully synchronous things like = meetings and webcasts. --a On Tue, 5 Feb 2013, Nalini Elkins wrote: > Andrew, >=20 > I like the idea of truly defining the problem space very much=21 =A0 I=20 > have to say, the one problem I had with adding a fragmentation header=20 > to each packet is the number of bytes it would take add to each=20 > packet. =A0I know people are already talking of potential performance = impacts of the additional bytes just in the IPv6 main header=21 =A0 We may = not have any choice at this point, but the fewer bytes added the better. >=20 > I can certainly host a webcast where anyone interested can join in and = comment on what qualities a possible solution should have.=20 > Is that a possibility for you? =A0Then, we don't even need to wait for = Orlando=21 >=20 > Thanks, >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com >=20 > ______________________________________________________________________ > _____________________________________________________________________ > From: Andrew Yourtchenko > To: Nalini Elkins > Cc: IETF v6ops list > Sent: Tuesday, February 5, 2013 9:08 AM > Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > Nalini, >=20 > On Tue, 5 Feb 2013, Nalini Elkins wrote: >=20 > > Andrew, > > > > I wonder if possible solutions can be worked out at a brainstorming=20 > > session at the IETF in Orlando. =A0We would like to get a group=20 > > together to think about solutions because I can tell you, we=20 > > internally have gone around with each other on different solutions > and > > their drawbacks=21 =A0Performance, security and implementation = difficulties being some of the problems involved. > > > > I will ask the chairs if we can have a BOF, if this is not possible,=20 > > then maybe we can all find a venue with beer and chips available=21 = =A0 I will post. >=20 > I won't make it to Orlando, but I still think that we should try to=20 > squeeze as much of a problem space in terms of problem definition, and = the qualities a potential solution should have, before going to define the = solutions themselves. >=20 > My quick sketch at how a potential solution's photorobot should look = like, includes at least the following two traits: >=20 > 1) be a property of every packet > 2) be always present (i.e. not require a separate 'switch it on' knob=20 > that would trigger a different code path) > 3) be frugal in terms of any packet space it occupies (0 bytes being=20 > the best) >=20 > Probably there's a couple more - and then the rest of the traits=20 > should come out from the distilled use cases that the IP ID was used for. >=20 > Such a list could then make a framework for evaluation of the potential = solutions. >=20 > --a >=20 >=20 > The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nalini.elkins@insidethestack.com Tue Feb 5 11:29: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 A4E6721F86F0 for ; Tue, 5 Feb 2013 11:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRhOr+7472QY for ; Tue, 5 Feb 2013 11:29:00 -0800 (PST) Received: from nm1.access.bullet.mail.sp2.yahoo.com (nm1.access.bullet.mail.sp2.yahoo.com [98.139.44.128]) by ietfa.amsl.com (Postfix) with ESMTP id 06BDC21F8697 for ; Tue, 5 Feb 2013 11:29:00 -0800 (PST) Received: from [98.139.44.98] by nm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:28:59 -0000 Received: from [98.139.44.78] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:28:59 -0000 Received: from [127.0.0.1] by omp1015.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:28:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 863529.19545.bm@omp1015.access.mail.sp2.yahoo.com Received: (qmail 23591 invoked by uid 60001); 5 Feb 2013 19:28:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360092539; bh=nduapqWYIZpir5QLskIxIr6fcOgsHA3j4/x/IuMcuP0=; 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=OtjhZNNUJIXw2G5MDfuPw+TnnMjN7MyYMA/DKLHCRaiCxQcWIFu87mbU+lq7ByNMZNlmLkN3xZZQHzzV6zLcbocvqeAjWhWOBa3knJc2BwAWieZJ+d1xFapF563ZxJL/Zgxa7HR0864YOpO4zuTTQH9nf0VmQG4fFvrPTQjWqZE= X-YMail-OSG: etAy4msVM1kGfoLZrp2ugz22G8rFOQWFZ2.BooacMSXwkks yHeVshRWhHEpEEgEKtxBivWC78a1rVKRo3uUBCsTWJJF5wWq50me82HI4wf9 VZTtONZzRT.bnxyQM4y2Dcr1ltDNvxNfTv5kN4R_Ey1VNgS4KsGF.wKxkwSv k76OF12NuW1dK7MJfRXoXHr.zf_pUNhXj.gI.KE5vncTNTQzGkTQqhr.19g. bbovC_vEReEbHyU0Iu0RW7QkXpoI_x9RnU10wDgj613fIVoMelw1bBRfvlsv WOwdQIWJo7RrAtmPwaiUShp42IaStZbsuasGqvFS04bVoCXhqC8ADIsVJnvx QDCABVbbdhEwtpYn5nB5iCY2JjiE8AXZdahqC8y8QyF9_CD.mcDpTz.NIJ32 gnfQsqnRHU1QkTfHhpzPnFROJ_KuhTkt0qQWTQZ_2JmT0IgHBjCCGRt.5vIs nqIPp0RqOWLPazCx.n63KGnqBkOaJDjAusVnBiNlFE_trRcT.3k_0R_hxh4V LbUBz9ygoFjFD.Yp5fVi2hHCxvmXRftnDIyCDcRRzSidHxrhFHNxWNJnhGAi C1hPeO0w9upjQTZRQQfT7mFUzQx0yfYvgs8h6CTnLKys- Received: from [12.249.100.42] by web2806.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 11:28:59 PST X-Rocket-MIMEInfo: 001.001, Sm9lLAoKV2VsbCwgZHVwbGljYXRlIHBhY2tldHMgYXJlIG9mdGVuIHJldHJhbnNtaXNzaW9ucy4gwqAgSWYgeW91IGhhdmUgcmV0cmFuc21pc3Npb25zLCB0aGVuIHRoZSBvdGhlciBlbmQgKG9yIHRoZSBuZXR3b3JrKSBpcyBub3QgYWJzb3JiaW5nIHRoZSBmbG93IHByb3Blcmx5LiDCoFRoZW4sIG9uIG91ciBlbmQsIHdlIG5lZWQgdG8gc2VlIGlmIHdlIGhhdmUgYWxsb2NhdGVkIGVub3VnaCBiYW5kd2lkdGgsIGl0IGlzIGdvaW5nIG92ZXIgYSBzdWItb3B0aW1hbCByb3V0ZSwgZXRjLgrCoApUaGFua3MsCgoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> Message-ID: <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 11:28:59 -0800 (PST) From: Nalini Elkins To: Joe Touch , Andrew Yourtchenko In-Reply-To: <51114E80.1090804@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-977142774-1360092539=:13968" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:29:00 -0000 --1510626085-977142774-1360092539=:13968 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Joe,=0A=0AWell, duplicate packets are often retransmissions. =A0 If you hav= e retransmissions, then the other end (or the network) is not absorbing the= flow properly. =A0Then, on our end, we need to see if we have allocated en= ough bandwidth, it is going over a sub-optimal route, etc.=0A=A0=0AThanks,= =0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insid= ethestack.com=0A=0A=0A=0A________________________________=0A From: Joe Touc= h =0ATo: Andrew Yourtchenko =0ACc: Nali= ni Elkins ; IETF v6ops list =0ASent: Tuesday, February 5, 2013 10:25 AM=0ASubject: Re: [v6ops] new = draft: draft-elkins-v6ops-ipv6-ipid-needed=0A =0APS - I'm particularly inte= rested in an explanation of why duplicate =0Apackets would be an indication= of congestion, FWIW.=0A=0AJoe=0A=0AOn 2/5/2013 10:20 AM, Joe Touch wrote:= =0A> Hi, Andrew,=0A>=0A> I completely agree; I look forward to a descriptio= n of the problem.=0A>=0A> Joe=0A>=0A> On 2/5/2013 9:22 AM, Andrew Yourtchen= ko wrote:=0A>> Nalini, Joe,=0A>>=0A>> This two-mail exchange vividly illust= rates why it's beneficial to=0A>> describe the problem better, and the prop= erties of the ideal solution=0A>> (starting with that of IP ID, but not nec= essarily limited to it), but=0A>> not jump to solutions themselves straight= away.=0A>>=0A>> Otherwise it's too easy to get into a situation of a fish = and a gull=0A>> arguing about the sea water.=0A>>=0A>> --a=0A>>=0A>>=0A>> O= n Tue, 5 Feb 2013, Nalini Elkins wrote:=0A>>=0A>>> Comparing hashes or pack= ets is not really a workable solution because=0A>>> there can be true dupli= cate packets.=A0 A hash will only show if=0A>>> the packets are the same.= =A0 Unless I am missing something.=A0 Sometimes=0A>>> the problem we are = trying to diagnose is how many duplicates=0A>>> there are.=A0 This is an in= dication of congestion.=A0 Some devices create=0A>>> 'false' duplicates.= =A0 That is a packet trace taken at that=0A>>> point will show that the pac= ket is the same but it is only the device=0A>>> or the trace mechanism trac= ing incorrectly.=A0 Believe me, this=0A>>> is not an infrequent problem.=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: Jo= e Touch =0A>>> To: Nalini Elkins =0A>>> Cc: Andrew Yourtchenko ; IETF v6ops list= =0A>>> =0A>>> Sent: Tuesday, February 5, 2013 8:50 AM=0A>>>= Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A>>>= =0A>>> FWIW, there are two obvious solutions that work for both IPv4 and IP= v6:=0A>>>=0A>>> 1) send fragmented (or fragmentable) packets=0A>>>=A0 =A0 = presuming you have control over a source=0A>>>=0A>>> 2) compare either full= packets or hashes of the full packets=0A>>>=0A>>> "convenience" of an exis= ting field that is not always available isn't=0A>>> a solution.=0A>>>=0A>>>= Joe=0A>>>=0A>>>=0A>>>=0A>>> --1510626085-977142774-1360092539=:13968 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Joe,

Well, duplicate packets = are often retransmissions.   If you have retransmissions, then the oth= er end (or the network) is not absorbing the flow properly.  Then, on = our end, we need to see if we have allocated enough bandwidth, it is going = over a sub-optimal route, etc.
 
Thanks,

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

From: Joe Touch <touch@isi.edu>
= To: Andrew Yourtchenko &l= t;ayourtch@cisco.com>
Cc: Nalini Elkins <nalini.elkins@insidethestack.com>; IETF v6ops l= ist <v6ops@ietf.org>
Sent:= Tuesday, February 5, 2013 10:25 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops= -ipv6-ipid-needed

=0APS - I'm particularly intereste= d in an explanation of why duplicate
packets would be an indication of = congestion, FWIW.

Joe

On 2/5/2013 10:20 AM, Joe Touch wrote:<= br>> Hi, Andrew,
>
> I completely agree; I look forward to a= description of the problem.
>
> Joe
>
> On 2/5/201= 3 9:22 AM, Andrew Yourtchenko wrote:
>> Nalini, Joe,
>>>> This two-mail exchange vividly illustrates why it's beneficial t= o
>> describe the problem better, and the properties of the ideal = solution
>> (starting with that of IP ID, but not necessarily limi= ted to it), but
>> not jump to solutions themselves straight away.=
>>
>> Otherwise it's too easy to get into a situation of= a fish and a gull
>> arguing about the sea water.
>>
= >> --a
>>
>>
>> On Tue, 5 Feb 2013, Nalini= Elkins wrote:
>>
>>> Comparing hashes or packets is not real= ly a workable solution because
>>> there can be true duplicate = packets.  A hash will only show if
>>> the packets are the= same.  Unless I am missing something.  Sometimes
>>&g= t; the problem we are trying to diagnose is how many duplicates
>>= > there are.  This is an indication of congestion.  Some devi= ces create
>>> 'false' duplicates.  That is a packet trace= taken at that
>>> point will show that the packet is the same = but it is only the device
>>> or the trace mechanism tracing in= correctly.  Believe me, this
>>> is not an infrequent prob= lem.
>>>
>>> Thanks,
>>>
>>>= ; Nalini Elkins
>>> Inside Products, Inc.
>>> (831)= 659-8360
>>> www.insidethestack.com
>= >>
>>> __________________________________________________= ___________________________________________________________________________= ______________
>>>
>>>
>>> From: Joe To= uch <t= ouch@isi.edu>
>>> To: Nalini Elkins <nalini.elkins@insidethestack.com>
>>> Cc: A= ndrew Yourtchenko <ayourtch@cisco.com>; IETF v6ops list
>&= gt;> <v6ops@ietf.org>
>>> Sent: Tuesday, February 5, 2013= 8:50 AM
>>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
>>>
>>> FWIW, = there are two obvious solutions that work for both IPv4 and IPv6:
>&g= t;>
>>> 1) send fragmented (or fragmentable) packets
>= >>    presuming you have control over a source
>>= >
>>> 2) compare either full packets or hashes of the full p= ackets
>>>
>>> "convenience" of an existing field t= hat is not always available isn't
>>> a solution.
>>&g= t;
>>> Joe
>>>
>>>
>>>
&= gt;>>


--1510626085-977142774-1360092539=:13968-- From markzzzsmith@yahoo.com.au Tue Feb 5 11:29: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 3AA1821F87A6 for ; Tue, 5 Feb 2013 11:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL-7cXnMygiH for ; Tue, 5 Feb 2013 11:29:43 -0800 (PST) Received: from nm9.bullet.mail.bf1.yahoo.com (nm9.bullet.mail.bf1.yahoo.com [98.139.212.168]) by ietfa.amsl.com (Postfix) with SMTP id 0C27221F8778 for ; Tue, 5 Feb 2013 11:29:42 -0800 (PST) Received: from [98.139.215.143] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2013 19:29:42 -0000 Received: from [98.139.212.212] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2013 19:29:42 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 05 Feb 2013 19:29:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 418307.3682.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 19951 invoked by uid 60001); 5 Feb 2013 19:29:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360092582; bh=ibCO72gtb2X7Kv9qaLNeM3wZlqueiSAe4HtqWGw94lU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=s+QkIqlTXFtxd3JlA6eXFHdgeTMKNvEarMxiBh0awQ4ngNycXNYOLWRgYI1YKy46ITpcG8e78tjaSTjWu/d65suV98kDHa9sBG87zyvUzxQbJBuYleRE9c2n6OQbv1DmezVXI2r3BW7eCoAgWROuGN8KGEDdP1WhQ+eRCgXRRdY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=piJAgCPbLsckUqGKxEf3hTNgwVl04bAQjsyD1hTIMRSg15ukmAaaAvjOiCY5BceXe4yVI5IieZhl7jhEF/F16eY+txyRUy8qGkSRNkhlitmwZMP7dAeilkoJxUvdZLqZ2fQ9uSdMaC+zDQS+M5eVdZOSnLU642696vO2/U+kEjA=; X-YMail-OSG: yvwnNAoVM1k0wEth5PK_CLQaM0McYj_4MU4vbH3l5b9Yva_ t.kMp7oKp3.GzWrpNxBiJ6W2FpgA3HOyimqoRelrLDocxXLKWTRulc.S9BCb q4iwYA_t8X1KQp8w7y2nlw5xduncvYuGlpAHGoiv0uMrDgoIIVW11QUaZuBC WnsIOdl2_aUsNFlSIUMlfZML95_BRrGpNofXIyJE0M4TALWUguASIa_DJwTl IytXhPzwHY21Jpr9wqDqS7SbOynChMgHg6WyWOMAd0Jky0GFg_Kisx2zUOhy NIwnzid5dNJ8GvHqIwfJ6yuNTJwy9nS9fJhSS5fk.raUdHIPxW79.mGkg2.u gt1_Vpshz2Lne5IA_42_jVUmDLDk2NXBSIx2Dd6c3ulmpeESLSiDRpfuVVgq gJZBzDMWpUoBaca6JommjRnz8biJfbXHfEEBKeF8aAxD5Og4VpZFBVxkGCCF kySz_GCaodFIVEvtTgnZy9pYSM4FgOyiiiccRN7C0.u0mBdeHfAebbiuyiS7 b1s0LWBR3K7bT3FzNsEwFJ0_C Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Tue, 05 Feb 2013 11:29:42 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiQWNrZXJtYW5uLCBNaWNoYWVsIiA8TUFja2VybWFubkBiY2JzbS5jb20.Cj4gVG86IGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT47ICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgSUVURiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4KPiBDYzogCj4gU2VudDogV2VkbmVzZGF5LCA2IEZlYnJ1YXJ5IDIwMTMgMzoxOSBBTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> Message-ID: <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Tue, 5 Feb 2013 11:29:42 -0800 (PST) From: Mark Smith To: "Ackermann, Michael" , joel jaeggli , "Templin, Fred L" , IETF v6ops list In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:29:44 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "Ackermann, Michael" =0A> To: joel jaeggli ; "Templin, Fred= L" ; IETF v6ops list =0A> Cc: = =0A> Sent: Wednesday, 6 February 2013 3:19 AM=0A> Subject: Re: [v6ops] new = draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A>T hanks Joel.=0A> =0A> Y= our comment highlights our more general issue, which is that large enterpri= ses =0A> are not very active at IETF, so would not see issues such as this = until they =0A> deploy IPV6 in production and have a problem where faciliti= es could be shown to =0A> be missing or inadequate.=A0 And yes, ideally sp= eaking, that is way to late in =0A> the process.=A0 =0A>=A0=0A=0AIn the dis= tant past I've worked in enterprise, and then more recently at ISPs. Enterp= rise networks used to be far more controlled than ISPs' networks, because i= n ISP networks customers bring along their own equipment and run applicatio= ns of their own choosing. Troubleshooting should be harder in ISP networks = because of this variety, yet reading through your use cases, it seems not t= o be any more.=0A=0AReading though your use cases, it seems like quite a nu= mber of them are related to faulty middle boxes, which have probably arisen= in Enterprise networks since I've worked on them. The IETF advises against= middle boxes because of these sorts of issues (see RFC4924).=A0It'd be goo= d to get more exact details of the devices that caused the issues, in parti= cular, the devices in use cases 2 and 3.=0A=0AI'm also curious how you came= up with your estimates of the time saved by using IPID. For example, I'd h= ave used standard ping with a few different packet sizes to troubleshoot th= e VPN packet loss issue in use case 4. For a typical packet loss issue, I'm= confident I'd have identified a packet loss issue within 15 to 30 minutes = (more likely 5 to 10), and identified where it was occurring along the VPN = traffic path within an hour or two. So a saving of 9 hours by using IPID ve= rses ping wouldn't be possible.=0A=0ARegards,=0AMark.=0A=0A> This issue is = somewhat separate from our RFC, but is a situation we seek to =0A> address = by getting more large organizations involved in IETF.=A0 We believe that = =0A> would be a win/win situation, benefiting not only the large organizati= ons =0A> themselves, but IETF and networking in general as well! =0A> =0A> = I hope you agree?=0A> =0A> Thanks again!=0A> =0A> Mike=0A> =0A> =0A> =0A> -= ----Original Message-----=0A> From: joel jaeggli [mailto:joelja@bogus.com] = =0A> Sent: Tuesday, February 05, 2013 2:01 AM=0A> To: Ackermann, Michael; T= emplin, Fred L; IETF v6ops list=0A> Subject: Re: [v6ops] new draft: draft-e= lkins-v6ops-ipv6-ipid-needed=0A> =0A> On 2/4/13 9:53 AM, Ackermann, Michael= wrote:=0A>> Thanks for your comments Fred!=0A>> =0A>> The first draft yo= u reference seems to highlight the need for an IPID field =0A> larger than = 16 bits (v4) or 32 bits (v6), due to the much faster networks we =0A> have = today.=A0 We agree and that is very lightly referenced in our RFC.=A0 The= =0A> reason for only lightly, is that we chose to focus on the need for IP= ID at all, =0A> since many at the IETF did not agree this was an issue when= we first introduced =0A> it.=A0 Our original proposal suggested going to = 64 bits as part of the solution, =0A> but for now we have backed off on sol= utions and are focused on convincing the =0A> IETF that the elimination of = IPID as a diagnostic facility, would be bad for end =0A> user organizations= .=0A> To be clear IPv6 never=A0 had an analogous facility except in the fra= gmentation =0A> header, so that state of affairs has been on the books for = about 18 years.=0A>> =0A>> The second draft you referenced is one I was no= t aware of but is very =0A> impressive and well written!=A0 I know it was = focused on tunnels and =0A> encapsulation, but among many other things it s= eems to promote the value of =0A> uniquely identifying packets, in particul= ar ones that could be duplicate, =0A> improper or even malicious.=A0 =A0 If= I am interpreting properly, then we are in =0A> full agreement.=0A>> =0A>>= Our main issue is that information such as provided by IPID can be critic= al =0A> to reliably running sophisticated networks today.=0A>> =0A>> Thank= s again!=0A>> =0A>> Mike=0A>> =0A>> =0A>> =0A>> -----Original Message----= -=0A>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Beh= alf =0A>> Of Templin, Fred L=0A>> Sent: Monday, February 04, 2013 11:51 A= M=0A>> To: IETF v6ops list=0A>> Subject: Re: [v6ops] new draft: draft-elk= ins-v6ops-ipv6-ipid-needed=0A>> =0A>> Hi,=0A>> =0A>> Two drafts the autho= rs should be aware of are "Updated Specification =0A> of the IPv4 ID Field"= :=0A>> =0A>> https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-u= pdate/=0A>> =0A>> and "The Subnetwork Encapsulation and Adapation Layer (S= EAL)":=0A>> =0A>> https://datatracker.ietf.org/doc/draft-templin-intarea-s= eal/=0A>> =0A>> The former is a revised specification of the use of the IP= v4 ID field and =0A> defines the cases in which the ID field does and does = not contain useful =0A> information. The latter is a means for adding a 32-= bit ID field during =0A> encapsulation, where the ID appears in an extensio= n header similar to the way =0A> the IPv6 fragment header currently appears= .=0A>> =0A>> Point being that the IPv4 ID was never intended for purposes = such as =0A> ensuring uniqueness other than for the fragmentation and reass= embly process. =0A> And, for IPv6, there are already ways to add an ID to a= packet if one is needed.=0A>> =0A>> Thanks - Fred=0A>> fred.l.templin@bo= eing.com=0A>> _______________________________________________=0A>> v6ops = mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/mailman/listin= fo/v6ops=0A>> =0A>> =0A>> The information contained in this communication = is highly confidential and =0A> is intended solely for the use of the indiv= idual(s) to whom this communication =0A> is directed. If you are not the in= tended recipient, you are hereby notified that =0A> any viewing, copying, d= isclosure or distribution of this information is =0A> prohibited. Please no= tify the sender, by electronic mail or telephone, of any =0A> unintended re= ceipt and delete the original message without making any copies.=0A>> =A0 = =0A>> =A0 Blue Cross Blue Shield of Michigan and Blue Care Network of Mich= igan are =0A> nonprofit corporations and independent licensees of the Blue = Cross and Blue =0A> Shield Association.=0A>> _____________________________= __________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> http= s://www.ietf.org/mailman/listinfo/v6ops=0A>> =0A> =0A> =0A> =0A> The inform= ation contained in this communication is highly confidential and is =0A> in= tended solely for the use of the individual(s) to whom this communication i= s =0A> directed. If you are not the intended recipient, you are hereby noti= fied that =0A> any viewing, copying, disclosure or distribution of this inf= ormation is =0A> prohibited. Please notify the sender, by electronic mail o= r telephone, of any =0A> unintended receipt and delete the original message= without making any copies.=0A> =0A> Blue Cross Blue Shield of Michigan and= Blue Care Network of Michigan are =0A> nonprofit corporations and independ= ent licensees of the Blue Cross and Blue =0A> Shield Association.=0A> _____= __________________________________________=0A> v6ops mailing list=0A> v6ops= @ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From touch@isi.edu Tue Feb 5 11:40: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 475EF21F8697 for ; Tue, 5 Feb 2013 11:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfEIocNRiqkh for ; Tue, 5 Feb 2013 11:40:41 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 668CD21F8523 for ; Tue, 5 Feb 2013 11:40:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15JePx8006043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 11:40:25 -0800 (PST) Message-ID: <51116029.1090102@isi.edu> Date: Tue, 05 Feb 2013 11:40:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nalini Elkins References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 19:40:42 -0000 On 2/5/2013 11:28 AM, Nalini Elkins wrote: > Joe, > > Well, duplicate packets are often retransmissions. TCP should be issuing the retransmissions, at which point IP should be issuing new IDs. RFC1122 recommends against TCP resending the same segment with the same IP ID, and RFC 6484 confirms this. > If you have > retransmissions, then the other end (or the network) is not absorbing > the flow properly. ... If you have retransmissions, the network is losing segments. Loss can be the result of a transmission error OR congestion. TCP reacts to those losses as if they were congestion only because it is more conservative. I.e.: - if you see exact duplicates, it's because a device is duplicating packets that device needs to be fixed, but that's rare as has already been noted - if you see segment retransmissions, you know there is loss, but you don't know why yet Joe > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* Andrew Yourtchenko > *Cc:* Nalini Elkins ; IETF v6ops list > > *Sent:* Tuesday, February 5, 2013 10:25 AM > *Subject:* Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > PS - I'm particularly interested in an explanation of why duplicate > packets would be an indication of congestion, FWIW. > > Joe > > On 2/5/2013 10:20 AM, Joe Touch wrote: > > Hi, Andrew, > > > > I completely agree; I look forward to a description of the problem. > > > > Joe > > > > On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote: > >> Nalini, Joe, > >> > >> This two-mail exchange vividly illustrates why it's beneficial to > >> describe the problem better, and the properties of the ideal solution > >> (starting with that of IP ID, but not necessarily limited to it), but > >> not jump to solutions themselves straight away. > >> > >> Otherwise it's too easy to get into a situation of a fish and a gull > >> arguing about the sea water. > >> > >> --a > >> > >> > >> On Tue, 5 Feb 2013, Nalini Elkins wrote: > >> > >>> Comparing hashes or packets is not really a workable solution because > >>> there can be true duplicate packets. A hash will only show if > >>> the packets are the same. Unless I am missing something. Sometimes > >>> the problem we are trying to diagnose is how many duplicates > >>> there are. This is an indication of congestion. Some devices create > >>> 'false' duplicates. That is a packet trace taken at that > >>> point will show that the packet is the same but it is only the device > >>> or the trace mechanism tracing incorrectly. Believe me, this > >>> is not an infrequent problem. > >>> > >>> Thanks, > >>> > >>> Nalini Elkins > >>> Inside Products, Inc. > >>> (831) 659-8360 > >>> www.insidethestack.com > >>> > >>> > ___________________________________________________________________________________________________________________________________________ > >>> > >>> > >>> From: Joe Touch > > >>> To: Nalini Elkins > > >>> Cc: Andrew Yourtchenko >; IETF v6ops list > >>> > > >>> Sent: Tuesday, February 5, 2013 8:50 AM > >>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > >>> > >>> FWIW, there are two obvious solutions that work for both IPv4 and IPv6: > >>> > >>> 1) send fragmented (or fragmentable) packets > >>> presuming you have control over a source > >>> > >>> 2) compare either full packets or hashes of the full packets > >>> > >>> "convenience" of an existing field that is not always available isn't > >>> a solution. > >>> > >>> Joe > >>> > >>> > >>> > >>> > > From markzzzsmith@yahoo.com.au Tue Feb 5 11:42: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 C76AC21F8464 for ; Tue, 5 Feb 2013 11:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mKIeiOjnqzj for ; Tue, 5 Feb 2013 11:42:28 -0800 (PST) Received: from nm9.bullet.mail.bf1.yahoo.com (nm9.bullet.mail.bf1.yahoo.com [98.139.212.168]) by ietfa.amsl.com (Postfix) with SMTP id A971E21F848B for ; Tue, 5 Feb 2013 11:42:27 -0800 (PST) Received: from [98.139.212.151] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2013 19:42:25 -0000 Received: from [98.139.212.198] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2013 19:42:25 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 05 Feb 2013 19:42:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 511845.95659.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 61949 invoked by uid 60001); 5 Feb 2013 19:42:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360093345; bh=mV+EJ2JFW4HkhbILM2gBcI05g6jNFXECiz1TMcU0IwA=; 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=tMy4jHgG9bFAwIQVrXUEc/KEtMhnxJcmuF4TnemUJgrbzo/Y3UMhr+E0K/Z+fhy5bX5HhmhefkSvwPUnCUk80BEdCjTK+kCUZ64dyoRY/Us8WHi2pkEkub3yIJvwMUuzTxXW52KunKfntJ6TdRV/WH9/V8fjkQsyVuLXJiXMsNY= 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=Q3g06YQuGRkuop6wCnhUQst9gmGcqkRa1B99M3SotDluLPymvV0qYZmnc1JaIGCpLkTPIVuNwjkpXpMUI3xuXXUNk+zmSRsouv3lpkydFWBu4Ud3Nb271Xg1PiJsfUDd1UaG5QtnIaYjHg2RYVVgvSEqyyhwWRK/FUn2ciSxocU=; X-YMail-OSG: JbGoiOEVM1n3jz60iCRh96K9Fn7IKv.YYNtGw4LDov2PyHj 1VxHZPWX3bypgu8SdAzSjsgm6lBq77Rh0z9VZQEOzZGqUktgtyUaqgBI4Sq4 ti7pYcEwT6JS0gbi5xZnTSEP12WmKGoOLv3zsZ92hnFShEH362BnSTWDEG2J ryKKwQKt0lgDUz6zfMSvAC7__okgsfHL2cMDn7GPJzayj6vYj0pWePm4Mgyk UIWdmkuuxAkb1J2SRZEMRBVrLmHmaexyGOpYVM3_yAwHqu_yadWj.E.hs.p8 xF62rWAvEQ9TmULcLyAoQ.3N74TCLTuMWr1NIBbU.Y1GXwjLRHeYxnevWxte 3wa9rSxbiu4QCafS8l7wEifiDjx06Np8IVNdZKGRZ4cQam2..4o6N.61G_wu fyIp6X8WTqrqTT.8aHfVeNLrMfeDSLbvYRWdumuRGPiakodVONH9Em2b6DJl iOHQKduazXSfnW8XR6.aIRxU349mv7uJhdwFoiw3aBjgYz2oxb0l8l0HS6bN Z8r6V64XhOM.TEROsETTwqEsHXA3bhxTWNEl6DqJw_VcC3c47ntyoUMYKBHh z5jrRvkFIogmj1alXGKqPktA4IEo0.E5XLqjRxiaG Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 05 Feb 2013 11:42:25 PST X-Rocket-MIMEInfo: 001.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBOYWxpbmkgRWxraW5zIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4KPlRvOiBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU.OyBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT4gCj5DYzogSUVURiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBXZWRuZXNkYXksIDYgRmVicnVhcnkgMjAxMyA2OjI4IEFNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Message-ID: <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 5 Feb 2013 11:42:25 -0800 (PST) From: Mark Smith To: Nalini Elkins , Joe Touch , Andrew Yourtchenko In-Reply-To: <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:42:28 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Nalini Elkins =0A>To: Joe Touch ; Andrew Y= ourtchenko =0A>Cc: IETF v6ops list = =0A>Sent: Wednesday, 6 February 2013 6:28 AM=0A>Subject: Re: [v6ops] new dr= aft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A>=0A>Joe,=0A>=0A>=0A>Well, = duplicate packets are often retransmissions.=A0=0A>=0A>=0A=0AThis can be qu= ite easily determined by comparing sent packet counts at one end with recei= ved packet counts at the other. I'd consider doing that to be much easier t= han capturing 1000s of packets and then looking through them with an analys= er to try to spot duplicate packets. I consider using a packet analyser to = be a last resort when troubleshooting because you're usually dealing with 1= 000s, 10 000s or 100 000s of packets, and trying to spot a trend or pick th= e bad individual packet. It can also be quite onerous to setup the packet c= apture and the volume of data can huge.=0A=0ASome of these examples are sta= rting sound like you've been taking the approach of "how can we use IPID to= troubleshoot this" rather than "what is the most effective tool to trouble= shoot this", of which IPID might be one for a particular situation.=A0=0A= =0A>=0A>=0A>=A0 If you have retransmissions, then the other end (or the net= work) is not absorbing the flow properly. =A0Then, on our end, we need to s= ee if we have allocated enough bandwidth, it is going over a sub-optimal ro= ute, etc.=0A>=A0=0A>Thanks,=0A>=0A>=0A>Nalini Elkins=0A>Inside Products, In= c.=0A>(831) 659-8360=0A>www.insidethestack.com=0A>=0A>=0A>=0A>_____________= ___________________=0A> From: Joe Touch =0A>To: Andrew Yourt= chenko =0A>Cc: Nalini Elkins ; IETF v6ops list =0A>Sent: Tuesday, February 5, = 2013 10:25 AM=0A>Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ip= id-needed=0A> =0A>PS - I'm particularly interested in an explanation of why= duplicate =0A>packets would be an indication of congestion, FWIW.=0A>=0A>J= oe=0A>=0A>On 2/5/2013 10:20 AM, Joe Touch wrote:=0A>> Hi, Andrew,=0A>>=0A>>= I completely agree; I look forward to a description of the problem.=0A>>= =0A>> Joe=0A>>=0A>> On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote:=0A>>> Na= lini, Joe,=0A>>>=0A>>> This two-mail exchange vividly illustrates why it's = beneficial to=0A>>> describe the problem better, and the properties of the = ideal solution=0A>>> (starting with that of IP ID, but not necessarily limi= ted to it), but=0A>>> not jump to solutions themselves straight away.=0A>>>= =0A>>> Otherwise it's too easy to get into a situation of a fish and a gull= =0A>>> arguing about the sea water.=0A>>>=0A>>> --a=0A>>>=0A>>>=0A>>> On Tu= e, 5 Feb 2013, Nalini Elkins=0Awrote:=0A>>>=0A>>>> Comparing hashes or pack= ets is not really a workable solution because=0A>>>> there can be true dupl= icate packets.=A0 A hash will only show if=0A>>>> the packets are the same.= =A0=A0=A0Unless I am missing something.=A0=A0=A0Sometimes=0A>>>> the proble= m we are trying to diagnose is how many duplicates=0A>>>> there are.=A0 Thi= s is an indication of congestion.=A0=A0=A0Some devices create=0A>>>> 'false= ' duplicates.=A0 That is a packet trace taken at that=0A>>>> point will sho= w that the packet is the same but it is only the device=0A>>>> or the trace= mechanism tracing incorrectly.=A0 Believe me, this=0A>>>> is not an infreq= uent problem.=0A>>>>=0A>>>> Thanks,=0A>>>>=0A>>>> Nalini Elkins=0A>>>> Insi= de Products, Inc.=0A>>>> (831) 659-8360=0A>>>> www.insidethestack.com=0A>>>= >=0A>>>> __________________________________________________________________= _________________________________________________________________________= =0A>>>>=0A>>>>=0A>>>> From: Joe Touch =0A>>>> To: Nalini Elk= ins =0A>>>> Cc: Andrew Yourtchenko ; IETF v6ops list=0A>>>> =0A>>>> Sent: Tuesda= y, February 5, 2013 8:50 AM=0A>>>> Subject: Re: [v6ops] new draft:=0Adraft-= elkins-v6ops-ipv6-ipid-needed=0A>>>>=0A>>>> FWIW, there are two obvious sol= utions that work for both IPv4 and IPv6:=0A>>>>=0A>>>> 1) send fragmented (= or fragmentable) packets=0A>>>>=A0 =A0=A0=A0presuming you have control over= a source=0A>>>>=0A>>>> 2) compare either full packets or hashes of the ful= l packets=0A>>>>=0A>>>> "convenience" of an existing field that is not alwa= ys available isn't=0A>>>> a solution.=0A>>>>=0A>>>> Joe=0A>>>>=0A>>>>=0A>>>= >=0A>>>>=0A>=0A>=0A>=0A>_______________________________________________=0A>= v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listin= fo/v6ops=0A>=0A>=0A> From nalini.elkins@insidethestack.com Tue Feb 5 11:42: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 188BA21F8464 for ; Tue, 5 Feb 2013 11:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KV3lDAv5vQ2 for ; Tue, 5 Feb 2013 11:42:27 -0800 (PST) Received: from nm5-vm0.access.bullet.mail.mud.yahoo.com (nm5-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.155]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2CB21F846B for ; Tue, 5 Feb 2013 11:42:27 -0800 (PST) Received: from [66.94.237.194] by nm5.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 19:42:21 -0000 Received: from [66.94.237.108] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 19:42:21 -0000 Received: from [127.0.0.1] by omp1013.access.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 19:42:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 137260.29330.bm@omp1013.access.mail.mud.yahoo.com Received: (qmail 28728 invoked by uid 60001); 5 Feb 2013 19:42:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360093340; bh=ATnFx/GMA1gR0/DyVEZNKowKQvWLFKgfCuyzQ9y7FGo=; 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=z7VSVcmr+OA+05KM21PzvyHVJbxrz5ZsJNeak98lDL2cXdE96UisQqHbCb+dlxoqOEOfIz2W2ZrWcmFgvIoVinzoNuMPMwAbQYWFY2phmvpgfOwKRrnNx1Wp4eALYXlZLSy5ZMvcQQJx0pbgwAnb++lfZnPem8ZALTj4oA3+d3c= X-YMail-OSG: 0MSrCvsVM1m9g4x0D2qrdwV2kcSIpu_vtNMlj4P17almpdC z0lEnbvu71wcdeoCRV9g1AZd7mZkb2QcuFZmef646oUhDAiM_YQWmt2KaFfp OK.7H.aKRHtWJER5EEbVtOLMcYAVVRwIG7B5rJl3cS1Bfh80nZFHnloUHqOT VjjfuVS8xrQrAR9lVErgbuJWkGlk3YG5kdJz9StTrisMSdQjzsNHrY2P8cI7 CYi72ACJB38667vZ.ks5P0_LLQF2Z5dBX12QAi8tOYjWTSPNPWZQd3kBNuBB 8gZQX9nwByMD4FoddWmXu_N7sDv1Lvh4D6eg52w4MklOlg1tpwCVrlOkzpDN Cy3PPqgqMaqZHi7EbXachhxFHs_.6HDnhtC2s4ESSxCjcM5iPsIg5a2HxRnQ PWGxTU8JFwBJVQi3g4Mh6elOHXjz3axo2XLLN6Yx29Z1BCnSx7hR5C9LOyDO .b_URN5kquIpwlGGSAbofN8tnIjfcCIoHSeoW_ILPm.erP1yo4AFMCHJIdVT 1w3QUN8BlihEoLxK4Dps58j6x43raOD_pqtYXz1Bmyz8h5tQOgGj7tnFYEbk KZyHhKs3Op1bTbM3180R852A8Q79EoCBvH8plzYthmgDqkg-- Received: from [12.249.100.42] by web2809.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 11:42:20 PST X-Rocket-MIMEInfo: 001.001, TWFyaywKClRoZSBWUE4gaXNzdWUsIHdoaWNoIHdlIGhhdmUgcnVuIGludG8gc2V2ZXJhbCB0aW1lcywgd2FzIGFuIGludGVybWl0dGVudCBwcm9ibGVtIHdoZXJlIGRpZmZlcmVudCBwYXJ0aWVzIG93bmVkIGRpZmZlcmVudCBwYXJ0cyBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuIMKgUGluZ3MgYXJlIG91dCBvZiB0aGUgcXVlc3Rpb24uIMKgIFRoZXkgYXJlIGJsb2NrZWQuCgpUaGVzZSBwcm9ibGVtcyBvZnRlbiBnbyBvbiBmb3Igd2Vla3Mgd2l0aCBtdWNoIGZpbmdlciBwb2ludGluZyBoYXBwZW5pbmcuIMKgIFQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> Message-ID: <1360093340.17180.YahooMailNeo@web2809.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 11:42:20 -0800 (PST) From: Nalini Elkins To: Mark Smith , "Ackermann, Michael" , joel jaeggli , "Templin, Fred L" , IETF v6ops list In-Reply-To: <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1574859133-506760097-1360093340=:17180" Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:42:29 -0000 ---1574859133-506760097-1360093340=:17180 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mark,=0A=0AThe VPN issue, which we have run into several times, was an inte= rmittent problem where different parties owned different parts of the infra= structure. =A0Pings are out of the question. =A0 They are blocked.=0A=0AThe= se problems often go on for weeks with much finger pointing happening. =A0 = The 9 hours is an estimate.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside = Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______= _________________________=0A From: Mark Smith = =0ATo: "Ackermann, Michael" ; joel jaeggli ; "Templin, Fred L" ; IETF v6ops list =0ASent: Tuesday, February 5, 2013 11:29 AM=0ASubject: Re: [= v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A =0A=0A=0A=0A=0A---= -- Original Message -----=0A> From: "Ackermann, Michael" =0A> To: joel jaeggli ; "Templin, Fred L" ; IETF v6ops list =0A> Cc: =0A> Sent: Wedne= sday, 6 February 2013 3:19 AM=0A> Subject: Re: [v6ops] new draft: draft-elk= ins-v6ops-ipv6-ipid-needed=0A> =0A>T hanks Joel.=0A> =0A> Your comment high= lights our more general issue, which is that large enterprises =0A> are not= very active at IETF, so would not see issues such as this until they =0A> = deploy IPV6 in production and have a problem where facilities could be show= n to =0A> be missing or inadequate.=A0=A0 And yes, ideally speaking, that i= s way to late in =0A> the process.=A0 =0A>=A0=0A=0AIn the distant past I've= worked in enterprise, and then more recently at ISPs. Enterprise networks = used to be far more controlled than ISPs' networks, because in ISP networks= customers bring along their own equipment and run applications of their ow= n choosing. Troubleshooting should be harder in ISP networks because of thi= s variety, yet reading through your use cases, it seems not to be any more.= =0A=0AReading though your use cases, it seems like quite a number of them a= re related to faulty middle boxes, which have probably arisen in Enterprise= networks since I've worked on them. The IETF advises against middle boxes = because of these sorts of issues (see RFC4924).=A0It'd be good to get more = exact details of the devices that caused the issues, in particular, the dev= ices in use cases 2 and 3.=0A=0AI'm also curious how you came up with your = estimates of the time saved by using IPID. For example, I'd have used stand= ard ping with a few different packet sizes to troubleshoot the VPN packet l= oss issue in use case 4. For a typical packet loss issue, I'm confident I'd= have identified a packet loss issue within 15 to 30 minutes (more likely 5= to 10), and identified where it was occurring along the VPN traffic path w= ithin an hour or two. So a saving of 9 hours by using IPID verses ping woul= dn't be possible.=0A=0ARegards,=0AMark.=0A=0A> This issue is somewhat separ= ate from our RFC, but is a situation we seek to =0A> address by getting mor= e large organizations involved in IETF.=A0=A0 We believe that =0A> would be= a win/win situation, benefiting not only the large organizations =0A> them= selves, but IETF and networking in general as well! =0A> =0A> I hope you ag= ree?=0A> =0A> Thanks again!=0A> =0A> Mike=0A> =0A> =0A> =0A> -----Original = Message-----=0A> From: joel jaeggli [mailto:joelja@bogus.com] =0A> Sent: Tu= esday, February 05, 2013 2:01 AM=0A> To: Ackermann, Michael; Templin, Fred = L; IETF v6ops list=0A> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-i= pv6-ipid-needed=0A> =0A> On 2/4/13 9:53 AM, Ackermann, Michael wrote:=0A>>= =A0 Thanks for your comments Fred!=0A>> =0A>>=A0 The first draft you refere= nce seems to highlight the need for an IPID field =0A> larger than 16 bits = (v4) or 32 bits (v6), due to the much faster networks we =0A> have today.= =A0=A0 We agree and that is very lightly referenced in our RFC.=A0=A0 The = =0A> reason for only lightly, is that we chose to focus on the need for IPI= D at all, =0A> since many at the IETF did not agree this was an issue when = we first introduced =0A> it.=A0=A0 Our original proposal suggested going to= 64 bits as part of the solution, =0A> but for now we have backed off on so= lutions and are focused on convincing the =0A> IETF that the elimination of= IPID as a diagnostic facility, would be bad for end =0A> user organization= s.=0A> To be clear IPv6 never=A0 had an analogous facility except in the fr= agmentation =0A> header, so that state of affairs has been on the books for= about 18 years.=0A>> =0A>>=A0 The second draft you referenced is one I was= not aware of but is very =0A> impressive and well written!=A0=A0 I know it= was focused on tunnels and =0A> encapsulation, but among many other things= it seems to promote the value of =0A> uniquely identifying packets, in par= ticular ones that could be duplicate, =0A> improper or even malicious.=A0 = =A0 If I am interpreting properly, then we are in =0A> full agreement.=0A>>= =0A>>=A0 Our main issue is that information such as provided by IPID can b= e critical =0A> to reliably running sophisticated networks today.=0A>> =0A>= >=A0 Thanks again!=0A>> =0A>>=A0 Mike=0A>> =0A>> =0A>> =0A>>=A0 -----Origin= al Message-----=0A>>=A0 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@= ietf.org] On Behalf =0A>>=A0 Of Templin, Fred L=0A>>=A0 Sent: Monday, Febru= ary 04, 2013 11:51 AM=0A>>=A0 To: IETF v6ops list=0A>>=A0 Subject: Re: [v6o= ps] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A>> =0A>>=A0 Hi,=0A>> = =0A>>=A0 Two drafts the authors should be aware of are "Updated Specificati= on =0A> of the IPv4 ID Field":=0A>> =0A>>=A0 https://datatracker.ietf.org/d= oc/draft-ietf-intarea-ipv4-id-update/=0A>> =0A>>=A0 and "The Subnetwork Enc= apsulation and Adapation Layer (SEAL)":=0A>> =0A>>=A0 https://datatracker.i= etf.org/doc/draft-templin-intarea-seal/=0A>> =0A>>=A0 The former is a revis= ed specification of the use of the IPv4 ID field and =0A> defines the cases= in which the ID field does and does not contain useful =0A> information. T= he latter is a means for adding a 32-bit ID field during =0A> encapsulation= , where the ID appears in an extension header similar to the way =0A> the I= Pv6 fragment header currently appears.=0A>> =0A>>=A0 Point being that the I= Pv4 ID was never intended for purposes such as =0A> ensuring uniqueness oth= er than for the fragmentation and reassembly process. =0A> And, for IPv6, t= here are already ways to add an ID to a packet if one is needed.=0A>> =0A>>= =A0 Thanks - Fred=0A>>=A0 fred.l.templin@boeing.com=0A>>=A0 _______________= ________________________________=0A>>=A0 v6ops mailing list=0A>>=A0 v6ops@i= etf.org=0A>>=A0 https://www.ietf.org/mailman/listinfo/v6ops=0A>> =0A>> =0A>= >=A0 The information contained in this communication is highly confidential= and =0A> is intended solely for the use of the individual(s) to whom this = communication =0A> is directed. If you are not the intended recipient, you = are hereby notified that =0A> any viewing, copying, disclosure or distribut= ion of this information is =0A> prohibited. Please notify the sender, by el= ectronic mail or telephone, of any =0A> unintended receipt and delete the o= riginal message without making any copies.=0A>> =A0 =0A>> =A0=A0 Blue Cross= Blue Shield of Michigan and Blue Care Network of Michigan are =0A> nonprof= it corporations and independent licensees of the Blue Cross and Blue =0A> S= hield Association.=0A>>=A0 _______________________________________________= =0A>>=A0 v6ops mailing list=0A>>=A0 v6ops@ietf.org=0A>>=A0 https://www.ietf= .org/mailman/listinfo/v6ops=0A>> =0A> =0A> =0A> =0A> The information contai= ned in this communication is highly confidential and is =0A> intended solel= y for the use of the individual(s) to whom this communication is =0A> direc= ted. If you are not the intended recipient, you are hereby notified that = =0A> any viewing, copying, disclosure or distribution of this information i= s =0A> prohibited. Please notify the sender, by electronic mail or telephon= e, of any =0A> unintended receipt and delete the original message without m= aking any copies.=0A> =0A> Blue Cross Blue Shield of Michigan and Blue Care= Network of Michigan are =0A> nonprofit corporations and independent licens= ees of the Blue Cross and Blue =0A> Shield Association.=0A> _______________= ________________________________=0A> v6ops mailing list=0A> v6ops@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> =0A___________________= ____________________________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps:= //www.ietf.org/mailman/listinfo/v6ops ---1574859133-506760097-1360093340=:17180 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Mark,

The VPN issue, which we= have run into several times, was an intermittent problem where different p= arties owned different parts of the infrastructure.  Pings are out of = the question.   They are blocked.

<= /span>
These problems often go on= for weeks with much finger pointing happening.   The 9 hours is an es= timate.
 
Thanks,

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

From: Mark Smith <markzzzsmith@yahoo.com.au>
To: "Ackermann, Michael" <MAckermann@= bcbsm.com>; joel jaeggli <joelja@bogus.com>; "Templin, Fred L" <= ;Fred.L.Templin@boeing.com>; IETF v6ops list <v6ops@ietf.org>
= Sent: Tuesday, February 5, 2013 11= :29 AM
Subject: Re: [v= 6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
=0A



----- Original Message -----
> From: "Ackermann, = Michael" <MAckermann@bcbsm.com>
> To: joel jaeggli <= ;jo= elja@bogus.com>; "Templin, Fred L" <Fred.L.Templin= @boeing.com>; IETF v6ops list <v6ops@ietf.org>
> Cc:
&g= t; Sent: Wednesday, 6 February 2013 3:19 AM
> Subject: Re: [v6ops] ne= w draft: draft-elkins-v6ops-ipv6-ipid-needed
>
>T hanks Joel.<= br>>
> Your comment highlights our more general issue, which is t= hat large enterprises
> are not very active at IETF, so would not se= e issues such as this until they
> deploy IPV6 in production and hav= e a problem where facilities could be shown to
> be missing or inadequate. = ;  And yes, ideally speaking, that is way to late in
> the proc= ess. 
> 

In the distant past I've worked in enterpr= ise, and then more recently at ISPs. Enterprise networks used to be far mor= e controlled than ISPs' networks, because in ISP networks customers bring a= long their own equipment and run applications of their own choosing. Troubl= eshooting should be harder in ISP networks because of this variety, yet rea= ding through your use cases, it seems not to be any more.

Reading th= ough your use cases, it seems like quite a number of them are related to fa= ulty middle boxes, which have probably arisen in Enterprise networks since = I've worked on them. The IETF advises against middle boxes because of these= sorts of issues (see RFC4924). It'd be good to get more exact details= of the devices that caused the issues, in particular, the devices in use cases 2 and 3.

I'm also curious how you came up with your es= timates of the time saved by using IPID. For example, I'd have used standar= d ping with a few different packet sizes to troubleshoot the VPN packet los= s issue in use case 4. For a typical packet loss issue, I'm confident I'd h= ave identified a packet loss issue within 15 to 30 minutes (more likely 5 t= o 10), and identified where it was occurring along the VPN traffic path wit= hin an hour or two. So a saving of 9 hours by using IPID verses ping wouldn= 't be possible.

Regards,
Mark.

> This issue is somewhat= separate from our RFC, but is a situation we seek to
> address by g= etting more large organizations involved in IETF.   We believe th= at
> would be a win/win situation, benefiting not only the large org= anizations
> themselves, but IETF and networking in general as well!=
>
> I hope you agree?
>
> Thanks again!
>
> Mike
>
>
>
> -----Origi= nal Message-----
> From: joel jaeggli [mailto:joelja@bogus.com]
= > Sent: Tuesday, February 05, 2013 2:01 AM
> To: Ackermann, Michae= l; Templin, Fred L; IETF v6ops list
> Subject: Re: [v6ops] new draft:= draft-elkins-v6ops-ipv6-ipid-needed
>
> On 2/4/13 9:53 AM, Ac= kermann, Michael wrote:
>>  Thanks for your comments Fred!>>
>>  The first draft you reference seems to highlig= ht the need for an IPID field
> larger than 16 bits (v4) or 32 bits = (v6), due to the much faster networks we
> have today.   W= e agree and that is very lightly referenced in our RFC.   The > reason for only lightly, is that we chose to focus on the need for IP= ID at all,
> since many at the IETF did not agree this was an issue when we first introduced
> it.   Our original propo= sal suggested going to 64 bits as part of the solution,
> but for no= w we have backed off on solutions and are focused on convincing the
>= ; IETF that the elimination of IPID as a diagnostic facility, would be bad = for end
> user organizations.
> To be clear IPv6 never  h= ad an analogous facility except in the fragmentation
> header, so th= at state of affairs has been on the books for about 18 years.
>> <= br>>>  The second draft you referenced is one I was not aware of= but is very
> impressive and well written!   I know it wa= s focused on tunnels and
> encapsulation, but among many other thing= s it seems to promote the value of
> uniquely identifying packets, i= n particular ones that could be duplicate,
> improper or even malici= ous.    If I am interpreting properly, then we are in
> full agreement.
>>
>>  Our main issue is = that information such as provided by IPID can be critical
> to relia= bly running sophisticated networks today.
>>
>>  Th= anks again!
>>
>>  Mike
>>
>> >>
>>  -----Original Message-----
>>  = From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ie= tf.org] On Behalf
>>  Of Templin, Fred L
>>&nbs= p; Sent: Monday, February 04, 2013 11:51 AM
>>  To: IETF v6op= s list
>>  Subject: Re: [v6ops] new draft: draft-elkins-v6ops= -ipv6-ipid-needed
>>
>>  Hi,
>>
>&g= t;  Two drafts the authors should be aware of are "Updated Specification
> of the IPv4 ID Field":
>>
>>&nbs= p; https://datatracker.ietf.org/doc/draft-ietf-intar= ea-ipv4-id-update/
>>
>>  and "The Subnetwork E= ncapsulation and Adapation Layer (SEAL)":
>>
>>  https://datatracker.ietf.org/doc/draft-templin-intarea-seal/<= /a>
>>
>>  The former is a revised specification of= the use of the IPv4 ID field and
> defines the cases in which the I= D field does and does not contain useful
> information. The latter i= s a means for adding a 32-bit ID field during
> encapsulation, where= the ID appears in an extension header similar to the way
> the IPv6= fragment header currently appears.
>>
>>  Point being that the IPv4 ID was never intended for purposes such as
> en= suring uniqueness other than for the fragmentation and reassembly process. =
> And, for IPv6, there are already ways to add an ID to a packet if = one is needed.
>>
>>  Thanks - Fred
>>&nbs= p; fred.l.templin@boeing.com
>>  _________= ______________________________________
>>  v6ops mailing list=
>>  v6ops@ietf.org
>>  https://www.ietf.org/mailma= n/listinfo/v6ops
>>
>>
>>  The inform= ation contained in this communication is highly confidential and
> i= s intended solely for the use of the individual(s) to whom this communicati= on
> is directed. If you are not the intended recipient, you are hereb= y notified that
> any viewing, copying, disclosure or distribution o= f this information is
> prohibited. Please notify the sender, by ele= ctronic mail or telephone, of any
> unintended receipt and delete th= e original message without making any copies.
>>  
>&g= t;    Blue Cross Blue Shield of Michigan and Blue Care Network of= Michigan are
> nonprofit corporations and independent licensees of = the Blue Cross and Blue
> Shield Association.
>>  ____= ___________________________________________
>>  v6ops mailing= list
>>  v6ops@ietf.org
>>  https://www.ietf.org/m= ailman/listinfo/v6ops
>>
>
>
>
> The information contained in this communication is highly confidential and= is
> intended solely for the use of the individual(s) to whom this = communication is
> directed. If you are not the intended recipient, = you are hereby notified that
> any viewing, copying, disclosure or d= istribution of this information is
> prohibited. Please notify the s= ender, 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 <= br>> nonprofit corporations and independent licensees of the Blue Cross = and Blue
> Shield Association.
> _____________________________= __________________
> v6ops mailing list
> v6ops@ietf.org
> <= a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops
> =
_______________________________________________
v6ops mailing listv6ops= @ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


=
---1574859133-506760097-1360093340=:17180-- From joelja@bogus.com Tue Feb 5 11:47: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 39BAE21F8464 for ; Tue, 5 Feb 2013 11:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRJb6lDE2UDT for ; Tue, 5 Feb 2013 11:47:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C008221F84C8 for ; Tue, 5 Feb 2013 11:47:08 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r15Jl81Z078489 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 5 Feb 2013 19:47:08 GMT (envelope-from joelja@bogus.com) Message-ID: <511161B7.9060808@bogus.com> Date: Tue, 05 Feb 2013 11:47:03 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG References: <510EDE64.8080906@bogus.com> In-Reply-To: <510EDE64.8080906@bogus.com> X-Forwarded-Message-Id: <510EDE64.8080906@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 05 Feb 2013 19:47:08 +0000 (UTC) Subject: [v6ops] Fwd: Re: Some questions on draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 19:47:10 -0000 for the record since this was my commentary on the response to our traditional questions. -------- Original Message -------- Subject: Re: Some questions on draft-elkins-v6ops-ipv6-ipid-needed Date: Sun, 03 Feb 2013 14:02:12 -0800 From: joel jaeggli To: Nalini Elkins , "fred@cisco.com" , "draft-elkins-v6ops-ipv6-ipid-needed@tools.ietf.org" CC: v6ops-chairs@tools.ietf.org , Bill Jouris , Ackermann Michael , Larry Kratzke , keven.haining@usbank.com Inline, On 2/3/13 11:29 AM, Nalini Elkins wrote: > Fred, > > Please find my comments below your questions. > > > Thanks, > > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > > ----- Original Message ----- > From: "fred@cisco.com" > To: draft-elkins-v6ops-ipv6-ipid-needed@tools.ietf.org > Cc: v6ops-chairs@tools.ietf.org > Sent: Saturday, February 2, 2013 5:45 AM > Subject: Some questions on draft-elkins-v6ops-ipv6-ipid-needed > >> Let me ask some questions. This is not intended to put you off or offend, but to help the chairs in understanding where the draft fits in the big scheme of things. > First, let me preface this discussion by saying that it seems that there may be a disconnect between the parties (IETF and some end-user companies) and we have an opportunity here to start to work together. The following is what I believe to be the case, please correct me if I am wrong. > > 1. The RFCs decided on by the IETF apply not just to the Internet but to large, private networks or Intranets. > 2. Some of these Intranets are quite large indeed. For example, I worked in network design and planning for Chevron for many years & and at that time Chevron had its own microwave network in the Gulf region, etc. Obviously, BCBS Michigan and US Bank run some of the largest intranets in the world. > 3. The companies who run these intranets are responsible for the traffic end-to-end. Huge amounts of money are involved. Time saved in diagnostics means real dollars for their bottom line. > 4. The IETF generally, I believe, does not realize the complexity of these internal networks. > 5. This is because the end-user companies, by and large, do not understand they need to participate in the IETF! > > To quote one of the people in my group: > > "A business like ours understands the significance of lobbying Congress for legislation, but they don't understand the significance of lobbying the IETF for network architecture. Even though IPv6 has been around for 10 years or more, we're just now starting to seriously take a look at using it. We did not have the foresight, leadership, finances, etc., 10 years ago to realize we should have been lobbying the IETF for the IPID when IPv6 was first designed. (If our RFC is not approved it might take another 5-10 years before enough organizations start feeling the pain of not having an IPv6 IPID that they'll begin to realize there is a problem at all. Much less have any idea what needs to be done to fix the problem.)" > > Having said that, I HOPE(!) to have 5 end-user companies all together attending the IETF in Orlando. These are cross-industry. (One is in the Fortune 20, another is one of the underpinnings of our financial system, and of course, BCBS Michigan and US Bank). Now, it is hard persuading companies to do something - e.g. attend IETF - that they have never done before. Especially when it involves spending money. I would like to suggest working together to do some outreach; as it is in the interests of both IETF and end user companies to participate in protocol discussions. I will bring this up again after answering all your questions. > > Also, it is somewhat disconcerting that, in order to get on the agenda for the IETF, we need to have support for our idea on the IETF email list. I'm not sure you're interpreting that correctly. the v6ops chairs are looking for evidence of involvement. Support is more equivocally positive. We are above all concerned that documents that get on the agenda are things that people are prepared to discuss, because that ends up producing in actionable results, notwithstanding what sort of action it results in. > To give an analogy, it is somewhat like saying if a bunch of zebras wants to join a herd of giraffes in doing something, then the zebras need support from the giraffes before they can join. Well, the giraffes may not understand the needs of the zebras and some of the needs may well be conflicting. So, it is hard to get support! And, that is why we are trying to join the discussion - so we can change the discussion from the inside. And, as we are new, I am sure that we are not obeying all of the protocols of the group - if indeed, we even understand them! Let me assure you, we are trying. Please let us know when we unwittingly miss something. > >> 1) Please provide a succinct problem statement for your draft. What problem/issue is this draft discussing? What operational problems does the proposal address in real life networks? > A sequence number such as IPv4 IPID helps reduce the time for problem diagnostics. At its most basic, the operational problems involve connections which are failing and connections which are slow. This, obviously, takes many forms depending on the applications involved - for example, http which kicks off SSL, law enforcement using cell phones over a VPN, etc. The point being that an end-to-end connection needs to be diagnosed. Hence, the networks affected are end-user networks - primarily intranets but not exclusively. Such problems are also complex enough to require packet tracing rather than log or SNMP analysis. We have provided 5 examples of such problems in the Use Cases in our 6man and v6ops drafts. So, you also have a previous draft, which received some dicussion but, I'm not sure the problem statement adequately conveys how ipid's are used for troubleshooting or responds to dicussion of the previous draft. In my own network I have a little trouble understanding how to do this, I would have a lot of trouble extracting ipids from ipv4 headers at most hops other than end systems and L4 or higher middle boxes, e.g. it's really hard to ask a router to do this, installing a mediation device across a 16 x 10Gb path is a non-starter, diverting traffic for a given destination through a device that allows measurement is straight forward but clearly what you're measuring at that point relative to the common path is an open question. putting it in and ipv6 extension header, is potentially even more expensive because it implies parsing a big chunk of a potentially large header chain (which is a known problem), which in fact the protocol expects you not to parse it all (parsing L4 headers headers when you have a extension header chain to look through is a known problem too) . In our case Largely this means we rely on a lot of statistical sampling and end to end measurement the latter case being where missing data-grams are readily identified... v6 extension headers are multiples of 8 octetes, so a device that originates this header is either sending smaller tcp/udp datagrams larger packets or is deliberately fragmenting all of which seem like really bad things to introduce to the measurement path, e.g. part of the value of an ipid from your current vantage point is that it's present. >> >> 2) Where does this draft or presentation fits into v6ops' current charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s) of the charter is preferable. > I believe this fits into section 1: > > "Solicit input from network operators *and users* [emphasis added] to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. " > > In your categorization, I believe we are 'users'. In your terminology, the telecommunications vendors (Comcast, AT&T, etc) are 'operators'. I don't know if the charter needs to be amended to include companies such as ourselves or if a new group needs to be formed? We are very impacted by the TCP/IP protocols and should have a voice somehow. If you operate a network you're an operator as far as I'm concerned. Carriers are something else. > >> >> 3) Who is this draft's audience? > Anyone who is interested in assisting end-user companies implement and use IPv6 effectively. > >> >> 4) Have any operators expressed interest in this draft or its problem space, either via review or other discussion? > If we understand correctly, by 'operators', you mean the telecommunications vendors (Comcast, AT&T, etc.). If that is correct, then I would venture to say none of them have any compelling business interest. Other than to make sure that their customers - end user companies - have the diagnostics that they need. Now, the reason that they or network equipment vendors, would not care about something such as IPID is, to put it simplistically, that they are responsible for getting bytes from one place to another successfully. If they are not the RIGHT bytes, or if it is taking an unacceptably long time to get them there, that is someone else's job to figure that out. Well, as the people working for and supporting the end user companies, we are the 'someone else'. > > Having said that, I do know some people at Comcast reasonably well and have asked them offline to review our submission and await their feedback. (I have also asked people at Cisco & university professors where my daughter goes to school & federal agencies who are customers & friends.) > > As, one of the others in my group put it: > > "For the 99% of the world who uses TCP/IP in one way or another they probably don't even know the IPID exists. Even if they did, they might not have any understanding of its use or care about it. For the 1% of the TCP/IP world that troubleshoots problems, especially complex problems, we've likely run into one or more occasions in which it was essential to have the IPID to get quickly to the root of the problem." > > I would say that this is a problem that is relevant probably exclusively to end-user companies. In particular, the 1% who have the largest and most complex networks. But, I just worked on a consulting contract for quite a small financial where I used IPID quite useful. > > I have also talked this over with the original developer of a network analysis product that you will all have heard of, and who has his own entry in Wikipedia (that passes for fame in today's world! Sigh.) I am trying to get him on the phone to see if he will comment publicly or at least let me forward his email to you. But, as it is Superbowl Sunday, it may take a day or two. He understands the issue VERY well and in fact, read over our draft submission. Let me quote from his email: > > "I think this is a great idea! An explicit (and separate) [IPID] diagnostic field for IPv6 would definitely be helpful for xxx and many other tools. > > "Two quick notes: > > "You might want to add a SHOULD NOT or MUST NOT explicitly stating that gateways must not modify or remove the IPID from packets that they forward. > Many OSes support random IP IDs (e.g. my laptop has a "net.inet.ip.random_id" sysctl which is currently enabled), primarily to improve security. Is that needed here? " > > As I say, I will ask him to comment publicly. > > >> >> 5) Is this draft pursuing discussion in any other WGs? If so, please list them here, along with rationale for the interaction with multiple WGs in parallel. > 6Man. We understood that the actual solution was to be presented in 6man. We may have misunderstood. Also, the 6man charter says that, if they are not the right venue for a particular proposed RFC, they are the venue to advise on which Working Group is the right place. Protocol change and in this cases the proposed creation of a new extension header is unequivocally the domain of 6man. there is certainly an operational component of the problem statement. I don't see any reason not to dicuss it. > >> >> 6) Is any protocol work being recommended in the draft? >> > In the 6man draft, we asked for a Destination Options header, to include the IPID field. But, this is ONLY a suggestion. What we really hope to get is a collaborative effort with current IETF members and some of us to come up with a solution. This, I think, will be in the best interests of all. > >> the criteria the WG asked me to apply for new work or presentation slots are: >> - recent or recently updated draft >> - within charter >> - results in constructive discussion on the mailing list >> >> I need for you to provoke discussion on the list. You may respond to my opening email to do so if it's helpful. >> >> > I am trying to get people and companies to join the IETF email list and comment publicly. As I said, this is an uphill battle as many companies ask 'Why should I do this?' 'Who is the IETF anyway?' And, "Will we get sued for commenting?" (I kid you not. This is a serious concern for some end-user companies.) > > I hope that we can do some outreach together with the goal of getting more end-user companies involved in the IETF. As a first step, my company is happy to arrange webcasts where I can try to get many of the Fortune 1000. Many are already customers of our classes, products, or consulting. I can also try to get IBM to support. We will be at a trade show this coming week where there will be quite a few large companies as well as IBM. I hope to do some face-to-face arm-twisting. > From nalini.elkins@insidethestack.com Tue Feb 5 11:48: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 7402221F8569 for ; Tue, 5 Feb 2013 11:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YgO1hl76aaC for ; Tue, 5 Feb 2013 11:48:20 -0800 (PST) Received: from nm27-vm0.access.bullet.mail.mud.yahoo.com (nm27-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.227]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1521F8430 for ; Tue, 5 Feb 2013 11:48:19 -0800 (PST) Received: from [66.94.237.127] by nm27.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 19:48:19 -0000 Received: from [66.94.237.104] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 19:48:19 -0000 Received: from [127.0.0.1] by omp1009.access.mail.mud.yahoo.com with NNFMP; 05 Feb 2013 19:48:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 390090.59736.bm@omp1009.access.mail.mud.yahoo.com Received: (qmail 44294 invoked by uid 60001); 5 Feb 2013 19:48:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360093699; bh=TzkMZVoAtOtL6QCInBbEzTZGXeZAE2uby5EHj2oETfU=; 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=gs46j5giiNxjDouRtTSml7K/bdVcVSXBeXVrXrIDt3ANvtskK6dhQROMy2z5SgJi/c2b0LohyWVT3hfw5V8cmdcu4bwjqB3qTx5SCBNgQDK6ReEf8NskotYtvuT2JZln7u0nTpYaYIlnpG4gko+hcavrvfETkMMqEDz5WUB8sK8= X-YMail-OSG: 3uVN.f8VM1n_2uu84XMTjr5wBsT_DwO3r_Hcjyjc5iJoLri kKHJLHtNd3jo2y_B.Wv_FF8COlUA4EIwym6fYifH3A7MVnTN6K6xAifMHjcn 6W_dVculZsfRv1tZDzNiHaXIgxTJNW5KMT9T7CZtwts23qx0Vy4wp.Gf5obA 5_Gn_E_ORsg7OrVRDEPVkmfW4CKMh7W23FgNF3EIvoiw24GytxNG8U6F6yxs fE2SWVM3Ebp1hBdqJjl3RrStfDrxTk079V4l4CjxbP944ZUxQ7ZkpuMNu_Ng Uuchk.B9EvKNR6tj5SYyPhB_Yscy_ahuuDgtTbHn0PhG2zcBndtOVi8gLSKw Zkd9uRzMbqabRdiVlOovXw7uCAUKiBPxG48e_eWmcsFTW.4FfR7FEngUbD7C 7zK_4UhtfxKoVAcNmaXsec0zUlClRd1pMAs73npRv7zXQIlU21ASJ80NoG6Q v2lEuGrBmc01qp47xjx7lXKWYbCgD0aqoy7qKmDfWB4sugIYOgAGGIyXyMEj Doo2zuyBcLEqRsXPNa5kLroq3JRHq4HZt8T7nZAeGIM0MokvfHAHCBx6xGZp brhXaC.1s_3P1AJ7vLNMrnGdofV3jkXp9zZs9RyvXEBo- Received: from [12.249.100.42] by web2805.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 11:48:18 PST X-Rocket-MIMEInfo: 001.001, Cgo.PlRDUCBzaG91bGQgYmUgaXNzdWluZyB0aGUgcmV0cmFuc21pc3Npb25zLCBhdCB3aGljaCBwb2ludCBJUCBzaG91bGQgYmXCoGlzc3VpbmcgbmV3IElEcy4KCkVYQUNUTFkhIMKgIFdpdGhvdXQgYSBuZXcgSUQsIHdoZXJlIGFyZSB3ZT8KCgpUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51116029.1090102@isi.edu> Message-ID: <1360093698.37958.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 11:48:18 -0800 (PST) From: Nalini Elkins To: Joe Touch In-Reply-To: <51116029.1090102@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1338742330-1360093698=:37958" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:48:21 -0000 --1619178251-1338742330-1360093698=:37958 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A>>TCP should be issuing the retransmissions, at which point IP should= be=A0issuing new IDs.=0A=0AEXACTLY! =A0 Without a new ID, where are we?=0A= =0A=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-836= 0=0Awww.insidethestack.com=0A=0A=0A=0A________________________________=0A F= rom: Joe Touch =0ATo: Nalini Elkins =0ACc: Andrew Yourtchenko ; IETF v6ops list = =0ASent: Tuesday, February 5, 2013 11:40 AM=0ASubject: Re:= [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A =0A=0A=0AOn 2/5/= 2013 11:28 AM, Nalini Elkins wrote:=0A> Joe,=0A>=0A> Well, duplicate packet= s are often retransmissions.=0A=0ATCP should be issuing the retransmissions= , at which point IP should be =0Aissuing new IDs.=0A=0ARFC1122 recommends a= gainst TCP resending the same segment with the same =0AIP ID, and RFC 6484 = confirms this.=0A=0A> If you have=0A> retransmissions, then the other end (= or the network) is not absorbing=0A> the flow properly.=0A...=0A=0AIf you h= ave retransmissions, the network is losing segments. Loss can be =0Athe res= ult of a transmission error OR congestion. TCP reacts to those =0Alosses as= if they were congestion only because it is more conservative.=0A=0AI.e.:= =0A=A0=A0=A0 - if you see exact duplicates, it's because a device=0A=A0=A0= =A0 is duplicating packets=0A=A0=A0=A0 =A0=A0=A0 that device needs to be fi= xed, but that's=0A=A0=A0=A0 =A0=A0=A0 rare as has already been noted=0A=0A= =A0=A0=A0 - if you see segment retransmissions, you know there=0A=A0=A0=A0 = is loss, but you don't know why yet=0A=0AJoe=0A=0A> Thanks,=0A>=0A> Nalini = Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> www.insidethestack.= com=0A>=0A> ---------------------------------------------------------------= ---------=0A> *From:* Joe Touch =0A> *To:* Andrew Yourtchenk= o =0A> *Cc:* Nalini Elkins ; IETF v6ops list=0A> =0A> *Sent:* Tuesday, February = 5, 2013 10:25 AM=0A> *Subject:* Re: [v6ops] new draft: draft-elkins-v6ops-i= pv6-ipid-needed=0A>=0A> PS - I'm particularly interested in an explanation = of why duplicate=0A> packets would be an indication of congestion, FWIW.=0A= >=0A> Joe=0A>=0A> On 2/5/2013 10:20 AM, Joe Touch wrote:=0A>=A0 > Hi, Andre= w,=0A>=A0 >=0A>=A0 > I completely agree; I look forward to a description of= the problem.=0A>=A0 >=0A>=A0 > Joe=0A>=A0 >=0A>=A0 > On 2/5/2013 9:22 AM, = Andrew Yourtchenko wrote:=0A>=A0 >> Nalini, Joe,=0A>=A0 >>=0A>=A0 >> This t= wo-mail exchange vividly illustrates why it's beneficial to=0A>=A0 >> descr= ibe the problem better, and the properties of the ideal solution=0A>=A0 >> = (starting with that of IP ID, but not necessarily limited to it), but=0A>= =A0 >> not jump to solutions themselves straight away.=0A>=A0 >>=0A>=A0 >> = Otherwise it's too easy to get into a situation of a fish and a gull=0A>=A0= >> arguing about the sea water.=0A>=A0 >>=0A>=A0 >> --a=0A>=A0 >>=0A>=A0 >= >=0A>=A0 >> On Tue, 5 Feb 2013, Nalini Elkins wrote:=0A>=A0 >>=0A>=A0 >>> C= omparing hashes or packets is not really a workable solution because=0A>=A0= >>> there can be true duplicate packets.=A0 A hash will only show if=0A>= =A0 >>> the packets are the same.=A0 Unless I am missing something.=A0 Some= times=0A>=A0 >>> the problem we are trying to diagnose is how many duplicat= es=0A>=A0 >>> there are.=A0 This is an indication of congestion.=A0 Some de= vices create=0A>=A0 >>> 'false' duplicates.=A0 That is a packet trace taken= at that=0A>=A0 >>> point will show that the packet is the same but it is o= nly the device=0A>=A0 >>> or the trace mechanism tracing incorrectly.=A0 Be= lieve me, this=0A>=A0 >>> is not an infrequent problem.=0A>=A0 >>>=0A>=A0 >= >> Thanks,=0A>=A0 >>>=0A>=A0 >>> Nalini Elkins=0A>=A0 >>> Inside Products, = Inc.=0A>=A0 >>> (831) 659-8360=0A>=A0 >>> www.insidethestack.com =0A>=A0 >>>=0A>=A0 >>>=0A> __________________________= ___________________________________________________________________________= ______________________________________=0A>=A0 >>>=0A>=A0 >>>=0A>=A0 >>> Fro= m: Joe Touch >=0A>=A0 >>> To: Nalini E= lkins >=0A>=A0 >>> Cc: Andrew Yourtchenko >; IETF v6ops list=0A>=A0 >>> >=0A>=A0 >>> Sent: Tuesday, February 5, 2013 8:50 AM=0A>=A0= >>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A= >=A0 >>>=0A>=A0 >>> FWIW, there are two obvious solutions that work for bot= h IPv4 and IPv6:=0A>=A0 >>>=0A>=A0 >>> 1) send fragmented (or fragmentable)= packets=0A>=A0 >>>=A0 =A0 presuming you have control over a source=0A>=A0 = >>>=0A>=A0 >>> 2) compare either full packets or hashes of the full packets= =0A>=A0 >>>=0A>=A0 >>> "convenience" of an existing field that is not alway= s available isn't=0A>=A0 >>> a solution.=0A>=A0 >>>=0A>=A0 >>> Joe=0A>=A0 >= >>=0A>=A0 >>>=0A>=A0 >>>=0A>=A0 >>>=0A>=0A> --1619178251-1338742330-1360093698=:37958 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

>= ;>TCP should be issuing the retransmissi= ons, at which point IP should be&nbs= p;
issuing new IDs.
=
EXACT= LY!   Without a new ID, where are we?

Thanks,

Nalini Elk= ins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com
=
From: Joe = Touch <touch@isi.edu>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: Andrew Yourtchenko <ayour= tch@cisco.com>; IETF v6ops list <v6ops@ietf.org>
Sent: Tuesday, February 5, 2013 11:40 = AM
Subject: Re: [v6ops] new draft: dr= aft-elkins-v6ops-ipv6-ipid-needed

=0A

On 2/5/= 2013 11:28 AM, Nalini Elkins wrote:
> Joe,
>
> Well, dupl= icate packets are often retransmissions.

TCP should be issuing the r= etransmissions, at which point IP should be
issuing new IDs.

RFC= 1122 recommends against TCP resending the same segment with the same
IP= ID, and RFC 6484 confirms this.

> If you have
> retransmi= ssions, then the other end (or the network) is not absorbing
> the fl= ow properly.
...

If you have retransmissions, the network is losi= ng segments. Loss can be
the result of a transmission error OR congesti= on. TCP reacts to those
losses as if they were congestion only because = it is more conservative.

I.e.:
    - if you see ex= act duplicates, it's because a device
    is duplicating = packets
        that device needs to be fi= xed, but that's
        rare as has already been noted

   = ; - if you see segment retransmissions, you know there
   = ; is loss, but you don't know why yet

Joe

> Thanks,
>= ;
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-836= 0
> www.= insidethestack.com
>
> ------------------------------------= ------------------------------------
> *From:* Joe Touch <touch@isi.edu= >
> *To:* Andrew Yourtchenko <ayourtch@cisco.com>
&g= t; *Cc:* Nalini Elkins <nalini.elkins@insid= ethestack.com>; IETF v6ops list
> <v6ops@iet= f.org>
> *Sent:* Tuesday, February 5, 2013 10:25 AM
> *S= ubject:* Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
>=
> PS - I'm particularly interested in an explanation of why duplicat= e
> packets would be an indication of congestion, FWIW.
>
&g= t; Joe
>
> On 2/5/2013 10:20 AM, Joe Touch wrote:
> = > Hi, Andrew,
>  >
>  > I completely agree;= I look forward to a description of the problem.
>  >
>=   > Joe
>  >
>  > On 2/5/2013 9:22 AM, = Andrew Yourtchenko wrote:
>  >> Nalini, Joe,
> = >>
>  >> This two-mail exchange vividly illustrates= why it's beneficial to
>  >> describe the problem better,= and the properties of the ideal solution
>  >> (starting with that of IP ID, but not necessarily limited to it), but
&= gt;  >> not jump to solutions themselves straight away.
>&= nbsp; >>
>  >> Otherwise it's too easy to get into a= situation of a fish and a gull
>  >> arguing about the se= a water.
>  >>
>  >> --a
>  &g= t;>
>  >>
>  >> On Tue, 5 Feb 2013, Na= lini Elkins wrote:
>  >>
>  >>> Compar= ing hashes or packets is not really a workable solution because
>&nbs= p; >>> there can be true duplicate packets.  A hash will only= show if
>  >>> the packets are the same.  Unless = I am missing something.  Sometimes
>  >>> the prob= lem we are trying to diagnose is how many duplicates
>  >>= > there are.  This is an indication of congestion.  Some devices create
>  >>> 'false' duplicates.  T= hat is a packet trace taken at that
>  >>> point will s= how that the packet is the same but it is only the device
>  >= ;>> or the trace mechanism tracing incorrectly.  Believe me, thi= s
>  >>> is not an infrequent problem.
>  &g= t;>>
>  >>> Thanks,
>  >>>>  >>> Nalini Elkins
>  >>> Inside Pr= oducts, Inc.
>  >>> (831) 659-8360
>  >&g= t;> www.insidethestack.com <http://www.insidethestack.com/>
>= ;  >>>
>  >>>
> ___________________= ___________________________________________________________________________= _____________________________________________
>  >>>>  >>>
>  >>> From: Joe Touch <touc= h@isi.edu <mailto:touch@isi.edu>>
>  >>> To: Na= lini Elkins <nalini.elkins@insidethestack.c= om
> <mailto:nalini.elkins@inside= thestack.com>>
>  >>> Cc: Andrew Yourtchenko = <ayourtch@cisco.com
> <mailto:ayourtch@cisco.com>&= gt;; IETF v6ops list
>  >>> <v6ops@ietf.org <mailto:= v6ops@iet= f.org>>
>  >>> Sent: Tuesday, February 5, 201= 3 8:50 AM
>  >>> Subject: Re: [v6ops] new draft: draft-= elkins-v6ops-ipv6-ipid-needed
>  >>>
>  >= >> FWIW, there are two obvious solutions that work for both IPv4 and = IPv6:
>  >>>
>  >>> 1) send fragmen= ted (or fragmentable) packets
>  >>>    presu= ming you have control over a source
>  >>>
> = ; >>> 2) compare either full packets or hashes of the full packets=
>  >>>
>  >>> "convenience" of an = existing field that is not always available isn't
>  >>>= ; a solution.
>  >>>
>  >>> Joe
= >  >>>
>  >>>
>  >>>
>  >>>
>
>


=
--1619178251-1338742330-1360093698=:37958-- From nalini.elkins@insidethestack.com Tue Feb 5 11:53:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F3921F8635 for ; Tue, 5 Feb 2013 11:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkAB0PCWw8Lz for ; Tue, 5 Feb 2013 11:53:30 -0800 (PST) Received: from nm28-vm0.access.bullet.mail.sp2.yahoo.com (nm28-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.190]) by ietfa.amsl.com (Postfix) with ESMTP id C334821F8648 for ; Tue, 5 Feb 2013 11:53:29 -0800 (PST) Received: from [98.139.44.102] by nm28.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:53:24 -0000 Received: from [98.139.44.93] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:53:24 -0000 Received: from [127.0.0.1] by omp1030.access.mail.sp2.yahoo.com with NNFMP; 05 Feb 2013 19:53:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 59266.93004.bm@omp1030.access.mail.sp2.yahoo.com Received: (qmail 7421 invoked by uid 60001); 5 Feb 2013 19:53:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360094003; bh=WyTLtLSTUIIbgy2gqURC3NutTzRpqckPBqIuN28rDvg=; 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=ekuQFMokzrKaVJgya9K3ksXyznEKWOQAcVqsXP9Crs3z2mad645Hn6Mwv+JPiPsbxOCUKELDsUCUCP6EX3gFUHg9UY+ovj1MmJZA+AZdH571FvlA3PlA/M6U8SMW3qsk8kj50nwpHuDmDAbK+GjXIfHXqGu9JalfmWJuTw6sygM= X-YMail-OSG: 3.Wlos4VM1nmTqibgoCbaB5p_4tod0Lm6M0QhUOxq3apmQY UxdYJyTqRDv9Nu3l75DFMK1jhbsMfvVWCkSBQ2FMZDl.fyR3A7dzO1oJMtdr hU1s23rR9QgeVejXrMw3hwAA6j_Qw9_x1K6NceX4Y.hrscQF9olqrndT3457 ZqyrtV3lzfxdxT92emdRNlwitYPgSAJJsXhs70u.DU.RGlSlNdyyQ8HVB3NP .Hm_6aXcfahDVgQcYbPV4d8LntcQm_5naETDXQwo20v5RS4tQSlvL.WPAXZE FCgyZCG_O6A2ykrcGoMo9DsTsMumbB6CQz2UH22_3PZ2183DDdXJAQF0UJcg cnz85k2csX.5HIFIgRxu_hhHDizA.6u0WfsahzMu_TkW_XDJxFLKsS73I.LK f3vaVcSscFtZusb2gZcP1tTFWWsm7daov2BsvSd.J0r2m2z1B5lEdAC6jQZ5 GMCj_Gh9RI7ejgnTHHVuULbz8AG95GMHmPNk0SP4N26.Kx8i0QgWDrHE.y7r 0uxi32E3DkIQWO1Jn2lvK5iJzoahecxAEZ8WPWOFOpTPN_CD.Zd0OS_qhJyF F2mva424Tp31IWqSDUditeI61jV34haEW5R.0gxUs2IE- Received: from [12.249.100.42] by web2811.biz.mail.ne1.yahoo.com via HTTP; Tue, 05 Feb 2013 11:53:23 PST X-Rocket-MIMEInfo: 001.001, TWFyaywKClRvb2xzIGFyZSBhIGRpZmZlcmVudCB0b3BpYy4gwqAgQSBudW1iZXIgb2YgY29tcGFuaWVzLCBpbmNsdWRpbmcgbWluZSwgaGF2ZSBpbnRlbGxpZ2VudCBwYWNrZXQgYW5hbHl6ZXJzLiDCoCBGb3IgdXMsIHRoZXJlIGlzIG5vdGhpbmcgb3VyIHByb2R1Y3RzIGxpa2UgYmV0dGVyIHRoYW4gdGhvdXNhbmRzIG9mIHBhY2tldHMgdGhhdCB3ZSBjYW4gcmVhZCBpbiBhbmQgdGhlbiBoZWxwIHRoZSBjdXN0b21lciB0byBwaW5wb2ludCBwcm9ibGVtcyB0byB0aGUgZXhhY3QgcGFja2V0LiDCoFRoaXMgaXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1360094003.76755.YahooMailNeo@web2811.biz.mail.ne1.yahoo.com> Date: Tue, 5 Feb 2013 11:53:23 -0800 (PST) From: Nalini Elkins To: Mark Smith , Joe Touch , Andrew Yourtchenko In-Reply-To: <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-759923333-1482721350-1360094003=:76755" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:53:32 -0000 ---759923333-1482721350-1360094003=:76755 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mark,=0A=0ATools are a different topic. =A0 A number of companies, includin= g mine, have intelligent packet analyzers. =A0 For us, there is nothing our= products like better than thousands of packets that we can read in and the= n help the customer to pinpoint problems to the exact packet. =A0This is th= e trend of the future. =A0The volume of data and packets soon outpaces what= we mere humans can do. =A0We need a partnership between intelligent tools = and intelligent humans.=0A=0AI would actually love to have a discussion at = some point on best practices in troubleshooting. =A0 Our ultimate goal is t= o have the right performance and troubleshooting metrix built right into th= e protocols from the get-go!=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside= Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______= __________________________=0A From: Mark Smith = =0ATo: Nalini Elkins ; Joe Touch ; Andrew Yourtchenko =0ACc: IETF v6ops list =0ASent: Tuesday, February 5, 2013 11:42 AM=0ASubject: Re: [v= 6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A =0A=0A=0A=0A=0A=0A>= ________________________________=0A> From: Nalini Elkins =0A>To: Joe Touch ; Andrew Yourtchenko =0A>Cc: IETF v6ops list =0A>Sent: Wednesda= y, 6 February 2013 6:28 AM=0A>Subject: Re: [v6ops] new draft: draft-elkins-= v6ops-ipv6-ipid-needed=0A> =0A>=0A>Joe,=0A>=0A>=0A>Well, duplicate packets = are often retransmissions.=A0=0A>=0A>=0A=0AThis can be quite easily determi= ned by comparing sent packet counts at one end with received packet counts = at the other. I'd consider doing that to be much easier than capturing 1000= s of packets and then looking through them with an analyser to try to spot = duplicate packets. I consider using a packet analyser to be a last resort w= hen troubleshooting because you're usually dealing with 1000s, 10 000s or 1= 00 000s of packets, and trying to spot a trend or pick the bad individual p= acket. It can also be quite onerous to setup the packet capture and the vol= ume of data can huge.=0A=0ASome of these examples are starting sound like y= ou've been taking the approach of "how can we use IPID to troubleshoot this= " rather than "what is the most effective tool to troubleshoot this", of wh= ich IPID might be one for a particular situation.=A0=0A=0A>=0A>=0A>=A0 If y= ou have retransmissions, then the other end (or the network) is not absorbi= ng the flow properly. =A0Then, on our end, we need to see if we have alloca= ted enough bandwidth, it is going over a sub-optimal route, etc.=0A>=A0=0A>= Thanks,=0A>=0A>=0A>Nalini Elkins=0A>Inside Products, Inc.=0A>(831) 659-8360= =0A>www.insidethestack.com=0A>=0A>=0A>=0A>________________________________= =0A> From: Joe Touch =0A>To: Andrew Yourtchenko =0A>Cc: Nalini Elkins ; IETF v6o= ps list =0A>Sent: Tuesday, February 5, 2013 10:25 AM=0A>Su= bject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A>P= S - I'm particularly interested in an explanation of why duplicate =0A>pack= ets would be an indication of congestion, FWIW.=0A>=0A>Joe=0A>=0A>On 2/5/20= 13 10:20 AM, Joe Touch wrote:=0A>> Hi, Andrew,=0A>>=0A>> I completely agree= ; I look forward to a description of the problem.=0A>>=0A>> Joe=0A>>=0A>> O= n 2/5/2013 9:22 AM, Andrew Yourtchenko wrote:=0A>>> Nalini, Joe,=0A>>>=0A>>= > This two-mail exchange vividly illustrates why it's beneficial to=0A>>> d= escribe the problem better, and the properties of the ideal solution=0A>>> = (starting with that of IP ID, but not necessarily limited to it), but=0A>>>= not jump to solutions themselves straight away.=0A>>>=0A>>> Otherwise it's= too easy to get into a situation of a fish and a gull=0A>>> arguing about = the sea water.=0A>>>=0A>>> --a=0A>>>=0A>>>=0A>>> On Tue, 5 Feb 2013, Nalini= Elkins=0Awrote:=0A>>>=0A>>>> Comparing hashes or packets is not really a w= orkable solution because=0A>>>> there can be true duplicate packets.=A0 A h= ash will only show if=0A>>>> the packets are the same.=A0=A0=A0Unless I am = missing something.=A0=A0=A0Sometimes=0A>>>> the problem we are trying to di= agnose is how many duplicates=0A>>>> there are.=A0 This is an indication of= congestion.=A0=A0=A0Some devices create=0A>>>> 'false' duplicates.=A0 That= is a packet trace taken at that=0A>>>> point will show that the packet is = the same but it is only the device=0A>>>> or the trace mechanism tracing in= correctly.=A0 Believe me, this=0A>>>> is not an infrequent problem.=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: Joe Touch =0A>>>> To: Nalini Elkins =0A>>>> Cc: Andrew Yourtchenko ; IETF v= 6ops list=0A>>>> =0A>>>> Sent: Tuesday, February 5, 2013 8:= 50 AM=0A>>>> Subject: Re: [v6ops] new draft:=0Adraft-elkins-v6ops-ipv6-ipid= -needed=0A>>>>=0A>>>> FWIW, there are two obvious solutions that work for b= oth IPv4 and IPv6:=0A>>>>=0A>>>> 1) send fragmented (or fragmentable) packe= ts=0A>>>>=A0 =A0=A0=A0presuming you have control over a source=0A>>>>=0A>>>= > 2) compare either full packets or hashes of the full packets=0A>>>>=0A>>>= > "convenience" of an existing field that is not always available isn't=0A>= >>> a solution.=0A>>>>=0A>>>> Joe=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>= =0A> ---759923333-1482721350-1360094003=:76755 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Mark,

Tools are a different topic. =   A number of companies, including mine, have intelligent packet analy= zers.   For us, there is nothing our products like better than thousan= ds of packets that we can read in and then help the customer to pinpoint pr= oblems to the exact packet.  This is the trend of the future.  Th= e volume of data and packets soon outpaces what we mere humans can do. &nbs= p;We need a partnership between intelligent tools and intelligent humans.

I would actually love to = have a discussion at some point on best practices in troubleshooting.  = ; Our ultimate goal is to have the right performance and troubleshooting me= trix built right into the protocols from the get-go!
&= nbsp;
Thanks,

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

=
From: Mark Smith <markzzzsmith@y= ahoo.com.au>
To: Na= lini Elkins <nalini.elkins@insidethestack.com>; Joe Touch <touch@i= si.edu>; Andrew Yourtchenko <ayourtch@cisco.com>
Cc: IETF v6ops list <v6ops@ietf.org&= gt;
Sent: Tuesday, Fe= bruary 5, 2013 11:42 AM
Subject:<= /span> Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
<= /font>

=0A




>______________________________= __
> From: Nalini Elkins <nalini.elki= ns@insidethestack.com>
>To: Joe Touch <touch@isi.edu>; Andrew= Yourtchenko <ayourtch@cisco.com>
>Cc: IETF v6ops list &l= t;v6ops= @ietf.org>
>Sent: Wednesday, 6 February 2013 6:28 AM
>S= ubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> =
>
>Joe,
>
>
>Well, duplicate packets are oft= en retransmissions. 
>
>

This can be quite easily d= etermined by comparing sent packet counts at one end with received packet c= ounts at the other. I'd consider doing that to be much easier than capturing 1000s of packets and = then looking through them with an analyser to try to spot duplicate packets= . I consider using a packet analyser to be a last resort when troubleshooti= ng because you're usually dealing with 1000s, 10 000s or 100 000s of packet= s, and trying to spot a trend or pick the bad individual packet. It can als= o be quite onerous to setup the packet capture and the volume of data can h= uge.

Some of these examples are starting sound like you've been taki= ng the approach of "how can we use IPID to troubleshoot this" rather than "= what is the most effective tool to troubleshoot this", of which IPID might = be one for a particular situation. 

>
>
>  = If you have retransmissions, then the other end (or the network) is not abs= orbing the flow properly.  Then, on our end, we need to see if we have= allocated enough bandwidth, it is going over a sub-optimal route, etc.
> 
>Thanks,
>
>
>Nalini Elkins
= >Inside Products, Inc.
>(831) 659-8360
>www.insidethestack.com
>=
>
>
>________________________________
> From: Joe = Touch <touch@isi.edu>
>To: Andrew Yourtchenko <ayourtch@cisco.co= m>
>Cc: Nalini Elkins <nalini= .elkins@insidethestack.com>; IETF v6ops list <v6ops@ietf.org> >Sent: Tuesday, February 5, 2013 10:25 AM
>Subject: Re: [v6ops] n= ew draft: draft-elkins-v6ops-ipv6-ipid-needed
>
>PS - I'm part= icularly interested in an explanation of why duplicate
>packets would be an = indication of congestion, FWIW.
>
>Joe
>
>On 2/5/20= 13 10:20 AM, Joe Touch wrote:
>> Hi, Andrew,
>>
>&g= t; I completely agree; I look forward to a description of the problem.
&= gt;>
>> Joe
>>
>> On 2/5/2013 9:22 AM, Andrew= Yourtchenko wrote:
>>> Nalini, Joe,
>>>
>>= ;> This two-mail exchange vividly illustrates why it's beneficial to
= >>> describe the problem better, and the properties of the ideal s= olution
>>> (starting with that of IP ID, but not necessarily l= imited to it), but
>>> not jump to solutions themselves straigh= t away.
>>>
>>> Otherwise it's too easy to get into= a situation of a fish and a gull
>>> arguing about the sea wat= er.
>>>
>>> --a
>>>
>>>
>>> On Tue, 5 Feb 2013, Na= lini Elkins
wrote:
>>>
>>>> Comparing hashes = or packets is not really a workable solution because
>>>> th= ere can be true duplicate packets.  A hash will only show if
>&g= t;>> the packets are the same.   Unless I am missing s= omething.   Sometimes
>>>> the problem we are= trying to diagnose is how many duplicates
>>>> there are.&n= bsp; This is an indication of congestion.   Some devices cre= ate
>>>> 'false' duplicates.  That is a packet trace ta= ken at that
>>>> point will show that the packet is the same= but it is only the device
>>>> or the trace mechanism traci= ng incorrectly.  Believe me, this
>>>> is not an infreq= uent problem.
>>>>
>>>> Thanks,
>>>>
>>>> Nalini Elkins
>>&= gt;> Inside Products, Inc.
>>>> (831) 659-8360
>>= ;>> www.insidethestack.com
>>>>
>>>> __= ___________________________________________________________________________= ______________________________________________________________
>>&= gt;>
>>>>
>>>> From: Joe Touch <touch@isi.edu>
>>>> To: Nalini Elkins <nalini.elkins@insidethestack.com>
>>>> Cc: Andrew Y= ourtchenko <ayourtch@cisco.com>; IETF v6ops list
>>>= > <v6ops@ietf.org>
>>>> = Sent: Tuesday, February 5, 2013 8:50 AM
>>>> Subject: Re: [v= 6ops] new draft:
draft-elkins-v6ops-ipv6-ipid-needed
>>>>=
>>>> FWIW, there are two obvious solutions that work for bo= th IPv4 and IPv6:
>>>>
>>>> 1) send fragmente= d (or fragmentable) packets
>>>>     pre= suming you have control over a source
>>>>
>>>&g= t; 2) compare either full packets or hashes of the full packets
>>= >>
>>>> "convenience" of an existing field that is not= always available isn't
>>>> a solution.
>>>>=
>>>> Joe
>>>>
>>>>
>>= ;>>
>>>>
>
>
>
>______________= _________________________________
>v6ops mailing list
>v6ops@iet= f.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
= >
>


---759923333-1482721350-1360094003=:76755-- From mackermann@bcbsm.com Tue Feb 5 12:26: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 3576721F8648 for ; Tue, 5 Feb 2013 12:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.981 X-Spam-Level: X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 729oc4cJTU36 for ; Tue, 5 Feb 2013 12:26:00 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 1218B21F85B2 for ; Tue, 5 Feb 2013 12:25:59 -0800 (PST) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 8E20A17E371 for ; Tue, 5 Feb 2013 14:25:58 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 2CBCD17E305; Tue, 5 Feb 2013 14:25:57 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id A24832F0070; Tue, 5 Feb 2013 15:24:26 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id 944992F006E; Tue, 5 Feb 2013 15:24:26 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Tue, 5 Feb 2013 15:25:56 -0500 From: "Ackermann, Michael" To: Mark Smith , joel jaeggli , "Templin, Fred L" , IETF v6ops list Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8CAATMIAIAAQkCggACO3wD//7KSQA== Date: Tue, 5 Feb 2013 20:25:55 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DF2F1@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 20:26:01 -0000 Great questions=21 =20 Here are some less than great answers: :) In many of the situations highlighted here, in particular some of the use = case examples, IPID was instrumental in determining where a problem = existed and sometimes even IF one existed. The user may claim = unacceptable performance but sometimes the monitors and reports do not = indicate a problem. =20 IPID has many times allowed us, at the endpoints, show that a problem was = occurring somewhere in the middle boxes. Often these middle boxes are run = by other organizations, which may be reluctant to consider they may be = responsible for any issues or degradation. Thus, any facility, such as = IPID, that can more clearly illustrate the case, can not only save time = but even bring those to the table who may not want to be. =20 Thus, from my perspective, IPID may be more important to end users (such = as me), than to ISP's and vendors.=20 I will see if more detail on the devices in cases 2 and 3 can be provided. =20 The time estimates are tricky and difficult to establish in many cases. = In almost every case, all of us contributing felt we estimated low to = avoid any reduction in believability. But when you add up the time to = establish that there is a problem, then add the time to find where you = think it might be (especially given that you don't own/control the entire = network path), and then add the biggest chunk of time, which is getting = the responsible party(s) fully engaged, you begin to see where ANY = information/facility/view that can help, can easily save you multiple = hours. These multiple hours cost large enterprises lots of =24=24=24=24. = =20 Most of these hours occur when a middle box responsible party checks their = management system and reports =22NO PROBLEM=22. It is the problems that = do not appear highly visible to management systems, or are logical (vs. = physical) in nature, that accrue time in these situations, while those = responsible are =22Convinced=22 to look deeper or consider things outside = their normal paradigm.=20 I know every situation is unique but IPID has definitely helped us and = others in select situations, which is why we would hate to see it = eliminated. =20 -----Original Message----- From: Mark Smith =5Bmailto:markzzzsmith=40yahoo.com.au=5D=20 Sent: Tuesday, February 05, 2013 2:30 PM To: Ackermann, Michael; joel jaeggli; Templin, Fred L; IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed ----- Original Message ----- > From: =22Ackermann, Michael=22 > To: joel jaeggli ; =22Templin, Fred L=22=20 > ; IETF v6ops list > Cc:=20 > Sent: Wednesday, 6 February 2013 3:19 AM > Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 >T hanks Joel. >=20 > Your comment highlights our more general issue, which is that large=20 > enterprises are not very active at IETF, so would not see issues such=20 > as this until they deploy IPV6 in production and have a problem where=20 > facilities could be shown to be missing or inadequate.=A0 And yes,=20 > ideally speaking, that is way to late in the process. >=A0 In the distant past I've worked in enterprise, and then more recently at = ISPs. Enterprise networks used to be far more controlled than ISPs' = networks, because in ISP networks customers bring along their own = equipment and run applications of their own choosing. Troubleshooting = should be harder in ISP networks because of this variety, yet reading = through your use cases, it seems not to be any more. Reading though your use cases, it seems like quite a number of them are = related to faulty middle boxes, which have probably arisen in Enterprise = networks since I've worked on them. The IETF advises against middle boxes = because of these sorts of issues (see RFC4924).=A0It'd be good to get more = exact details of the devices that caused the issues, in particular, the = devices in use cases 2 and 3. I'm also curious how you came up with your estimates of the time saved by = using IPID. For example, I'd have used standard ping with a few different = packet sizes to troubleshoot the VPN packet loss issue in use case 4. For = a typical packet loss issue, I'm confident I'd have identified a packet = loss issue within 15 to 30 minutes (more likely 5 to 10), and identified = where it was occurring along the VPN traffic path within an hour or two. = So a saving of 9 hours by using IPID verses ping wouldn't be possible. Regards, Mark. > This issue is somewhat separate from our RFC, but is a situation we=20 > seek to address by getting more large organizations involved in IETF.=A0 = =20 > We believe that would be a win/win situation, benefiting not only the=20 > large organizations themselves, but IETF and networking in general as = well=21 >=20 > I hope you agree? >=20 > Thanks again=21 >=20 > Mike >=20 >=20 >=20 > -----Original Message----- > From: joel jaeggli =5Bmailto:joelja=40bogus.com=5D > Sent: Tuesday, February 05, 2013 2:01 AM > To: Ackermann, Michael; Templin, Fred L; IETF v6ops list > Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > On 2/4/13 9:53 AM, Ackermann, Michael wrote: >> Thanks for your comments Fred=21 >>=20 >> The first draft you reference seems to highlight the need for an=20 >> IPID field > larger than 16 bits (v4) or 32 bits (v6), due to the much faster=20 > networks we have today.=A0 We agree and that is very lightly = referenced=20 > in our RFC.=A0 The reason for only lightly, is that we chose to focus=20 > on the need for IPID at all, since many at the IETF did not agree this=20 > was an issue when we first introduced it.=A0 Our original proposal=20 > suggested going to 64 bits as part of the solution, but for now we=20 > have backed off on solutions and are focused on convincing the IETF=20 > that the elimination of IPID as a diagnostic facility, would be bad for = end user organizations. > To be clear IPv6 never=A0 had an analogous facility except in the=20 > fragmentation header, so that state of affairs has been on the books for = about 18 years. >>=20 >> The second draft you referenced is one I was not aware of but is=20 >> very > impressive and well written=21=A0 I know it was focused on tunnels and=20 > encapsulation, but among many other things it seems to promote the=20 > value of uniquely identifying packets, in particular ones that could=20 > be duplicate, improper or even malicious.=A0 =A0 If I am interpreting=20 > properly, then we are in full agreement. >>=20 >> Our main issue is that information such as provided by IPID can be=20 >> critical > to reliably running sophisticated networks today. >>=20 >> Thanks again=21 >>=20 >> Mike >>=20 >>=20 >>=20 >> -----Original Message----- >> From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D = On=20 >> Behalf Of Templin, Fred L >> Sent: Monday, February 04, 2013 11:51 AM >> To: IETF v6ops list >> Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >>=20 >> Hi, >>=20 >> Two drafts the authors should be aware of are =22Updated Specification > of the IPv4 ID Field=22: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ >>=20 >> and =22The Subnetwork Encapsulation and Adapation Layer (SEAL)=22: >>=20 >> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ >>=20 >> The former is a revised specification of the use of the IPv4 ID=20 >> field and > defines the cases in which the ID field does and does not contain=20 > useful information. The latter is a means for adding a 32-bit ID field=20 > during encapsulation, where the ID appears in an extension header=20 > similar to the way the IPv6 fragment header currently appears. >>=20 >> Point being that the IPv4 ID was never intended for purposes such as > ensuring uniqueness other than for the fragmentation and reassembly = process.=20 > And, for IPv6, there are already ways to add an ID to a packet if one is = needed. >>=20 >> Thanks - Fred >> fred.l.templin=40boeing.com >> _______________________________________________ >> v6ops mailing list >> v6ops=40ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >> The information contained in this communication is highly=20 >> confidential and > is intended solely for the use of the individual(s) to whom this=20 > communication is directed. If you are not the intended recipient, you=20 > are hereby notified that any viewing, copying, disclosure or=20 > distribution of this information is prohibited. Please notify the=20 > sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >> =A0=20 >> =A0 Blue Cross Blue Shield of Michigan and Blue Care Network of=20 >> Michigan are > nonprofit corporations and independent licensees of the Blue Cross and=20 > Blue Shield Association. >> _______________________________________________ >> v6ops mailing list >> v6ops=40ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 >=20 > The information contained in this communication is highly confidential=20 > and is intended solely for the use of the individual(s) to whom this=20 > communication is directed. If you are not the intended recipient, you=20 > are hereby notified that any viewing, copying, disclosure or=20 > distribution of this information is prohibited. Please notify the=20 > 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=20 > are nonprofit corporations and independent licensees of the Blue Cross=20 > and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From mackermann@bcbsm.com Tue Feb 5 12:36: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 7D01D21F8534 for ; Tue, 5 Feb 2013 12:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPosj0HLDo6r for ; Tue, 5 Feb 2013 12:35:59 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2D21F846C for ; Tue, 5 Feb 2013 12:35:58 -0800 (PST) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 7095417E35F for ; Tue, 5 Feb 2013 14:35:53 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id A1DCC17E2FD; Tue, 5 Feb 2013 14:35:51 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 120EA2F0045; Tue, 5 Feb 2013 15:34:21 -0500 (EST) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 00E2B2F0040; Tue, 5 Feb 2013 15:34:21 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Tue, 5 Feb 2013 15:35:49 -0500 From: "Ackermann, Michael" To: Mark Smith , Nalini Elkins , Joe Touch , Andrew Yourtchenko Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8CAATMIAIAABu4AgAA61oCAAFrmgIAACBsAgAABfgCAAAdIAIAAEGAAgAABJQCAABHcgIAAA8CA//+5bBA= Date: Tue, 5 Feb 2013 20:35:49 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DF31D@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 20:36:01 -0000 Regards to trying to use IPID to solve problems. =20 I feel kind of the opposite. I would really prefer NOT to use it. =20 It is only a select, rare breed of problems, where we would need to = utilize IPID at all. =20 Unfortunately, these rare problems are the tough ones, the important ones = and the ones where you need anything you can get to resolve them.=20 =20 So I view these situations, and the use of IPID, as a last and sometimes = desperate attempt to get something fixed or as stated earlier to convince = someone else to get engaged.=20 So, I think you are RIGHT ON, in that we should always employ the tool or = technique, which can address the issue at hand as quickly and effectively = as possible. In some cases this has been IPID, which is why we do not = want it taken away in IPV6. =20 =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Mark Smith Sent: Tuesday, February 05, 2013 2:42 PM To: Nalini Elkins; Joe Touch; Andrew Yourtchenko Cc: IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >________________________________ > From: Nalini Elkins >To: Joe Touch ; Andrew Yourtchenko = =20 >Cc: IETF v6ops list =20 >Sent: Wednesday, 6 February 2013 6:28 AM >Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > >Joe, > > >Well, duplicate packets are often retransmissions.=A0 > > This can be quite easily determined by comparing sent packet counts at one = end with received packet counts at the other. I'd consider doing that to = be much easier than capturing 1000s of packets and then looking through = them with an analyser to try to spot duplicate packets. I consider using a = packet analyser to be a last resort when troubleshooting because you're = usually dealing with 1000s, 10 000s or 100 000s of packets, and trying to = spot a trend or pick the bad individual packet. It can also be quite = onerous to setup the packet capture and the volume of data can huge. Some of these examples are starting sound like you've been taking the = approach of =22how can we use IPID to troubleshoot this=22 rather than = =22what is the most effective tool to troubleshoot this=22, of which IPID = might be one for a particular situation.=A0 > > >=A0 If you have retransmissions, then the other end (or the network) is = not absorbing the flow properly. =A0Then, on our end, we need to see if we = have allocated enough bandwidth, it is going over a sub-optimal route, etc. >=A0 >Thanks, > > >Nalini Elkins >Inside Products, Inc. >(831) 659-8360 >www.insidethestack.com > > > >________________________________ > From: Joe Touch >To: Andrew Yourtchenko =20 >Cc: Nalini Elkins ; IETF v6ops list = =20 >Sent: Tuesday, February 5, 2013 10:25 AM >Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 >PS - I'm particularly interested in an explanation of why duplicate=20 >packets would be an indication of congestion, FWIW. > >Joe > >On 2/5/2013 10:20 AM, Joe Touch wrote: >> Hi, Andrew, >> >> I completely agree; I look forward to a description of the problem. >> >> Joe >> >> On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote: >>> Nalini, Joe, >>> >>> This two-mail exchange vividly illustrates why it's beneficial to >>> describe the problem better, and the properties of the ideal solution >>> (starting with that of IP ID, but not necessarily limited to it), but >>> not jump to solutions themselves straight away. >>> >>> Otherwise it's too easy to get into a situation of a fish and a gull >>> arguing about the sea water. >>> >>> --a >>> >>> >>> On Tue, 5 Feb 2013, Nalini Elkins wrote: >>> >>>> Comparing hashes or packets is not really a workable solution because >>>> there can be true duplicate packets.=A0 A hash will only show if >>>> the packets are the same.=A0=A0=A0Unless I am missing = something.=A0=A0=A0Sometimes >>>> the problem we are trying to diagnose is how many duplicates >>>> there are.=A0 This is an indication of congestion.=A0=A0=A0Some = devices create >>>> 'false' duplicates.=A0 That is a packet trace taken at that >>>> point will show that the packet is the same but it is only the device >>>> or the trace mechanism tracing incorrectly.=A0 Believe me, this >>>> is not an infrequent problem. >>>> >>>> Thanks, >>>> >>>> Nalini Elkins >>>> Inside Products, Inc. >>>> (831) 659-8360 >>>> www.insidethestack.com >>>> >>>> = ___________________________________________________________________________= ________________________________________________________________ >>>> >>>> >>>> From: Joe Touch >>>> To: Nalini Elkins >>>> Cc: Andrew Yourtchenko ; IETF v6ops list >>>> >>>> Sent: Tuesday, February 5, 2013 8:50 AM >>>> Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed >>>> >>>> FWIW, there are two obvious solutions that work for both IPv4 and IPv6: >>>> >>>> 1) send fragmented (or fragmentable) packets >>>>=A0 =A0=A0=A0presuming you have control over a source >>>> >>>> 2) compare either full packets or hashes of the full packets >>>> >>>> =22convenience=22 of an existing field that is not always available = isn't >>>> a solution. >>>> >>>> Joe >>>> >>>> >>>> >>>> > > > >_______________________________________________ >v6ops mailing list >v6ops=40ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From touch@isi.edu Tue Feb 5 12:45: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 1221A21F85D2 for ; Tue, 5 Feb 2013 12:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.991 X-Spam-Level: X-Spam-Status: No, score=-102.991 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5le4lfJP8oZj for ; Tue, 5 Feb 2013 12:45:16 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61521F85BC for ; Tue, 5 Feb 2013 12:45:16 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15KiFnh025327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 12:44:15 -0800 (PST) Message-ID: <51116F1C.5090507@isi.edu> Date: Tue, 05 Feb 2013 12:44:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nalini Elkins References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51116029.1090102@isi.edu> <1360093698.37958.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1360093698.37958.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 20:45:17 -0000 On 2/5/2013 11:48 AM, Nalini Elkins wrote: > > >>TCP should be issuing the retransmissions, at which point IP should be > issuing new IDs. > > EXACTLY! Without a new ID, where are we? Well, to be more precise: - a TCP segment retransmission should not result in the reuse of an ID However, that's not true for IPv6 if the packet isn't already fragmented. Nor has it been true for a long time for packets from some cellphones, which reuse 0 as the ID. Nor has it been true for a long time for sources that are fairly modest (>7 Mbps for 1500-byte MTUs). Nor is not now true as allowed by RFC 6864 (which should be coming out of the pub queue shortly). It's only true when a packet is fragmented (IPv4 or IPv6), or can be (IPv4, or IPv6 in a 6-to-4 scenario). So assuming this is true is a bad idea. Again, the question is "what problem are you trying to solve". Joe From touch@isi.edu Tue Feb 5 12:52: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 EB4C421F85D2 for ; Tue, 5 Feb 2013 12:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih5g0ATHMlVZ for ; Tue, 5 Feb 2013 12:52:02 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0434421F85BC for ; Tue, 5 Feb 2013 12:51:58 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15KpIhA027625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 12:51:18 -0800 (PST) Message-ID: <511170C3.5060706@isi.edu> Date: Tue, 05 Feb 2013 12:51:15 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Ackermann, Michael" References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A0DF2F1@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DF2F1@PWN401EA160.ent.corp.bcbsm.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: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 20:52:09 -0000 On 2/5/2013 12:25 PM, Ackermann, Michael wrote: ... > I know every situation is unique but IPID has definitely helped us and others in select situations, which is why we would hate to see it eliminated. As has already been pointed out, it's already gone - both in IPv6 and in IPv4. If such a tool is instrumental in analyzing network anomalies, it would be useful to propose an alternative. However, it's trivial to have a controlled source send packets with traceable contents, and I doubt we need to have the entire Internet send information needed to trace problems such as this. Keep in mind that in IP, packet duplication is *allowed*. It's not desired, but unless it's a very high traffic rate, nothing should break. Joe From touch@isi.edu Tue Feb 5 12:54: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 C5D6D21F87E0 for ; Tue, 5 Feb 2013 12:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2S++lt6tQ00 for ; Tue, 5 Feb 2013 12:54:05 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3159421F8645 for ; Tue, 5 Feb 2013 12:54:05 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15KrpGx028482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 12:53:51 -0800 (PST) Message-ID: <5111715B.3090305@isi.edu> Date: Tue, 05 Feb 2013 12:53:47 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Yourtchenko References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 20:54:06 -0000 One observation on this doc's discussion: a middlebox that emits non-atomic (already fragmented or DF=0) packets on its public side MUST already rewrite the ID; otherwise, it's already doesn't comply with RFC 791. So if you're looking for a bug to fix, that's a very easy one to find. Joe On 2/5/2013 9:51 AM, Andrew Yourtchenko wrote: > Nalini, > > I took a stab at the initial version of the list here: > > https://docs.google.com/document/d/1TnONzdbicxwktuFzfjsZADdFSSNghK0GBzvPKAFneOc/edit?usp=sharing > > > I marked the doc as world-editable, and it has chat. So, both > synchronous (with chat for coordination) and asynchronous editing is > possible, and it's open for anyone regardless of the timezone, so should > ease the logistics. > > Let's see if this approach works in lieu of fully synchronous things > like meetings and webcasts. > > --a > > On Tue, 5 Feb 2013, Nalini Elkins wrote: > >> Andrew, >> >> I like the idea of truly defining the problem space very much! I >> have to say, the one problem I had with adding a fragmentation >> header to each packet is the number of bytes it would take add to each >> packet. I know people are already talking of potential >> performance impacts of the additional bytes just in the IPv6 main >> header! We may not have any choice at this point, but the fewer >> bytes added the better. >> >> I can certainly host a webcast where anyone interested can join in and >> comment on what qualities a possible solution should have. Is that a >> possibility for you? Then, we don't even need to wait for Orlando! >> >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> ___________________________________________________________________________________________________________________________________________ >> >> From: Andrew Yourtchenko >> To: Nalini Elkins >> Cc: IETF v6ops list >> Sent: Tuesday, February 5, 2013 9:08 AM >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >> >> Nalini, >> >> On Tue, 5 Feb 2013, Nalini Elkins wrote: >> >> > Andrew, >> > >> > I wonder if possible solutions can be worked out at a brainstorming >> session at the IETF in Orlando. We would like to get a group >> > together to think about solutions because I can tell you, we >> internally have gone around with each other on different solutions >> and >> > their drawbacks! Performance, security and implementation >> difficulties being some of the problems involved. >> > >> > I will ask the chairs if we can have a BOF, if this is not possible, >> then maybe we can all find a venue with beer and chips >> > available! I will post. >> >> I won't make it to Orlando, but I still think that we should try to >> squeeze as much of a problem space in terms of problem >> definition, and the qualities a potential solution should have, before >> going to define the solutions themselves. >> >> My quick sketch at how a potential solution's photorobot should look >> like, includes at least the following two traits: >> >> 1) be a property of every packet >> 2) be always present (i.e. not require a separate 'switch it on' knob >> that would trigger a different code path) >> 3) be frugal in terms of any packet space it occupies (0 bytes being >> the best) >> >> Probably there's a couple more - and then the rest of the traits >> should come out from the distilled use cases that the IP ID was >> used for. >> >> Such a list could then make a framework for evaluation of the >> potential solutions. >> >> --a >> >> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Fred.L.Templin@boeing.com Tue Feb 5 12:58: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 BCE0921F8609 for ; Tue, 5 Feb 2013 12:58:11 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFnB3zu+Ksot for ; Tue, 5 Feb 2013 12:58:11 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id DFAC121F859A for ; Tue, 5 Feb 2013 12:58:10 -0800 (PST) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r15KwA3n009180 for ; Tue, 5 Feb 2013 14:58:10 -0600 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r15Kw9Cd009157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 5 Feb 2013 14:58:09 -0600 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 5 Feb 2013 12:58:09 -0800 From: "Templin, Fred L" To: Joe Touch , Andrew Yourtchenko Date: Tue, 5 Feb 2013 12:58:08 -0800 Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: Ac4D4xurwO1bIf9CQneARkOBya7A6AAADFdg Message-ID: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> <5111715B.3090305@isi.edu> In-Reply-To: <5111715B.3090305@isi.edu> 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 X-TM-AS-MML: No Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 20:58:11 -0000 Hi Joe, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Tuesday, February 05, 2013 12:54 PM > To: Andrew Yourtchenko > Cc: IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 > One observation on this doc's discussion: >=20 > a middlebox that emits non-atomic (already fragmented or DF=3D0) packets > on its public side MUST already rewrite the ID; otherwise, it's already > doesn't comply with RFC 791. Sad but true, but I suspect there are plenty of middleboxes that already violate this requirement. Thanks - Fred fred.l.templin@boeing.com > So if you're looking for a bug to fix, that's a very easy one to find. >=20 > Joe >=20 > On 2/5/2013 9:51 AM, Andrew Yourtchenko wrote: > > Nalini, > > > > I took a stab at the initial version of the list here: > > > > > https://docs.google.com/document/d/1TnONzdbicxwktuFzfjsZADdFSSNghK0GBzvPK= A > FneOc/edit?usp=3Dsharing > > > > > > I marked the doc as world-editable, and it has chat. So, both > > synchronous (with chat for coordination) and asynchronous editing is > > possible, and it's open for anyone regardless of the timezone, so shoul= d > > ease the logistics. > > > > Let's see if this approach works in lieu of fully synchronous things > > like meetings and webcasts. > > > > --a > > > > On Tue, 5 Feb 2013, Nalini Elkins wrote: > > > >> Andrew, > >> > >> I like the idea of truly defining the problem space very much! I > >> have to say, the one problem I had with adding a fragmentation > >> header to each packet is the number of bytes it would take add to each > >> packet. I know people are already talking of potential > >> performance impacts of the additional bytes just in the IPv6 main > >> header! We may not have any choice at this point, but the fewer > >> bytes added the better. > >> > >> I can certainly host a webcast where anyone interested can join in and > >> comment on what qualities a possible solution should have. Is that a > >> possibility for you? Then, we don't even need to wait for Orlando! > >> > >> Thanks, > >> > >> Nalini Elkins > >> Inside Products, Inc. > >> (831) 659-8360 > >> www.insidethestack.com > >> > >> > _________________________________________________________________________= _ > _________________________________________________________________ > >> > >> From: Andrew Yourtchenko > >> To: Nalini Elkins > >> Cc: IETF v6ops list > >> Sent: Tuesday, February 5, 2013 9:08 AM > >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > >> > >> Nalini, > >> > >> On Tue, 5 Feb 2013, Nalini Elkins wrote: > >> > >> > Andrew, > >> > > >> > I wonder if possible solutions can be worked out at a brainstorming > >> session at the IETF in Orlando. We would like to get a group > >> > together to think about solutions because I can tell you, we > >> internally have gone around with each other on different solutions > >> and > >> > their drawbacks! Performance, security and implementation > >> difficulties being some of the problems involved. > >> > > >> > I will ask the chairs if we can have a BOF, if this is not possible, > >> then maybe we can all find a venue with beer and chips > >> > available! I will post. > >> > >> I won't make it to Orlando, but I still think that we should try to > >> squeeze as much of a problem space in terms of problem > >> definition, and the qualities a potential solution should have, before > >> going to define the solutions themselves. > >> > >> My quick sketch at how a potential solution's photorobot should look > >> like, includes at least the following two traits: > >> > >> 1) be a property of every packet > >> 2) be always present (i.e. not require a separate 'switch it on' knob > >> that would trigger a different code path) > >> 3) be frugal in terms of any packet space it occupies (0 bytes being > >> the best) > >> > >> Probably there's a couple more - and then the rest of the traits > >> should come out from the distilled use cases that the IP ID was > >> used for. > >> > >> Such a list could then make a framework for evaluation of the > >> potential solutions. > >> > >> --a > >> > >> > >> > > > > > > _______________________________________________ > > 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 mackermann@bcbsm.com Tue Feb 5 13:07: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 6ABA221F84FC for ; Tue, 5 Feb 2013 13:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ladY4HNFOVwO for ; Tue, 5 Feb 2013 13:07:45 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id CDF9C21F84FB for ; Tue, 5 Feb 2013 13:07:45 -0800 (PST) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 35F02136D43 for ; Tue, 5 Feb 2013 15:07:45 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id C2FD6136D40; Tue, 5 Feb 2013 15:07:43 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id B54D94F8049; Tue, 5 Feb 2013 16:06:20 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id AF87F4F804F; Tue, 5 Feb 2013 16:06:20 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Tue, 5 Feb 2013 16:07:43 -0500 From: "Ackermann, Michael" To: Joe Touch Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8CAATMIAIAAQkCggACO3wD//7KSQAAMhuaAAAo0HEA= Date: Tue, 5 Feb 2013 21:07:41 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0DF3FB@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A0DF2F1@PWN401EA160.ent.corp.bcbsm.com> <511170C3.5060706@isi.edu> In-Reply-To: <511170C3.5060706@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 21:07:46 -0000 Hi joe, Why do you say it is gone in IPV4? =20 I just used it to help me diagnose an issue last week. =20 I think I am in agreement with what you are saying, in that I also do not = want to add any unnecessary overhead or other unnecessary processing or = function. =20 I do know that IPID has been a very valuable diagnostic tool to me in many = critical situations over the years in v4.=20 That is why I am in currently in favor of focusing this RFC on the lack of = IPID in v6, as an issue and not focusing so much on what the specific = solution should be at this point. I am hopeful that if the IETF accepts this as something needing attention, = that greater minds than mine can craft an optimal solution. =20 Certainly sounds to me like you could/should be one of those? =20 -----Original Message----- From: Joe Touch =5Bmailto:touch=40isi.edu=5D=20 Sent: Tuesday, February 05, 2013 3:51 PM To: Ackermann, Michael Cc: Mark Smith; joel jaeggli; Templin, Fred L; IETF v6ops list Subject: Re: =5Bv6ops=5D new draft: draft-elkins-v6ops-ipv6-ipid-needed On 2/5/2013 12:25 PM, Ackermann, Michael wrote: =2E.. > I know every situation is unique but IPID has definitely helped us and = others in select situations, which is why we would hate to see it = eliminated. As has already been pointed out, it's already gone - both in IPv6 and in = IPv4. If such a tool is instrumental in analyzing network anomalies, it would be = useful to propose an alternative. However, it's trivial to have a = controlled source send packets with traceable contents, and I doubt we = need to have the entire Internet send information needed to trace problems = such as this. Keep in mind that in IP, packet duplication is *allowed*. It's not = desired, but unless it's a very high traffic rate, nothing should break. Joe The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From touch@isi.edu Tue Feb 5 13:08:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBB521F8506 for ; Tue, 5 Feb 2013 13:08:50 -0800 (PST) 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.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckZDIMn5F6Xl for ; Tue, 5 Feb 2013 13:08:48 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 93C1121F84FC for ; Tue, 5 Feb 2013 13:08:48 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15L7muj002731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 13:07:48 -0800 (PST) Message-ID: <511174A0.7020108@isi.edu> Date: Tue, 05 Feb 2013 13:07:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Templin, Fred L" References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <1360085143.44876.YahooMailNeo@web2815.biz.mail.ne1.yahoo.com> <5111715B.3090305@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 21:08:50 -0000 On 2/5/2013 12:58 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Joe Touch >> Sent: Tuesday, February 05, 2013 12:54 PM >> To: Andrew Yourtchenko >> Cc: IETF v6ops list >> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >> >> One observation on this doc's discussion: >> >> a middlebox that emits non-atomic (already fragmented or DF=0) packets >> on its public side MUST already rewrite the ID; otherwise, it's already >> doesn't comply with RFC 791. > > Sad but true, but I suspect there are plenty of middleboxes > that already violate this requirement. Certainly. But right now I would like to point out that: - there are boxes violating specs left and right and they're not hard to find or explain what's wrong - there are other boxes that are occasionally duplicating packets, and that's consistent with current specs So what's broken can already be identified. And what isn't broken doesn't warrant a new solution to detect. IMO. Joe > > Thanks - Fred > fred.l.templin@boeing.com > >> So if you're looking for a bug to fix, that's a very easy one to find. >> >> Joe >> >> On 2/5/2013 9:51 AM, Andrew Yourtchenko wrote: >>> Nalini, >>> >>> I took a stab at the initial version of the list here: >>> >>> >> https://docs.google.com/document/d/1TnONzdbicxwktuFzfjsZADdFSSNghK0GBzvPKA >> FneOc/edit?usp=sharing >>> >>> >>> I marked the doc as world-editable, and it has chat. So, both >>> synchronous (with chat for coordination) and asynchronous editing is >>> possible, and it's open for anyone regardless of the timezone, so should >>> ease the logistics. >>> >>> Let's see if this approach works in lieu of fully synchronous things >>> like meetings and webcasts. >>> >>> --a >>> >>> On Tue, 5 Feb 2013, Nalini Elkins wrote: >>> >>>> Andrew, >>>> >>>> I like the idea of truly defining the problem space very much! I >>>> have to say, the one problem I had with adding a fragmentation >>>> header to each packet is the number of bytes it would take add to each >>>> packet. I know people are already talking of potential >>>> performance impacts of the additional bytes just in the IPv6 main >>>> header! We may not have any choice at this point, but the fewer >>>> bytes added the better. >>>> >>>> I can certainly host a webcast where anyone interested can join in and >>>> comment on what qualities a possible solution should have. Is that a >>>> possibility for you? Then, we don't even need to wait for Orlando! >>>> >>>> Thanks, >>>> >>>> Nalini Elkins >>>> Inside Products, Inc. >>>> (831) 659-8360 >>>> www.insidethestack.com >>>> >>>> >> __________________________________________________________________________ >> _________________________________________________________________ >>>> >>>> From: Andrew Yourtchenko >>>> To: Nalini Elkins >>>> Cc: IETF v6ops list >>>> Sent: Tuesday, February 5, 2013 9:08 AM >>>> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >>>> >>>> Nalini, >>>> >>>> On Tue, 5 Feb 2013, Nalini Elkins wrote: >>>> >>>>> Andrew, >>>>> >>>>> I wonder if possible solutions can be worked out at a brainstorming >>>> session at the IETF in Orlando. We would like to get a group >>>>> together to think about solutions because I can tell you, we >>>> internally have gone around with each other on different solutions >>>> and >>>>> their drawbacks! Performance, security and implementation >>>> difficulties being some of the problems involved. >>>>> >>>>> I will ask the chairs if we can have a BOF, if this is not possible, >>>> then maybe we can all find a venue with beer and chips >>>>> available! I will post. >>>> >>>> I won't make it to Orlando, but I still think that we should try to >>>> squeeze as much of a problem space in terms of problem >>>> definition, and the qualities a potential solution should have, before >>>> going to define the solutions themselves. >>>> >>>> My quick sketch at how a potential solution's photorobot should look >>>> like, includes at least the following two traits: >>>> >>>> 1) be a property of every packet >>>> 2) be always present (i.e. not require a separate 'switch it on' knob >>>> that would trigger a different code path) >>>> 3) be frugal in terms of any packet space it occupies (0 bytes being >>>> the best) >>>> >>>> Probably there's a couple more - and then the rest of the traits >>>> should come out from the distilled use cases that the IP ID was >>>> used for. >>>> >>>> Such a list could then make a framework for evaluation of the >>>> potential solutions. >>>> >>>> --a >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 touch@isi.edu Tue Feb 5 13:24: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 1533121F8667 for ; Tue, 5 Feb 2013 13:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foZsslGY-haP for ; Tue, 5 Feb 2013 13:24:53 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A5ACA21F8596 for ; Tue, 5 Feb 2013 13:24:52 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r15LOO45007964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Feb 2013 13:24:24 -0800 (PST) Message-ID: <51117883.3090200@isi.edu> Date: Tue, 05 Feb 2013 13:24:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Ackermann, Michael" References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <4FC37E442D05A748896589E468752CAA0A0DEEC9@PWN401EA160.ent.corp.bcbsm.com> <1360092582.19685.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A0DF2F1@PWN401EA160.ent.corp.bcbsm.com> <511170C3.5060706@isi.edu> <4FC37E442D05A748896589E468752CAA0A0DF3FB@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A0DF3FB@PWN401EA160.ent.corp.bcbsm.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: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-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, 05 Feb 2013 21:24:54 -0000 On 2/5/2013 1:07 PM, Ackermann, Michael wrote: > Hi joe, > > Why do you say it is gone in IPV4? > I just used it to help me diagnose an issue last week. It *can* help when it's there and when it's unique, but you can't rely on either one. > I think I am in agreement with what you are saying, in that I also do not want to add any unnecessary overhead or other unnecessary processing or function. > > I do know that IPID has been a very valuable diagnostic tool to me in many critical situations over the years in v4. > That is why I am in currently in favor of focusing this RFC on the lack of IPID in v6, as an issue and not focusing so much on what the specific solution should be at this point. > I am hopeful that if the IETF accepts this as something needing attention, that greater minds than mine can craft an optimal solution. > Certainly sounds to me like you could/should be one of those? I would gladly support the idea of an optional fingerprint for network analysis. However, the IP ID - in IPv4 or IPv6 - is not and never was such a fingerprint. The fact that it has been misused this way, and that this has proven helpful is insufficient to suggest that this mechanism to support fragment reassembly is appropriate for network analysis. Joe > > > > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, February 05, 2013 3:51 PM > To: Ackermann, Michael > Cc: Mark Smith; joel jaeggli; Templin, Fred L; IETF v6ops list > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > > > > On 2/5/2013 12:25 PM, Ackermann, Michael wrote: > ... >> I know every situation is unique but IPID has definitely helped us and others in select situations, which is why we would hate to see it eliminated. > > As has already been pointed out, it's already gone - both in IPv6 and in IPv4. > > If such a tool is instrumental in analyzing network anomalies, it would be useful to propose an alternative. However, it's trivial to have a controlled source send packets with traceable contents, and I doubt we need to have the entire Internet send information needed to trace problems such as this. > > Keep in mind that in IP, packet duplication is *allowed*. It's not desired, but unless it's a very high traffic rate, nothing should break. > > Joe > > > 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. > From aservin@lacnic.net Tue Feb 5 16: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 6E52021F8941 for ; Tue, 5 Feb 2013 16:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sis7pMfYMOy8 for ; Tue, 5 Feb 2013 16:43:39 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7B46521F8915 for ; Tue, 5 Feb 2013 16:43:38 -0800 (PST) Received: from [IPv6:2800:af:ba30:d6e7:48c3:e9ba:4275:6547] (unknown [IPv6:2800:af:ba30:d6e7:48c3:e9ba:4275:6547]) by mail.lacnic.net.uy (Postfix) with ESMTP id 3C059308427 for ; Tue, 5 Feb 2013 22:43:19 -0200 (UYST) Message-ID: <5111A72B.2000804@lacnic.net> Date: Tue, 05 Feb 2013 22:43:23 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130205215743.30106.77867.idtracker@ietfa.amsl.com> In-Reply-To: <20130205215743.30106.77867.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130205215743.30106.77867.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 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: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 00:43:40 -0000 Hi, We have submitted a new version of draft-lopez-v6ops-dc-ipv6-04. Some of the changes we made: - We expanded the security section as suggested in the list. We included the attacks and security issues that we considered more important in DC infrastructure. Please let us know if you wanted to see more, or if some need to be expanded. - We added a new section "Other Operational Considerations" and we included topics such as Addressing, Cost and Monitoring/Management. If it want to include more topics let us know. - We re-organized some text in the introduction to be now under a renamed section "Architecture and Transition Stages" - We added text suggesting how to start moving applications to IPv6 within the DC - We added some text to explaining the motivations from moving from Dual-stack to IPv6-only as suggested in the list - We changed some text to improve reading as suggested by some people off-list - We fixed some typos - We updated some references - And we added a new author And I think that is all. Please let us know your comments. Best regards as -------- Original Message -------- Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt Date: Tue, 05 Feb 2013 13:57:43 -0800 From: internet-drafts@ietf.org To: aservin@lacnic.net CC: tina.tsou.zouting@huawei.com, diego@tid.es, cathy.zhou@huawei.com, 18918588897@189.cn A new version of I-D, draft-lopez-v6ops-dc-ipv6-04.txt has been successfully submitted by Arturo Servin and posted to the IETF repository. Filename: draft-lopez-v6ops-dc-ipv6 Revision: 04 Title: IPv6 Operational Guidelines for Datacenters Creation date: 2013-02-05 WG ID: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-lopez-v6ops-dc-ipv6-04.txt Status: http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6 Htmlized: http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-lopez-v6ops-dc-ipv6-04 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 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 Secretariat From zhenkaiw@gmail.com Tue Feb 5 17:52: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 90B1C21F8484 for ; Tue, 5 Feb 2013 17:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLs7Lh3pEc3I for ; Tue, 5 Feb 2013 17:52:05 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id A532E21F89D5 for ; Tue, 5 Feb 2013 17:52:05 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id v19so923317obq.21 for ; Tue, 05 Feb 2013 17:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/UWkpF5hr0ahcLt+oaE5yUkA/NXmj0v2Sv8dBkv7zWk=; b=lLKW7renufzK1FR0ST9vxb2kGZCLxQlrPW0EGdyKc59gtGkw+UPR/u0oJ5BsrLImhn 7UN4vrOGTdnB/1u9kE3CuGoVsuFhHK9GYNUvLsbz3FHG2zrJeDqQqW6QBjPUhl9CNicl cSjPPgLiCeioDGZLRTuCOnNs6C2YFxm8t1kjopjyOJCYjpHsAnTdsiCISLVb8gtnYwGu 4WNJYScI2so5Q/tbb5988iLwTLJyXCalfR9i1mB3ui7v4wAPXKF37eXwJ2OLU+C8Z9lE rLg+kXB5+kNxUg0bo5NfGihWH9frrHWr+DEoVirzKNLUx1D8wnnub+sxWUaP1Wsc7KJg 7gwA== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr19247045oec.116.1360115525138; Tue, 05 Feb 2013 17:52:05 -0800 (PST) Received: by 10.182.80.42 with HTTP; Tue, 5 Feb 2013 17:52:04 -0800 (PST) In-Reply-To: <00f301ce039c$480b3a80$4001a8c0@gateway.2wire.net> References: <8C48B86A895913448548E6D15DA7553B767174@xmb-rcd-x09.cisco.com> <00f301ce039c$480b3a80$4001a8c0@gateway.2wire.net> Date: Wed, 6 Feb 2013 09:52:04 +0800 Message-ID: From: Zhenkai Wang To: "t.petch" Content-Type: multipart/alternative; boundary=bcaec5523bb6babada04d50492f2 Cc: "" Subject: Re: [v6ops] China Mobile's Statement about IPR related todraft-ietf-v6ops-464xlat-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, 06 Feb 2013 01:52:13 -0000 --bcaec5523bb6babada04d50492f2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,The patent number informations are right, that can be searched in the SIPO=A1=AE website, or other patent database, eg:www.*google*.com/patentsAp= plication Number:200910088351.1 Publication Number:101931658 Application Date:2009-06-26 Publication Date: 2010-12-29 Thank you. ------------------------------ Wang Zhenkai IP Counsel | China Mobile Research Institute Office: +86 15801696688-35235 | Mobile: +8613810187794 | NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of China Mobile, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. 2013/2/5 t.petch > Thank you for the additional information. > > You posted a response to this list on 31st January which referred to a > disclosure http://datatracker.ietf.org/ipr/1730/ > which in turn refers to > Application Number =A3=BA200910088351.1 Publication Number =A3=BACN 10193= 1658 A > > The two numbers you give below seem to refer to a different Application, > and so potentially, a different IPR Claim. Can you clarify this for us? > > Tom Petch > > ----- Original Message ----- > From: "Zhenkai Wang" > To: "Fred Baker (fred)" > Cc: > Sent: Tuesday, February 05, 2013 9:24 AM > > Mr Fred: > > After we reasonably know the China Mobile=A1=AFs IPRs meeting the conditi= on > of > Section 6 of the RFC 3979 "Intellectual Property Rights in IETF > Technology", we will make disclosure update in accordance with the RFC > 3979 > for the http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09. > > The patent application CN200910085886.3 is still in the SIPO's > examination > process and the patent 200910085887.8 was granted at 2012.12.26, more > details can be read from the SIPO=A1=AFs website. > > Best regards, > > > ------------------------------ > Wang Zhenkai > > IP Counsel | China Mobile Research Institute > > Office: +86 15801696688-35235 | Mobile: +8613810187794 | > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. > > 2013/2/3 Fred Baker (fred) > > > Mr Wang: > > > > I speak here as one of the chairs of v6ops. This is a formal question > from > > the IETF to China Mobile, and the answer may affect how the IETF > treats the > > posted internet draft.. > > > > The question before the house is not whether China Mobile puts effort > into > > what it does; we assume that China Mobile does, just as we all do. The > > question regards the substance of the IPR claim - what claims have > been > > allowed or filed for in the patent - and whether the claims apply to > the > > current version of the draft. The statements of IPR were on the -00 > and -01 > > versions of the draft, which changed materially before reaching its > current > > status. > > > > The draft proposes no new technology; if that were not true, this > working > > group could not, by charter, consider it. It depends on several other > > technologies, notably > > > > https://tools.ietf.org/html/rfc6052 > > 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. > > Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=3D41849 > bytes) > > (Updates RFC4291) (Status: PROPOSED STANDARD) > > > > https://tools.ietf.org/html/rfc6144 > > 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. > > Yin. April 2011. (Format: TXT=3D67181 bytes) (Status: > INFORMATIONAL) > > > > https://tools.ietf.org/html/rfc6145 > > 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April > > 2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC2765) (Updated by > > RFC6791) (Status: PROPOSED STANDARD) > > > > https://tools.ietf.org/html/rfc6146 > > 6146 Stateful NAT64: Network Address and Protocol Translation from > > IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van > > Beijnum. April 2011. (Format: TXT=3D107954 bytes) (Status: PROPOSE= D > > STANDARD) > > > > https://tools.ietf.org/html/rfc6147 > > 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 > > Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. > van > > Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Status: PROPOSED > > STANDARD) > > > > plus several that are listed as "informative" in reading the document. > (I > > note that 6144 was overlooked in the bibliography of > > draft-ietf-v6ops-464xlat). Hence, this draft is not about technology > per > > se, it is about the use of existing technology in a 3GPP network. Is > China > > Mobile's patent about the use of the technologies in a 3GPP network, > or is > > it on the technologies themselves? What is the substance of the IPR > claim? > > Does it apply to > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09? > > > > Fred Baker > > co-chair, IETF IPv6 Operations Working Group > > > > On Jan 29, 2013, at 7:08 PM, Zhenkai Wang wrote: > > > > > Hello IETF, > > > > > > As a company, China Mobile has spent lots of efforts like > expenditure of > > man workforce, time, et al. on some technologies. We underline that > > Intellectual property Rights (IPRs) are an important part of > technologies, > > and also respect IPRs like other companies in the industry. > > > > > > The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is > a > > compliance with the rules of the IETF which are defined in RFC 3979, > > "Intellectual Property Rights in IETF Technology." The licensing > > declaration for this Document =A1=AEc) Reasonable and Non-Discriminator= y > License > > to All Implementers with Possible Royalty/Fee=A1=AF made by China Mobil= e > was in > > accordance with our corporate strategy, as well as industry practice. > > > > > > Best regards, > > > > > > Wang Zhengkai > > > > > > Wang Zhenkai > > > IP Counsel | China Mobile Research Institute > > > Office: +86 15801696688-35235 | Mobile: +8613810187794 | > > > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. > > > --bcaec5523bb6babada04d50492f2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi,
The patent number informations are r= ight, that can be searched in the SIPO‘ website, or other patent data= base, eg:www.google.com/patents
Application Number:200= 910088351.1
Publication Number:101931658
Application Date:2009-06-26
Publication Date:2010-12-29

Thank you.
 
Wang Zhenkai

 IP Counsel | China Mobile Research Institute

Office: +86 15801696688-35235 | Mobile: +8= 613810187794 |

NO.32 Xuanwumen West Street,Xicheng District,Beijing&n= bsp;100053.China.
 
Confidentiality Notice: The information contained in this e-= mail and any accompanying attachment(s) is intended only for the use of the= intended recipient and may be confidential and/or privileged of China Mobi= le, its subsidiaries and/or its affiliates. If any reader of this communica= tion is not the intended recipient, unauthorized use, forwarding, printing,= storing, disclosure or copying is strictly prohibited, and may be unlawful= . If you have received this communication in error, please immediately noti= fy the sender by return e-mail, and delete the original message and all cop= ies from your system. Thank you.


2013/2/5 t.petch <<= a href=3D"mailto:ietfc@btconnect.com" target=3D"_blank">ietfc@btconnect.com= >
Thank you for the additional information.

You posted a response to this list on 31st January which referred to a
disclosure http://datatracker.ietf.org/ipr/1730/
which in turn refers to
Application Number =A3=BA200910088351.1 Publication Number =A3=BACN 1019316= 58 A

The two numbers you give below seem to refer to a different Application, and so potentially, a different IPR Claim.  Can you clarify this for u= s?

Tom Petch

----- Original Message -----
From: "Zhenkai Wang" <zh= enkaiw@gmail.com>
To: "Fred Baker (fred)" <fre= d@cisco.com>
Cc: <v6ops@ietf.org>
Sent: Tuesday, February 05, 2013 9:24 AM

Mr Fred:

After we reasonably know the China Mobile’s IPRs meeting the conditio= n
of
Section 6 of the RFC 3979 "Intellectual Property Rights in IETF
Technology", we will make disclosure update in accordance with the RFC=
3979
for the http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09.

The patent application CN200910085886.3 is still in the SIPO's
examination
process and the patent 200910085887.8 was granted at 2012.12.26, more
details can be read from the SIPO’s website.

 Best regards,


 ------------------------------
  Wang Zhenkai

 IP Counsel | China Mobile Research Institute

Office: +86 15801696688-35235 | Mobile: +8613810187794 |
NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China.

2013/2/3 Fred Baker (fred) <fred@cisco= .com>

> Mr Wang:
>
> I speak here as one of the chairs of v6ops. This is a formal question<= br> from
> the IETF to China Mobile, and the answer may affect how the IETF
treats the
> posted internet draft..
>
> The question before the house is not whether China Mobile puts effort<= br> into
> what it does; we assume that China Mobile does, just as we all do. The=
> question regards the substance of the IPR claim - what claims have
been
> allowed or filed for in the patent - and whether the claims apply to the
> current version of the draft. The statements of IPR were on the -00 and -01
> versions of the draft, which changed materially before reaching its current
> status.
>
> The draft proposes no new technology; if that were not true, this
working
> group could not, by charter, consider it. It depends on several other<= br> > technologies, notably
>
> http= s://tools.ietf.org/html/rfc6052
> 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M.<= br> >      Bagnulo, M. Boucadair, X. Li. October 2010. (Forma= t: TXT=3D41849
bytes)
>      (Updates RFC4291) (Status: PROPOSED STANDARD)
>
> http= s://tools.ietf.org/html/rfc6144
> 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K.<= br> >      Yin. April 2011. (Format: TXT=3D67181 bytes) (Stat= us:
INFORMATIONAL)
>
> http= s://tools.ietf.org/html/rfc6145
> 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April
>      2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC27= 65) (Updated by
>      RFC6791) (Status: PROPOSED STANDARD)
>
> http= s://tools.ietf.org/html/rfc6146
> 6146 Stateful NAT64: Network Address and Protocol Translation from
>      IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matth= ews, I. van
>      Beijnum. April 2011. (Format: TXT=3D107954 bytes) = (Status: PROPOSED
>      STANDARD)
>
> http= s://tools.ietf.org/html/rfc6147
> 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 >      Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, = P. Matthews, I.
van
>      Beijnum. April 2011. (Format: TXT=3D75103 bytes) (= Status: PROPOSED
>      STANDARD)
>
> plus several that are listed as "informative" in reading the= document.
(I
> note that 6144 was overlooked in the bibliography of
> draft-ietf-v6ops-464xlat). Hence, this draft is not about technology per
> se, it is about the use of existing technology in a 3GPP network. Is China
> Mobile's patent about the use of the technologies in a 3GPP networ= k,
or is
> it on the technologies themselves? What is the substance of the IPR claim?
> Does it apply to
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09?
>
> Fred Baker
> co-chair, IETF IPv6 Operations Working Group
>
> On Jan 29, 2013, at 7:08 PM, Zhenkai Wang <zhenkaiw@gmail.com> wrote:
>
> > Hello IETF,
> >
> > As a company, China Mobile has spent lots of efforts like
expenditure of
> man workforce, time, et al. on some technologies. We underline that > Intellectual property Rights (IPRs) are an important part of
technologies,
> and also respect IPRs like other companies in the industry.
> >
> > The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is=
a
> compliance with the rules of the IETF which are defined in RFC 3979, > "Intellectual Property Rights in IETF Technology." The licen= sing
> declaration for this Document ‘c) Reasonable and Non-Discriminat= ory
License
> to All Implementers with Possible Royalty/Fee’ made by China Mob= ile
was in
> accordance with our corporate strategy, as well as industry practice.<= br> > >
> > Best regards,
> >
> > Wang Zhengkai
> >
> > Wang Zhenkai
> >  IP Counsel | China Mobile Research Institute
> > Office: +86 15801696688-35235 | Mobile: +8613810187794 |
> > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China= .



--bcaec5523bb6babada04d50492f2-- From cb.list6@gmail.com Tue Feb 5 18:00: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 72A4C21F89A4 for ; Tue, 5 Feb 2013 18:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYeHcddIwiMy for ; Tue, 5 Feb 2013 18:00:21 -0800 (PST) Received: from mail-la0-x22a.google.com (la-in-x022a.1e100.net [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9D821F8996 for ; Tue, 5 Feb 2013 18:00:15 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so875465lab.15 for ; Tue, 05 Feb 2013 18:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JSK9zzf97vwI2EeieGsvWO1aA9dPtqXLWIj2q1Gtre8=; b=C983kJOTtVgXYQ0r+o/RdZvCT0yKKtLE1Pmr1UsRxNXk+7GwRxZoLTJYPYL/YzcAT0 euXBBjPAtjQUvextITHRjmbP54kF7qEVk04jG3jZRHQ+VTUqITqCZm8XyzVhQlVG4a7o lcbHV8rtS21UZjeDsoX5WmXBbsU/I8a5mGZX978Rj9iMTsqsLfEeUz7qP+pMcPQh+oX4 7s2+9+FPy+B2bfevn3OgWbVg17Or9heNcD5otg1zdkyrl2FyW2p5PRPyqixYKN/SLmPX frBEOnM0gJOCHV5+yvmBg1oIb/UIfojdgCQh+5p87Z1foPvo4/g6WQqWLbPmtYBGGpBr W0ew== MIME-Version: 1.0 X-Received: by 10.112.51.44 with SMTP id h12mr10425076lbo.111.1360116013962; Tue, 05 Feb 2013 18:00:13 -0800 (PST) Received: by 10.112.7.165 with HTTP; Tue, 5 Feb 2013 18:00:13 -0800 (PST) Received: by 10.112.7.165 with HTTP; Tue, 5 Feb 2013 18:00:13 -0800 (PST) In-Reply-To: References: <8C48B86A895913448548E6D15DA7553B767174@xmb-rcd-x09.cisco.com> <00f301ce039c$480b3a80$4001a8c0@gateway.2wire.net> Date: Tue, 5 Feb 2013 18:00:13 -0800 Message-ID: From: Cameron Byrne To: Zhenkai Wang Content-Type: multipart/alternative; boundary=f46d04017147dd95d004d504af6b Cc: "<,v6ops@ietf.org>," Subject: Re: [v6ops] China Mobile's Statement about IPR related todraft-ietf-v6ops-464xlat-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, 06 Feb 2013 02:00:22 -0000 --f46d04017147dd95d004d504af6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Are there any international applications or patent grants that may impact this work? Or is it just this one disclosed patent China? Thanks, CB Sent from ipv6-only Android On Feb 5, 2013 5:52 PM, "Zhenkai Wang" wrote: > Hi,The patent number informations are right, that can be searched in the > SIPO=E2=80=98 website, or other patent database, eg:www.*google*.com/pate= ntsApplication > Number:200910088351.1 > Publication Number:101931658 Application Date:2009-06-26 Publication > Date:2010-12-29 > Thank you. > ------------------------------ > Wang Zhenkai > > IP Counsel | China Mobile Research Institute > > Office: +86 15801696688-35235 | Mobile: +8613810187794 | > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. > > Confidentiality Notice: The information contained in this e-mail and any > accompanying attachment(s) is intended only for the use of the intended > recipient and may be confidential and/or privileged of China Mobile, its > subsidiaries and/or its affiliates. If any reader of this communication i= s > not the intended recipient, unauthorized use, forwarding, printing, > storing, disclosure or copying is strictly prohibited, and may be unlawfu= l. > If you have received this communication in error, please immediately noti= fy > the sender by return e-mail, and delete the original message and all copi= es > from your system. Thank you. > > > 2013/2/5 t.petch > >> Thank you for the additional information. >> >> You posted a response to this list on 31st January which referred to a >> disclosure http://datatracker.ietf.org/ipr/1730/ >> which in turn refers to >> Application Number =EF=BC=9A200910088351.1 Publication Number =EF=BC=9AC= N 101931658 A >> >> The two numbers you give below seem to refer to a different Application, >> and so potentially, a different IPR Claim. Can you clarify this for us? >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Zhenkai Wang" >> To: "Fred Baker (fred)" >> Cc: >> Sent: Tuesday, February 05, 2013 9:24 AM >> >> Mr Fred: >> >> After we reasonably know the China Mobile=E2=80=99s IPRs meeting the con= dition >> of >> Section 6 of the RFC 3979 "Intellectual Property Rights in IETF >> Technology", we will make disclosure update in accordance with the RFC >> 3979 >> for the http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09. >> >> The patent application CN200910085886.3 is still in the SIPO's >> examination >> process and the patent 200910085887.8 was granted at 2012.12.26, more >> details can be read from the SIPO=E2=80=99s website. >> >> Best regards, >> >> >> ------------------------------ >> Wang Zhenkai >> >> IP Counsel | China Mobile Research Institute >> >> Office: +86 15801696688-35235 | Mobile: +8613810187794 | >> NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. >> >> 2013/2/3 Fred Baker (fred) >> >> > Mr Wang: >> > >> > I speak here as one of the chairs of v6ops. This is a formal question >> from >> > the IETF to China Mobile, and the answer may affect how the IETF >> treats the >> > posted internet draft.. >> > >> > The question before the house is not whether China Mobile puts effort >> into >> > what it does; we assume that China Mobile does, just as we all do. The >> > question regards the substance of the IPR claim - what claims have >> been >> > allowed or filed for in the patent - and whether the claims apply to >> the >> > current version of the draft. The statements of IPR were on the -00 >> and -01 >> > versions of the draft, which changed materially before reaching its >> current >> > status. >> > >> > The draft proposes no new technology; if that were not true, this >> working >> > group could not, by charter, consider it. It depends on several other >> > technologies, notably >> > >> > https://tools.ietf.org/html/rfc6052 >> > 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. >> > Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=3D41849 >> bytes) >> > (Updates RFC4291) (Status: PROPOSED STANDARD) >> > >> > https://tools.ietf.org/html/rfc6144 >> > 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. >> > Yin. April 2011. (Format: TXT=3D67181 bytes) (Status: >> INFORMATIONAL) >> > >> > https://tools.ietf.org/html/rfc6145 >> > 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April >> > 2011. (Format: TXT=3D76484 bytes) (Obsoletes RFC2765) (Updated by >> > RFC6791) (Status: PROPOSED STANDARD) >> > >> > https://tools.ietf.org/html/rfc6146 >> > 6146 Stateful NAT64: Network Address and Protocol Translation from >> > IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van >> > Beijnum. April 2011. (Format: TXT=3D107954 bytes) (Status: PROPOS= ED >> > STANDARD) >> > >> > https://tools.ietf.org/html/rfc6147 >> > 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 >> > Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. >> van >> > Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Status: PROPOSE= D >> > STANDARD) >> > >> > plus several that are listed as "informative" in reading the document. >> (I >> > note that 6144 was overlooked in the bibliography of >> > draft-ietf-v6ops-464xlat). Hence, this draft is not about technology >> per >> > se, it is about the use of existing technology in a 3GPP network. Is >> China >> > Mobile's patent about the use of the technologies in a 3GPP network, >> or is >> > it on the technologies themselves? What is the substance of the IPR >> claim? >> > Does it apply to >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09? >> > >> > Fred Baker >> > co-chair, IETF IPv6 Operations Working Group >> > >> > On Jan 29, 2013, at 7:08 PM, Zhenkai Wang wrote: >> > >> > > Hello IETF, >> > > >> > > As a company, China Mobile has spent lots of efforts like >> expenditure of >> > man workforce, time, et al. on some technologies. We underline that >> > Intellectual property Rights (IPRs) are an important part of >> technologies, >> > and also respect IPRs like other companies in the industry. >> > > >> > > The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is >> a >> > compliance with the rules of the IETF which are defined in RFC 3979, >> > "Intellectual Property Rights in IETF Technology." The licensing >> > declaration for this Document =E2=80=98c) Reasonable and Non-Discrimin= atory >> License >> > to All Implementers with Possible Royalty/Fee=E2=80=99 made by China M= obile >> was in >> > accordance with our corporate strategy, as well as industry practice. >> > > >> > > Best regards, >> > > >> > > Wang Zhengkai >> > > >> > > Wang Zhenkai >> > > IP Counsel | China Mobile Research Institute >> > > Office: +86 15801696688-35235 | Mobile: +8613810187794 | >> > > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China. >> >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --f46d04017147dd95d004d504af6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks

Are there any international applications or patent grants th= at may impact this work?

Or is it just this one disclosed patent China?=C2=A0=C2=A0 <= /p>

Thanks,

CB

Sent from ipv6-only Android

On Feb 5, 2013 5:52 PM, "Zhenkai Wang"= <zhenkaiw@gmail.com> wrote= :
Hi,
The patent number informations are right, = that can be searched in the SIPO=E2=80=98 website, or other patent database= , eg:www.google.com/patents
Application Number:200910088351.= 1
Publication Number:101931658
Application Date:2009-06-26
Publication Date:2010-12-29

Thank you.
=C2=A0
=
Wang Zhenkai

=C2=A0IP Counsel | China Mobile = Research Institute

Office: +86 15801696688-35235 = | Mobile: +8613810187794=C2=A0|

NO.32=C2=A0Xuanwumen=C2=A0West=C2=A0Street,Xicheng=C2=A0Dist= rict,Beijing=C2=A0100053.China. <= /span>
=C2=A0
Confidentiality Notice: The information containe= d in this e-mail and any accompanying attachment(s) is intended only for th= e use of the intended recipient and may be confidential and/or privileged o= f China Mobile, its subsidiaries and/or its affiliates. If any reader of th= is communication is not the intended recipient, unauthorized use, forwardin= g, printing, storing, disclosure or copying is strictly prohibited, and may= be unlawful. If you have received this communication in error, please imme= diately notify the sender by return e-mail, and delete the original message= and all copies from your system. Thank you.


2013/2/5 t.petch <<= a href=3D"mailto:ietfc@btconnect.com" target=3D"_blank">ietfc@btconnect.com= >
Thank you for the additional information.

You posted a response to this list on 31st January which referred to a
disclosure http://datatracker.ietf.org/ipr/1730/
which in turn refers to
Application Number =EF=BC=9A200910088351.1 Publication Number =EF=BC=9ACN 1= 01931658 A

The two numbers you give below seem to refer to a different Application, and so potentially, a different IPR Claim. =C2=A0Can you clarify this for u= s?

Tom Petch

----- Original Message -----
From: "Zhenkai Wang" <zhenkaiw@gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Cc: <v6ops@ietf.org<= /a>>
Sent: Tuesday, February 05, 2013 9:24 AM

Mr Fred:

After we reasonably know the China Mobile=E2=80=99s IPRs meeting the condit= ion
of
Section 6 of the RFC 3979 "Intellectual Property Rights in IETF
Technology", we will make disclosure update in accordance with the RFC=
3979
for the http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09.

The patent application CN200910085886.3 is still in the SIPO's
examination
process and the patent 200910085887.8 was granted at 2012.12.26, more
details can be read from the SIPO=E2=80=99s website.

=C2=A0Best regards,


=C2=A0------------------------------
=C2=A0 Wang Zhenkai

=C2=A0IP Counsel | China Mobile Research Institute

Office: +86 15801696688-35235 | Mobile: +8613810187794 |
NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China.

2013/2/3 Fred Baker (fred) <fred@cisco.com>

> Mr Wang:
>
> I speak here as one of the chairs of v6ops. This is a formal question<= br> from
> the IETF to China Mobile, and the answer may affect how the IETF
treats the
> posted internet draft..
>
> The question before the house is not whether China Mobile puts effort<= br> into
> what it does; we assume that China Mobile does, just as we all do. The=
> question regards the substance of the IPR claim - what claims have
been
> allowed or filed for in the patent - and whether the claims apply to the
> current version of the draft. The statements of IPR were on the -00 and -01
> versions of the draft, which changed materially before reaching its current
> status.
>
> The draft proposes no new technology; if that were not true, this
working
> group could not, by charter, consider it. It depends on several other<= br> > technologies, notably
>
> http= s://tools.ietf.org/html/rfc6052
> 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M.<= br> > =C2=A0 =C2=A0 =C2=A0Bagnulo, M. Boucadair, X. Li. October 2010. (Forma= t: TXT=3D41849
bytes)
> =C2=A0 =C2=A0 =C2=A0(Updates RFC4291) (Status: PROPOSED STANDARD)
>
> http= s://tools.ietf.org/html/rfc6144
> 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K.<= br> > =C2=A0 =C2=A0 =C2=A0Yin. April 2011. (Format: TXT=3D67181 bytes) (Stat= us:
INFORMATIONAL)
>
> http= s://tools.ietf.org/html/rfc6145
> 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April
> =C2=A0 =C2=A0 =C2=A02011. (Format: TXT=3D76484 bytes) (Obsoletes RFC27= 65) (Updated by
> =C2=A0 =C2=A0 =C2=A0RFC6791) (Status: PROPOSED STANDARD)
>
> http= s://tools.ietf.org/html/rfc6146
> 6146 Stateful NAT64: Network Address and Protocol Translation from
> =C2=A0 =C2=A0 =C2=A0IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matth= ews, I. van
> =C2=A0 =C2=A0 =C2=A0Beijnum. April 2011. (Format: TXT=3D107954 bytes) = (Status: PROPOSED
> =C2=A0 =C2=A0 =C2=A0STANDARD)
>
> http= s://tools.ietf.org/html/rfc6147
> 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 > =C2=A0 =C2=A0 =C2=A0Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, = P. Matthews, I.
van
> =C2=A0 =C2=A0 =C2=A0Beijnum. April 2011. (Format: TXT=3D75103 bytes) (= Status: PROPOSED
> =C2=A0 =C2=A0 =C2=A0STANDARD)
>
> plus several that are listed as "informative" in reading the= document.
(I
> note that 6144 was overlooked in the bibliography of
> draft-ietf-v6ops-464xlat). Hence, this draft is not about technology per
> se, it is about the use of existing technology in a 3GPP network. Is China
> Mobile's patent about the use of the technologies in a 3GPP networ= k,
or is
> it on the technologies themselves? What is the substance of the IPR claim?
> Does it apply to
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09?
>
> Fred Baker
> co-chair, IETF IPv6 Operations Working Group
>
> On Jan 29, 2013, at 7:08 PM, Zhenkai Wang <zhenkaiw@gmail.com> wrote:
>
> > Hello IETF,
> >
> > As a company, China Mobile has spent lots of efforts like
expenditure of
> man workforce, time, et al. on some technologies. We underline that > Intellectual property Rights (IPRs) are an important part of
technologies,
> and also respect IPRs like other companies in the industry.
> >
> > The disclosure about patent http://datatracker.ietf.org/ipr/1730/ is=
a
> compliance with the rules of the IETF which are defined in RFC 3979, > "Intellectual Property Rights in IETF Technology." The licen= sing
> declaration for this Document =E2=80=98c) Reasonable and Non-Discrimin= atory
License
> to All Implementers with Possible Royalty/Fee=E2=80=99 made by China M= obile
was in
> accordance with our corporate strategy, as well as industry practice.<= br> > >
> > Best regards,
> >
> > Wang Zhengkai
> >
> > Wang Zhenkai
> > =C2=A0IP Counsel | China Mobile Research Institute
> > Office: +86 15801696688-35235 | Mobile: +8613810187794 |
> > NO.32 Xuanwumen West Street,Xicheng District,Beijing 100053.China= .




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

--f46d04017147dd95d004d504af6b-- From otroan@employees.org Wed Feb 6 05:41: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 6A8AE21F875F for ; Wed, 6 Feb 2013 05:41:41 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyJnEzkzBwUN for ; Wed, 6 Feb 2013 05:41:36 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7421F871D for ; Wed, 6 Feb 2013 05:41:36 -0800 (PST) Received: from dhcp-lys01-vla250-10-147-113-8.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 222D95F3E; Wed, 6 Feb 2013 05:41:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <510C47F0.5040808@bogus.com> Date: Wed, 6 Feb 2013 14:41:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 06 Feb 2013 13:41:41 -0000 I'm fine with publishing this considering the IPR. I would much have preferred this to be an informational document though. as it can hardly be said to be best current practice for how to deliver = IPv4 service. - native IPv4 is. - even in an IPv6 only access network, there are better solutions; e.g. = MAP-E, DS-lite... 464xlat is what's left when the operator (or your host implementation) = doesn't support anything else. the smallest common denominator isn't best current practice. cheers, Ole From wesley.george@twcable.com Wed Feb 6 06: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 93BFA21F870E for ; Wed, 6 Feb 2013 06:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH5uC35aNveL for ; Wed, 6 Feb 2013 06:05:14 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id BF96221F853A for ; Wed, 6 Feb 2013 06:05:14 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,615,1355115600"; d="scan'208";a="22818526" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 06 Feb 2013 09:04:50 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 6 Feb 2013 09:05:12 -0500 From: "George, Wes" To: joel jaeggli , IPv6 Ops WG Date: Wed, 6 Feb 2013 09:05:09 -0500 Thread-Topic: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4DD3z3vr2BsLRaRia25mOgDUWJzABYs3bw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033DD441BB@PRVPEXVS15.corp.twcable.com> References: <51100E9D.6050803@bogus.com> In-Reply-To: <51100E9D.6050803@bogus.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] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 06 Feb 2013 14:05:15 -0000 I would rather see this as an informational document. Like others, I'm not = convinced it actually is best common practice, and I'm even more leery of d= eclaring it so when it is encumbered with an IPR morass. China Mobile's answers have done nothing to instill confidence that it will= be anything less than such for those interested in implementing it. I also= do not believe that the document is made any less useful by being released= as informational instead of BCP. Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of joel jaeggli > Sent: Monday, February 04, 2013 2:40 PM > To: IPv6 Ops WG; Working Group Chairs > Subject: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination > of Stateful andStateless Translation' to Best CurrentPractice (draft- > ietf-v6ops-464xlat-09.txt) > > To emphasize Fred's request, please share you opinion on whether this > document should be published intact (as a BCP), with with a lower state > (informational), or not at all, given the IPR disclosure associated with > it. > > The document can be reviewed here: > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > > the known IPR disclosure is here: > > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&documen= t > _search=3Ddraft-ietf-v6ops-464xlat > > if you have registered your opinion on this subject already you will be > counted. > > The deadline for commentary is Monday Feb 11th 2012. > > _______________________________________________ > 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 warren@kumari.net Wed Feb 6 06:44: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 F3FA121F85E2 for ; Wed, 6 Feb 2013 06:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq3pGizqpW0r for ; Wed, 6 Feb 2013 06:44:20 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9150821F8472 for ; Wed, 6 Feb 2013 06:44:19 -0800 (PST) Received: from my.router (unknown [205.201.181.4]) by vimes.kumari.net (Postfix) with ESMTPSA id 19EBF1B40136; Wed, 6 Feb 2013 09:44:18 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <1360094003.76755.YahooMailNeo@web2811.biz.mail.ne1.yahoo.com> Date: Wed, 6 Feb 2013 09:44:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1360094003.76755.YahooMailNeo@web2811.biz.mail.ne1.yahoo.com> To: Nalini Elkins X-Mailer: Apple Mail (2.1499) Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:44:22 -0000 On Feb 5, 2013, at 2:53 PM, Nalini Elkins = wrote: > Mark, >=20 > Tools are a different topic. A number of companies, including mine, = have intelligent packet analyzers. =20 I believe you sell packet analyzers, no? (The word "have" in the above = made it sound like you purchased / own a packet analyzer from someone = else). > For us, there is nothing our products like better than thousands of = packets that we can read in and then help the customer to pinpoint = problems to the exact packet. This is the trend of the future. Ahhhh! The trend of the future. Well, that's all alright then=85. > The volume of data and packets soon outpaces what we mere humans can = do. We need a partnership between intelligent tools and intelligent = humans. >=20 Oh dear=85 "volume of data and packets soon outpaces what we mere = humans can do". That's worrying, because up till now I've been picking = bits off the wire with an oscilloscope, scribbling them down on a piece = of paper *really quickly*, converting the bits to hex in my head and = then reassembling the packets and streams=85 Sometimes calculating the = checksum on my fingers is tricky, but I usually get it right the second = or third time. Oh, and don't even get me started on trying to do this = with VoIP or video -- the codec designers really should take into = account how hard decoding is for a human=85 > I would actually love to have a discussion at some point on best = practices in troubleshooting. =20 So=85. The last time this came up (around August 2011 in the = "draft-elkins-6man-ipv6-diagnostic-header" thread, part of which is = here: http://www.ietf.org/mail-archive/web/v6ops/current/msg10275.html) = a number of operators who actually *do* troubleshooting provided a = number of ideas. AFACT / AFAIR, none of them said that they use IPID in v4 very often at = all. They did provide a number of their troubleshooting techniques for = these sorts of issues... Some snippets from that thread: =46rom yourself in = http://www.ietf.org/mail-archive/web/v6ops/current/msg10260.html: "I am working on contacting a number of our large corporate customers to = weigh in on this topic. I think that the biggest issue here is that = when a large commercial network is having problems, anything that can = help speed diagnostics is worth doing. Outages and poor performance can = cost a great deal of money. =20 Situations such as comparing packets at various points on the network to = determine packet loss is a necessary part of network problem = determination. I am working to get the technicians from the = corporations themselves to get onto this email list and tell their = opinions themselves." We didn't see your "large corporate customers" (nor, I suspect did we = really want to), but we did have a number of folk present a bunch of = ideas (many of them operators who perform troubleshooting on large = networks on a daily basis) For example, Carlos suggested = (http://www.ietf.org/mail-archive/web/v6ops/current/msg10266.html): "To compare packets, we could potentially have the network protocol analyzer (e.g., Wireshark) compute a hash on invariant fields of the packet (i.e., exclude Hop Limit, etc), and present that as packet metadata that is not actually carried on the wire." you replied: "Well, that is a really good idea that we had explored also. Now, we = ourselves make an intelligent packet analyzer and work with the = WireShark folks. If I look at this selfishly for having an extra = selling point for my products, then I can say, 'Yes, we allow you to do = this! Buy my product!' But, I was trying to be a good citizen and = allow all to do this without our products. Now, if our proposal is not = adopted, then we will do the checksum or hash on the packets in our = products as I think it is needed for diagnostics. " Did you implement this? (I'd like to note that this exact same = suggestion came up in this thread). Shane Amante suggested (in = http://www.ietf.org/mail-archive/web/v6ops/current/msg10270.html=20 "Have you taken a look at flow-spec for IPv4: http://tools.ietf.org/html/rfc5575 ... and, flow-spec for IPv6: http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00 (Both the RFC and I-D are within the IDR WG). In summary, using flow-spec one can define an ACL that then get = distributed across all routers within an ASN, via BGP, that can then be = used to count matching packets, log packet header information, etc. = It's up to the operator to decide what ACL to be applied and what = 'action' (logging, counting, etc.) to be taken for packets that match a = given 'rule'. =20 =46rom where I'm sitting, this seems like it might already solve the = problem you're having, without having to invent a wholly new IPv6 = Destination Header Option. So, I would like to know if you have taken a = look at flow-spec and, if so, why it was ruled out?" and then answered a bunch of your questions (from which it seemed you = hadn't read the references he sent).=20 Shane also suggested sFlow / NetFlow / IPFIX and ACLs with RSPAN. Did you investigate / implement these? I don't see a flow collector / = span endpoint lester in your products... As was said in the previous go-round on this, and in this thread, it is = unclear what exactly the problem statement is.=20 Apart from feeling very markety[0], much of this sounds like "If all you = have is a hammer, everything looks like a nail". A simple, clear, concise description of *what* problem you are trying to = solve (without any references to how much time you have saved using = IPID, how it is the most wonderful, awesomest thing ever, etc) would = help a bunch... W [0]: Which might be causing much of my grumpiness in this response... > Our ultimate goal is to have the right performance and troubleshooting = metrix built right into the protocols from the get-go! > =20 > Thanks, >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com >=20 > From: Mark Smith > To: Nalini Elkins ; Joe Touch = ; Andrew Yourtchenko =20 > Cc: IETF v6ops list =20 > Sent: Tuesday, February 5, 2013 11:42 AM > Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed >=20 >=20 >=20 >=20 >=20 >=20 > >________________________________ > > From: Nalini Elkins > >To: Joe Touch ; Andrew Yourtchenko = =20 > >Cc: IETF v6ops list =20 > >Sent: Wednesday, 6 February 2013 6:28 AM > >Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > >=20 > > > >Joe, > > > > > >Well, duplicate packets are often retransmissions.=20 > > > > >=20 > This can be quite easily determined by comparing sent packet counts at = one end with received packet counts at the other. I'd consider doing = that to be much easier than capturing 1000s of packets and then looking = through them with an analyser to try to spot duplicate packets. I = consider using a packet analyser to be a last resort when = troubleshooting because you're usually dealing with 1000s, 10 000s or = 100 000s of packets, and trying to spot a trend or pick the bad = individual packet. It can also be quite onerous to setup the packet = capture and the volume of data can huge. >=20 > Some of these examples are starting sound like you've been taking the = approach of "how can we use IPID to troubleshoot this" rather than "what = is the most effective tool to troubleshoot this", of which IPID might be = one for a particular situation.=20 >=20 > > > > > > If you have retransmissions, then the other end (or the network) is = not absorbing the flow properly. Then, on our end, we need to see if we = have allocated enough bandwidth, it is going over a sub-optimal route, = etc. > >=20 > >Thanks, > > > > > >Nalini Elkins > >Inside Products, Inc. > >(831) 659-8360 > >www.insidethestack.com > > > > > > > >________________________________ > > From: Joe Touch > >To: Andrew Yourtchenko =20 > >Cc: Nalini Elkins ; IETF v6ops list = =20 > >Sent: Tuesday, February 5, 2013 10:25 AM > >Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed > >=20 > >PS - I'm particularly interested in an explanation of why duplicate=20= > >packets would be an indication of congestion, FWIW. > > > >Joe > > > >On 2/5/2013 10:20 AM, Joe Touch wrote: > >> Hi, Andrew, > >> > >> I completely agree; I look forward to a description of the problem. > >> > >> Joe > >> > >> On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote: > >>> Nalini, Joe, > >>> > >>> This two-mail exchange vividly illustrates why it's beneficial to > >>> describe the problem better, and the properties of the ideal = solution > >>> (starting with that of IP ID, but not necessarily limited to it), = but > >>> not jump to solutions themselves straight away. > >>> > >>> Otherwise it's too easy to get into a situation of a fish and a = gull > >>> arguing about the sea water. > >>> > >>> --a > >>> > >>> > >>> On Tue, 5 Feb 2013, Nalini Elkins > wrote: > >>> > >>>> Comparing hashes or packets is not really a workable solution = because > >>>> there can be true duplicate packets. A hash will only show if > >>>> the packets are the same. Unless I am missing something. = Sometimes > >>>> the problem we are trying to diagnose is how many duplicates > >>>> there are. This is an indication of congestion. Some devices = create > >>>> 'false' duplicates. That is a packet trace taken at that > >>>> point will show that the packet is the same but it is only the = device > >>>> or the trace mechanism tracing incorrectly. Believe me, this > >>>> is not an infrequent problem. > >>>> > >>>> Thanks, > >>>> > >>>> Nalini Elkins > >>>> Inside Products, Inc. > >>>> (831) 659-8360 > >>>> www.insidethestack.com > >>>> > >>>> = __________________________________________________________________________= _________________________________________________________________ > >>>> > >>>> > >>>> From: Joe Touch > >>>> To: Nalini Elkins > >>>> Cc: Andrew Yourtchenko ; IETF v6ops list > >>>> > >>>> Sent: Tuesday, February 5, 2013 8:50 AM > >>>> Subject: Re: [v6ops] new draft: > draft-elkins-v6ops-ipv6-ipid-needed > >>>> > >>>> FWIW, there are two obvious solutions that work for both IPv4 and = IPv6: > >>>> > >>>> 1) send fragmented (or fragmentable) packets > >>>> presuming you have control over a source > >>>> > >>>> 2) compare either full packets or hashes of the full packets > >>>> > >>>> "convenience" of an existing field that is not always available = isn't > >>>> a solution. > >>>> > >>>> Joe > >>>> > >>>> > >>>> > >>>> > > > > > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > > > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny = saved is a penny earned--" -- Terry Pratchett From ales.vizdal@t-mobile.cz Wed Feb 6 07:25: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 B16F921F87DC for ; Wed, 6 Feb 2013 07:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umjLPuPL-P4k for ; Wed, 6 Feb 2013 07:25:36 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id F146421F84C2 for ; Wed, 6 Feb 2013 07:25:30 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 9D16628580E; Wed, 6 Feb 2013 16:25:29 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 6 Feb 2013 16:25:29 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Ole Troan , joel jaeggli Date: Wed, 6 Feb 2013 16:26:23 +0100 Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4Eb8Nr/U5lNtqlQV+ieDw2W/n/MwAC20ew Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com><00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net><6.2.5.6.2.20130131141627.0a209458@resistor.net><510AFDC0.5020300@bogus.com><8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com><510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> In-Reply-To: <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 06 Feb 2013 15:25:37 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Ole > Troan > Sent: Wednesday, February 06, 2013 2:42 PM > To: joel jaeggli > Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful a= ndStateless > Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >=20 > I'm fine with publishing this considering the IPR. >=20 > I would much have preferred this to be an informational document though. > as it can hardly be said to be best current practice for how to deliver I= Pv4 service. > - native IPv4 is. > - even in an IPv6 only access network, there are better solutions; e.g. M= AP-E, DS- > lite... There are better solutions, there is no doubt about it, but there are also = scenarios where the encapsulation may be seen as too much of an overhead (e.g. mobile, wher= e there is enough encapsulation/tunnelling overhead already), so translation can be= a better fit. > 464xlat is what's left when the operator (or your host implementation) do= esn't support > anything else. > the smallest common denominator isn't best current practice. I don't think I can agree to it. 464xlat extends NAT64 with the 4-to-6 func= tion on the host, so it can carry IPv4 traffic over NAT64. Again referring to mobile where tu= nnelling would work, but translation less of an overhead from transport point of view.. > cheers, > Ole Cheers, Ales From nalini.elkins@insidethestack.com Wed Feb 6 07:44: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 72DE721F85F3 for ; Wed, 6 Feb 2013 07:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4gAC6G0W80X for ; Wed, 6 Feb 2013 07:44:45 -0800 (PST) Received: from nm5.access.bullet.mail.sp2.yahoo.com (nm5.access.bullet.mail.sp2.yahoo.com [98.139.44.132]) by ietfa.amsl.com (Postfix) with ESMTP id 78C5921F84CE for ; Wed, 6 Feb 2013 07:44:45 -0800 (PST) Received: from [98.139.44.101] by nm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Feb 2013 15:44:40 -0000 Received: from [98.139.44.85] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Feb 2013 15:44:40 -0000 Received: from [127.0.0.1] by omp1022.access.mail.sp2.yahoo.com with NNFMP; 06 Feb 2013 15:44:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 219565.91511.bm@omp1022.access.mail.sp2.yahoo.com Received: (qmail 59365 invoked by uid 60001); 6 Feb 2013 15:44:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360165479; bh=T54P9t6K6WA9qwEg7z9VMhV0QFiuGQDA6gov//1q+no=; 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=aUCzbpJlBSeZJY26ZG+UkjieFvb2DL8UUb4f873820ITUE7ecZ8/jBs7CoEJAo6eWy2dJBUT+Q2P7chvVfm8ICJ/ZI2x8uzQU5V6WMgBn8hweJk5+jpbGIB/cWd4D0Tw3oCX/Y88QYHmIw1cG2B4MwIGyRSWpuiWbfpzI4K+lAY= X-YMail-OSG: SwoDrmYVM1kRmcAvwO47GYtROAPQ9c4Yyf5COSYEnjzG4Tj lmY1ff9AkPPhbZXxSZnlwdYuhd4nLxxfyWH_yM6a6mXjq9tQEoM_QbbQSrCv kUDo3aL.7Ot9t79BZPsfK5VBh5CWRyxOsmLyLKBgnt8QrbKJe_EqNTufCwtW LVk1t6aaRnnnTyL.ZF44HIM51DtYo6SeNJ4ZeFVKDq8gez_Cwi.TUiFu6YO_ oU5_IYCMg7aVp7UjId6PKMWRcOEDlBaqUntO_LLkpUo3SKQinP9RiU5bkbNL stLklU.OTBXHQ0sUH3NtBFNDftwuLEyELg4UIX79NG_qDOIq8riMcqJpfXKA E_amyZX88JGk5L9iHTaT99UJFsCDMg4M6ARZmMlmyp5PAcziqcGI8G4RRNdE rYPcKhW1Q9ya74hvJ2jHQfIpzi99y0.gF69Qtou2I70jT3sCpG40aw_pAlTf gMLQmDlGfwmiyizwbrtCRt3DCccFL7lm7BWmG5Pmwr55tqmRXaHE9wZ07PWX 4EL1467rpTLywEAJMeF.vrXJa9lCvAdz7L3wn46AutWk0YarNIpuntpUkSj. CBLrg41ao3TF8m_5LwtC7XNHIGzCczPH_uZxO3Wlxpadb1Blt5lfe5KxlIST AIDJxz7_pCdukLZSYCZUfkMukfk0x31YetgGz3lIqjhbpVTGvX9j9aWDh3Df EPdkXc3A1M9EX1HZb40OhFpfQvQMtQIfmu9lpcN8hoP4CjR9DQw.XH4yN99U PWS8_OQ5mZ0i5xYva1tOs8Q-- Received: from [71.4.138.3] by web2817.biz.mail.ne1.yahoo.com via HTTP; Wed, 06 Feb 2013 07:44:38 PST X-Rocket-MIMEInfo: 001.001, V2FycmVuLAoKSSB3aWxsIGFuc3dlciBmZXcgb2YgeW91ciBjb21tZW50cyAoaG9wZWZ1bGx5ISkgaW4gYSBtb3JlIHBvc2l0aXZlIHNwaXJpdCB0aGFuIHlvdXJzLgoKMS4gwqBZb3VyIGNvbW1lbnQ6wqBXZSBkaWRuJ3Qgc2VlIHlvdXIgImxhcmdlIGNvcnBvcmF0ZSBjdXN0b21lcnMiIChub3IsIEkgc3VzcGVjdCBkaWQgd2UgcmVhbGx5IHdhbnQgdG8pLMKgCgpNeSBhbnN3ZXI6IMKgUmVhbGx5PyDCoCBXaHkgaW4gdGhlIHdvcmxkIHdvdWxkIHlvdSBub3Qgd2FudCB0bz8gwqAgV2hhdCB3b3VsZCBtYWtlIHkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1360094003.76755.YahooMailNeo@web2811.biz.mail.ne1.yahoo.com> Message-ID: <1360165478.32768.YahooMailNeo@web2817.biz.mail.ne1.yahoo.com> Date: Wed, 6 Feb 2013 07:44:38 -0800 (PST) From: Nalini Elkins To: Warren Kumari In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="186841555-1420596130-1360165478=:32768" Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 15:44:47 -0000 --186841555-1420596130-1360165478=:32768 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Warren,=0A=0AI will answer few of your comments (hopefully!) in a more posi= tive spirit than yours.=0A=0A1. =C2=A0Your comment:=C2=A0We didn't see your= "large corporate customers" (nor, I suspect did we really want to),=C2=A0= =0A=0AMy answer: =C2=A0Really? =C2=A0 Why in the world would you not want t= o? =C2=A0 What would make you say something like that? =C2=A0I was under th= e impression that the IETF was open to everyone with concerns. =C2=A0BTW, t= here are two large corporate customers who have actually co-authored the RF= C - Blue Cross Blue Shield of Michigan and US Bank. =C2=A0 The other co-aut= hor is IBM. =C2=A0You may have heard of them. =C2=A0 I wonder why you think= they participated in this effort.=0A=0A2. =C2=A0 I investigated doing a ha= sh on the packets and it will not work. =C2=A0It only indicates if there ar= e duplicate packets. =C2=A0At least one problem with that is that I have ru= n into middleware which creates duplicate packets in traces which are reall= y not on the wire. =C2=A0I believe we discussed why hashing would not work = in the RFC that we submitted.=0A=0A3. =C2=A0Netflow, ACLs, logs, etc are al= l often quite impossible to do because we do not necessarily own the networ= k end to end or it may be a network where a business partner is involved.= =0A=0A3. =C2=A0I suspect that the troubleshooting the operators at the IETF= perform is possibly not end-to-end. =C2=A0So, they may not have run into t= he problems that we have.=0A=0A4. =C2=A0 A better statement of the problem = is actually a good idea and you may want to look the positive approach take= n by Andrew Y.=0A=0Ahttps://docs.google.com/document/d/1TnONzdbicxwktuFzfjs= ZADdFSSNghK0GBzvPKAFneOc/edit?usp=3Dsharing=0A=0A=0AWe will be updating the= above document with our thoughts.=0A=0ATo end with, please do me the court= esy of thinking that I am not merely trying to market my products. =C2=A0 I= believe there are other venues that would be more cost effective than the = email list of the IETF. =C2=A0=C2=A0=0A=0A=C2=A0=0AThanks,=0A=0A=0ANalini E= lkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A= =0A=0A=0A________________________________=0A From: Warren Kumari =0ATo: Nalini Elkins =0ACc: War= ren Kumari ; Mark Smith ; Joe= Touch ; Andrew Yourtchenko ; IETF v6ops= list =0ASent: Wednesday, February 6, 2013 6:44 AM=0ASubje= ct: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A =0A=0AOn = Feb 5, 2013, at 2:53 PM, Nalini Elkins w= rote:=0A=0A> Mark,=0A> =0A> Tools are a different topic.=C2=A0 A number of= companies, including mine, have intelligent packet analyzers.=C2=A0 =0A=0A= I believe you sell packet analyzers, no? (The word "have" in the above made= it sound like you purchased / own a packet analyzer from someone else).=0A= =0A> For us, there is nothing our products like better than thousands of pa= ckets that we can read in and then help the customer to pinpoint problems t= o the exact packet.=C2=A0 This is the trend of the future.=0A=0AAhhhh! The = trend of the future. Well, that's all alright then=E2=80=A6.=0A=0A=0A>=C2= =A0 The volume of data and packets soon outpaces what we mere humans can do= .=C2=A0 We need a partnership between intelligent tools and intelligent hum= ans.=0A> =0A=0AOh dear=E2=80=A6=C2=A0 "volume of data and packets soon outp= aces what we mere humans can do".=C2=A0 That's worrying, because up till no= w I've been picking bits off the wire with an oscilloscope, scribbling them= down on a piece of paper *really quickly*, converting the bits to hex in m= y head and then reassembling the packets and streams=E2=80=A6 Sometimes cal= culating the checksum on my fingers is tricky, but I usually get it right t= he second or third time. Oh, and don't even get me started on trying to do = this with VoIP or video -- the codec designers really should take into acco= unt how hard decoding is for a human=E2=80=A6=0A=0A=0A> I would actually lo= ve to have a discussion at some point on best practices in troubleshooting.= =C2=A0 =0A=0ASo=E2=80=A6.=0A=0AThe last time this came up (around August 20= 11 in the "draft-elkins-6man-ipv6-diagnostic-header" thread, part of which = is here: http://www.ietf.org/mail-archive/web/v6ops/current/msg10275.html) = a number of operators who actually *do* troubleshooting provided a number o= f ideas.=0A=0AAFACT / AFAIR, none of them said that they use IPID in v4 ver= y often at all. They did provide a number of their troubleshooting techniqu= es for these sorts of issues...=0A=0ASome snippets from that thread:=0AFrom= yourself in http://www.ietf.org/mail-archive/web/v6ops/current/msg10260.ht= ml:=0A"I am working on contacting a number of our large corporate customers= to weigh in on this topic.=C2=A0 I think that the biggest issue here is th= at when a large commercial network is having problems, anything that can he= lp speed diagnostics is worth doing. Outages and poor performance can cost = a great deal of money.=C2=A0 =0A=0ASituations such as comparing packets at = various points on the network to determine packet loss is a necessary part = of network problem determination.=C2=A0 I am working to get the technicians= from the corporations themselves to get onto this email list and tell thei= r opinions themselves."=0A=0AWe didn't see your "large corporate customers"= (nor, I suspect did we really want to), but we did have a number of folk p= resent a bunch of ideas (many of them operators who perform troubleshooting= on large networks on a daily basis)=0A=0AFor example, Carlos suggested (ht= tp://www.ietf.org/mail-archive/web/v6ops/current/msg10266.html):=0A"To comp= are packets, we could potentially have the=0Anetwork protocol analyzer (e.g= ., Wireshark) compute a hash on invariant=0Afields of the packet (i.e., exc= lude Hop Limit, etc), and present that as=0Apacket metadata that is not act= ually carried on the wire."=0A=0Ayou replied:=0A"Well, that is a really goo= d idea that we had explored also.=C2=A0 Now, we ourselves make an intellige= nt packet analyzer and work with the WireShark folks.=C2=A0 If I look at th= is selfishly for having an extra selling point for my products, then I can = say, 'Yes, we allow you to do this!=C2=A0 Buy my product!'=C2=A0 But, I was= trying to be a good citizen and allow all to do this without our products.= =C2=A0 Now, if our proposal is not adopted, then we will do the checksum or= hash on the packets in our products as I think it is needed for diagnostic= s. "=0A=0ADid you implement this? (I'd like to note that this exact same su= ggestion came up in this thread).=0A=0AShane Amante suggested (in http://ww= w.ietf.org/mail-archive/web/v6ops/current/msg10270.html =0A"Have you taken = a look at flow-spec for IPv4:=0Ahttp://tools.ietf.org/html/rfc5575=0A=0A...= and, flow-spec for IPv6:=0Ahttp://tools.ietf.org/html/draft-ietf-idr-flow-= spec-v6-00=0A=0A(Both the RFC and I-D are within the IDR WG).=0A=0AIn summa= ry, using flow-spec one can define an ACL that then get distributed across = all routers within an ASN, via BGP, that can then be used to count matching= packets, log packet header information, etc.=C2=A0 It's up to the operator= to decide what ACL to be applied and what 'action' (logging, counting, etc= .) to be taken for packets that match a given 'rule'.=C2=A0 =0A=0AFrom wher= e I'm sitting, this seems like it might already solve the problem you're ha= ving, without having to invent a wholly new IPv6 Destination Header Option.= =C2=A0 So, I would like to know if you have taken a look at flow-spec and, = if so, why it was ruled out?"=0A=0Aand then answered a bunch of your questi= ons (from which it seemed you hadn't read the references he sent). =0AShane= also suggested sFlow / NetFlow / IPFIX and ACLs with RSPAN.=0A=0ADid you i= nvestigate / implement these? I don't see a flow collector / span endpoint = lester in your products...=0A=0A=0A=0AAs was said in the previous go-round = on this, and in this thread, it is unclear what exactly the problem stateme= nt is. =0AApart from feeling very markety[0], much of this sounds like "If = all you have is a hammer, everything looks like a nail".=0A=0AA simple, cle= ar, concise description of *what* problem you are trying to solve (without = any references to how much time you have saved using IPID, how it is the mo= st wonderful, awesomest thing ever, etc) would help a bunch...=0A=0AW=0A=0A= [0]: Which might be causing much of my grumpiness in this response...=0A=0A= =0A> Our ultimate goal is to have the right performance and troubleshooting= metrix built right into the protocols from the get-go!=0A>=C2=A0 =0A> Than= ks,=0A> =0A> Nalini Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A>= www.insidethestack.com=0A> =0A> From: Mark Smith =0A> To: Nalini Elkins ; Joe Touch ; Andrew Yourtchenko =0A> Cc: IETF v6ops li= st =0A> Sent: Tuesday, February 5, 2013 11:42 AM=0A> Subje= ct: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A> =0A= > =0A> =0A> =0A> =0A> >________________________________=0A> > From: Nalini = Elkins =0A> >To: Joe Touch ; Andrew Yourtchenko =0A> >Cc: IETF v6ops list =0A> >Sent: Wednesday, 6 February 2013 6:28 AM=0A> >Subject: Re:= [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> > =0A> >=0A> >J= oe,=0A> >=0A> >=0A> >Well, duplicate packets are often retransmissions. =0A= > >=0A> >=0A> =0A> This can be quite easily determined by comparing sent pa= cket counts at one end with received packet counts at the other. I'd consid= er doing that to be much easier than capturing 1000s of packets and then lo= oking through them with an analyser to try to spot duplicate packets. I con= sider using a packet analyser to be a last resort when troubleshooting beca= use you're usually dealing with 1000s, 10 000s or 100 000s of packets, and = trying to spot a trend or pick the bad individual packet. It can also be qu= ite onerous to setup the packet capture and the volume of data can huge.=0A= > =0A> Some of these examples are starting sound like you've been taking th= e approach of "how can we use IPID to troubleshoot this" rather than "what = is the most effective tool to troubleshoot this", of which IPID might be on= e for a particular situation. =0A> =0A> >=0A> >=0A> >=C2=A0 If you have ret= ransmissions, then the other end (or the network) is not absorbing the flow= properly.=C2=A0 Then, on our end, we need to see if we have allocated enou= gh bandwidth, it is going over a sub-optimal route, etc.=0A> > =0A> >Thanks= ,=0A> >=0A> >=0A> >Nalini Elkins=0A> >Inside Products, Inc.=0A> >(831) 659-= 8360=0A> >www.insidethestack.com=0A> >=0A> >=0A> >=0A> >___________________= _____________=0A> > From: Joe Touch =0A> >To: Andrew Yourtch= enko =0A> >Cc: Nalini Elkins ; IETF v6ops list =0A> >Sent: Tuesday, February 5= , 2013 10:25 AM=0A> >Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv= 6-ipid-needed=0A> > =0A> >PS - I'm particularly interested in an explanatio= n of why duplicate =0A> >packets would be an indication of congestion, FWIW= .=0A> >=0A> >Joe=0A> >=0A> >On 2/5/2013 10:20 AM, Joe Touch wrote:=0A> >> H= i, Andrew,=0A> >>=0A> >> I completely agree; I look forward to a descriptio= n of the problem.=0A> >>=0A> >> Joe=0A> >>=0A> >> On 2/5/2013 9:22 AM, Andr= ew Yourtchenko wrote:=0A> >>> Nalini, Joe,=0A> >>>=0A> >>> This two-mail ex= change vividly illustrates why it's beneficial to=0A> >>> describe the prob= lem better, and the properties of the ideal solution=0A> >>> (starting with= that of IP ID, but not necessarily limited to it), but=0A> >>> not jump to= solutions themselves straight away.=0A> >>>=0A> >>> Otherwise it's too eas= y to get into a situation of a fish and a gull=0A> >>> arguing about the se= a water.=0A> >>>=0A> >>> --a=0A> >>>=0A> >>>=0A> >>> On Tue, 5 Feb 2013, Na= lini Elkins=0A> wrote:=0A> >>>=0A> >>>> Comparing hashes or packets is not = really a workable solution because=0A> >>>> there can be true duplicate pac= kets.=C2=A0 A hash will only show if=0A> >>>> the packets are the same.=C2= =A0 Unless I am missing something.=C2=A0 Sometimes=0A> >>>> the problem w= e are trying to diagnose is how many duplicates=0A> >>>> there are.=C2=A0 T= his is an indication of congestion.=C2=A0 Some devices create=0A> >>>> 'fa= lse' duplicates.=C2=A0 That is a packet trace taken at that=0A> >>>> point = will show that the packet is the same but it is only the device=0A> >>>> or= the trace mechanism tracing incorrectly.=C2=A0 Believe me, this=0A> >>>> i= s not an infrequent problem.=0A> >>>>=0A> >>>> Thanks,=0A> >>>>=0A> >>>> Na= lini Elkins=0A> >>>> Inside Products, Inc.=0A> >>>> (831) 659-8360=0A> >>>>= www.insidethestack.com=0A> >>>>=0A> >>>> _________________________________= ___________________________________________________________________________= _______________________________=0A> >>>>=0A> >>>>=0A> >>>> From: Joe Touch = =0A> >>>> To: Nalini Elkins =0A> >>>> Cc: Andrew Yourtchenko ; IETF v6ops list=0A= > >>>> =0A> >>>> Sent: Tuesday, February 5, 2013 8:50 AM=0A= > >>>> Subject: Re: [v6ops] new draft:=0A> draft-elkins-v6ops-ipv6-ipid-nee= ded=0A> >>>>=0A> >>>> FWIW, there are two obvious solutions that work for b= oth IPv4 and IPv6:=0A> >>>>=0A> >>>> 1) send fragmented (or fragmentable) p= ackets=0A> >>>>=C2=A0 =C2=A0 presuming you have control over a source=0A> = >>>>=0A> >>>> 2) compare either full packets or hashes of the full packets= =0A> >>>>=0A> >>>> "convenience" of an existing field that is not always av= ailable isn't=0A> >>>> a solution.=0A> >>>>=0A> >>>> Joe=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> >=0A> >=0A> =0A> =0A> __________= _____________________________________=0A> v6ops mailing list=0A> v6ops@ietf= .org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A=0A--=0A"Have you go= t any previous convictions?"=0A=0A"Well, I dunno... I suppose I used to bel= ieve very firmly that a penny saved is a penny earned--"=0A-- Terry Pratche= tt --186841555-1420596130-1360165478=:32768 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Warren,

= I will answer few of your co= mments (hopefully!) in a more positive spirit than yours.

1.  Your comment: We didn't see your "large corporat= e customers" (nor, I suspect did we really want to), 

<= div style=3D"color: rgb(69, 69, 69); font-size: 12.222222328186035px; font-= family: Helvetica, Arial, sans-serif; background-color: transparent; font-s= tyle: normal;">My answer: &n= bsp;Really?   Why in the world would you not want to?   What woul= d make you say something like that?  I was under the impression that t= he IETF was open to everyone with concerns.  BTW, there are two large = corporate customers who have actually co-authored the RFC - Blue Cross Blue= Shield of Michigan and US Bank.   The other co-author is IBM.  Y= ou may have heard of them.   I wonder why you think they participated = in this effort.

2.   I investigated do= ing a hash on the packets and it will not work.  It only indicates if = there are duplicate packets.  At least one problem with that is that I= have run into middleware which creates duplicate packets in traces which a= re really not on the wire.  I believe we discussed why hashing would n= ot work in the RFC that we submitted.

3.  Netflow, ACLs, logs, etc are all often quite impossible to do because we do not necessarily own the network end to end or it may b= e a network where a business partner is involved.

=
3.  I suspect that the troubleshooting the opera= tors at the IETF perform is possibly not end-to-end.  So, they may not= have run into the problems that we have.

4.   A better statement of the problem is actual= ly a good idea and you may want to look the positive approach taken by Andr= ew Y.


We will be updating the above document with our thoughts.
=

To end with, please do me the cou= rtesy of thinking that I am not merely trying to market my products.  = I believe there are other venues that would be more cost effective than th= e email list of the IETF.   

 
Thanks,

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

From: Warren Kumari <warren@kumari.net>
To: Nalini Elkins <nalini.elkins@insidethest= ack.com>
Cc: Warren= Kumari <warren@kumari.net>; Mark Smith <markzzzsmith@yahoo.com.au= >; Joe Touch <touch@isi.edu>; Andrew Yourtchenko <ayourtch@cisc= o.com>; IETF v6ops list <v6ops@ietf.org>
Sent: Wednesday, February 6, 2013 6:44 AM
= Subject: Re: [v6ops] new draft: dr= aft-elkins-v6ops-ipv6-ipid-needed


On Feb 5, 2013= , at 2:53 PM, Nalini Elkins <nalini.elkins@= insidethestack.com> wrote:

> Mark,
>
> Tools = are a different topic.  A number of companies, including mine, have i= ntelligent packet analyzers. 

I believe you sell packet analyz= ers, no? (The word "have" in the above made it sound like you purchased / o= wn a packet analyzer from someone else).

> For us, there is nothi= ng our products like better than thousands of packets that we can read in a= nd then help the customer to pinpoint problems to the exact packet.  T= his is the trend of the future.

Ahhhh! The trend of the future. Well= , that's all alright then=E2=80=A6.


>  The volume of dat= a and packets soon outpaces what we mere humans can do.  We need a partners= hip between intelligent tools and intelligent humans.
>

Oh de= ar=E2=80=A6  "volume of data and packets soon outpaces what we mere hu= mans can do".  That's worrying, because up till now I've been picking = bits off the wire with an oscilloscope, scribbling them down on a piece of = paper *really quickly*, converting the bits to hex in my head and then reas= sembling the packets and streams=E2=80=A6 Sometimes calculating the checksu= m on my fingers is tricky, but I usually get it right the second or third t= ime. Oh, and don't even get me started on trying to do this with VoIP or vi= deo -- the codec designers really should take into account how hard decodin= g is for a human=E2=80=A6


> I would actually love to have a d= iscussion at some point on best practices in troubleshooting. 
So=E2=80=A6.

The last time this came up (around August 2011 in the "draft-elkins-6man-ipv6-diagnostic-header" thread, part of which is here: = http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 0275.html) a number of operators who actually *do* troubleshooting prov= ided a number of ideas.

AFACT / AFAIR, none of them said that they u= se IPID in v4 very often at all. They did provide a number of their trouble= shooting techniques for these sorts of issues...

Some snippets from = that thread:
From yourself in http://www.ietf.org/ma= il-archive/web/v6ops/current/msg10260.html:
"I am working on contact= ing a number of our large corporate customers to weigh in on this topic.&nb= sp; I think that the biggest issue here is that when a large commercial net= work is having problems, anything that can help speed diagnostics is worth doing. Outages and poor performance can cost a great deal of money.  =

Situations such as comparing packets at various points on the netwo= rk to determine packet loss is a necessary part of network problem determin= ation.  I am working to get the technicians from the corporations them= selves to get onto this email list and tell their opinions themselves."
=
We didn't see your "large corporate customers" (nor, I suspect did we r= eally want to), but we did have a number of folk present a bunch of ideas (= many of them operators who perform troubleshooting on large networks on a d= aily basis)

For example, Carlos suggested (http:= //www.ietf.org/mail-archive/web/v6ops/current/msg10266.html):
"To co= mpare packets, we could potentially have the
network protocol analyzer (= e.g., Wireshark) compute a hash on invariant
fields of the packet (i.e., exclude Hop Limit, etc), and present that as
packet metadata tha= t is not actually carried on the wire."

you replied:
"Well, that = is a really good idea that we had explored also.  Now, we ourselves ma= ke an intelligent packet analyzer and work with the WireShark folks.  = If I look at this selfishly for having an extra selling point for my produc= ts, then I can say, 'Yes, we allow you to do this!  Buy my product!'&n= bsp; But, I was trying to be a good citizen and allow all to do this withou= t our products.  Now, if our proposal is not adopted, then we will do = the checksum or hash on the packets in our products as I think it is needed= for diagnostics. "

Did you implement this? (I'd like to note that t= his exact same suggestion came up in this thread).

Shane Amante sugg= ested (in http://www.ietf.org/mail-archive/web/v6ops/current/msg10= 270.html
"Have you taken a look at flow-spec for IPv4:
http://tools.ietf= .org/html/rfc5575

... and, flow-spec for IPv6:
h= ttp://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00

(Both t= he RFC and I-D are within the IDR WG).

In summary, using flow-spec o= ne can define an ACL that then get distributed across all routers within an= ASN, via BGP, that can then be used to count matching packets, log packet = header information, etc.  It's up to the operator to decide what ACL t= o be applied and what 'action' (logging, counting, etc.) to be taken for pa= ckets that match a given 'rule'. 

From where I'm sitting, this= seems like it might already solve the problem you're having, without havin= g to invent a wholly new IPv6 Destination Header Option.  So, I would like= to know if you have taken a look at flow-spec and, if so, why it was ruled= out?"

and then answered a bunch of your questions (from which it se= emed you hadn't read the references he sent).
Shane also suggested sFlo= w / NetFlow / IPFIX and ACLs with RSPAN.

Did you investigate / imple= ment these? I don't see a flow collector / span endpoint lester in your pro= ducts...



As was said in the previous go-round on this, and i= n this thread, it is unclear what exactly the problem statement is.
Apa= rt from feeling very markety[0], much of this sounds like "If all you have = is a hammer, everything looks like a nail".

A simple, clear, concise= description of *what* problem you are trying to solve (without any referen= ces to how much time you have saved using IPID, how it is the most wonderfu= l, awesomest thing ever, etc) would help a bunch...

W

[0]: Which might be causing much of my grumpiness= in this response...


> Our ultimate goal is to have the right= performance and troubleshooting metrix built right into the protocols from= the get-go!
> 
> Thanks,
>
> Nalini Elkins<= br>> Inside Products, Inc.
> (831) 659-8360
> www.insidethes= tack.com
>
> From: Mark Smith <markzzzsmith@= yahoo.com.au>
> To: Nalini Elkins <nalini.elkins@insidethestack.com>; Joe Touch <touch@isi.edu>; = Andrew Yourtchenko <ayourtch@cisco.com>
> Cc: IETF v6ops = list <v6= ops@ietf.org>
> Sent: Tuesday, February 5, 2013 11:42 AM
&= gt; Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
= >
>
>
>
>
>
> >____________= ____________________
> > From: Nalini Elkins <nalini.elkins@insidethestack.com>
> >To: Joe To= uch <t= ouch@isi.edu>; Andrew Yourtchenko <ayourtch@cisco.com> > >Cc: IETF v6ops list <v6ops@ietf.org>
> >Sent: Wedne= sday, 6 February 2013 6:28 AM
> >Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed
> >
> >
> >= ;Joe,
> >
> >
> >Well, duplicate packets are oft= en retransmissions.
> >
> >
>
> This can be= quite easily determined by comparing sent packet counts at one end with re= ceived packet counts at the other. I'd consider doing that to be much easie= r than capturing 1000s of packets and then looking through them with an ana= lyser to try to spot duplicate packets. I consider using a packet analyser = to be a last resort when troubleshooting because you're usually dealing wit= h 1000s, 10 000s or 100 000s of packets, and trying to spot a trend or pick= the bad individual packet. It can also be quite onerous to setup the packe= t capture and the volume of data can huge.
>
> Some of these e= xamples are starting sound like you've been taking the approach of "how can= we use IPID to troubleshoot this" rather than "what is the most effective tool to troubleshoot this", of which IPID might be one for a par= ticular situation.
>
> >
> >
> >  I= f you have retransmissions, then the other end (or the network) is not abso= rbing the flow properly.  Then, on our end, we need to see if we have = allocated enough bandwidth, it is going over a sub-optimal route, etc.
&= gt; >
> >Thanks,
> >
> >
> >Nalini = Elkins
> >Inside Products, Inc.
> >(831) 659-8360
>= >www.insidethestack.com
> >
> >
> >
> = >________________________________
> > From: Joe Touch <touch@isi.edu<= /a>>
> >To: Andrew Yourtchenko <ayourtch@cisco.com> =
> >Cc: Nalini Elkins <nalini.elkins@insidethestack.com>; IETF v= 6ops list <v6ops@ietf.org>
> >Sent: Tuesday, February 5, 2013 = 10:25 AM
> >Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv= 6-ipid-needed
> >
> >PS - I'm particularly interested in= an explanation of why duplicate
> >packets would be an indicatio= n of congestion, FWIW.
> >
> >Joe
> >
> &g= t;On 2/5/2013 10:20 AM, Joe Touch wrote:
> >> Hi, Andrew,
&g= t; >>
> >> I completely agree; I look forward to a descri= ption of the problem.
> >>
> >> Joe
> >>= ;
> >> On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote:
> &= gt;>> Nalini, Joe,
> >>>
> >>> This two-mail exchange vividly illustrates why it's beneficial to
> >&= gt;> describe the problem better, and the properties of the ideal soluti= on
> >>> (starting with that of IP ID, but not necessarily l= imited to it), but
> >>> not jump to solutions themselves st= raight away.
> >>>
> >>> Otherwise it's too e= asy to get into a situation of a fish and a gull
> >>> argui= ng about the sea water.
> >>>
> >>> --a
&g= t; >>>
> >>>
> >>> On Tue, 5 Feb 201= 3, Nalini Elkins
> wrote:
> >>>
> >>>&g= t; Comparing hashes or packets is not really a workable solution because> >>>> there can be true duplicate packets.  A hash wi= ll only show if
> >>>> the packets are the same.  U= nless I am missing something.  Sometimes
> >>>> the problem we are trying to diagnose is how many duplica= tes
> >>>> there are.  This is an indication of cong= estion.  Some devices create
> >>>> 'false' duplica= tes.  That is a packet trace taken at that
> >>>> po= int will show that the packet is the same but it is only the device
>= >>>> or the trace mechanism tracing incorrectly.  Believe= me, this
> >>>> is not an infrequent problem.
> &g= t;>>>
> >>>> Thanks,
> >>>>> >>>> Nalini Elkins
> >>>> Inside Produc= ts, Inc.
> >>>> (831) 659-8360
> >>>> w= ww.insidethestack.com
> >>>>
> >>>> __________________________________________________________________________= _________________________________________________________________
> &= gt;>>>
> >>>>
> >>>> From: Joe= Touch <touch@isi.edu>
> >>>> To: Nalini Elkins <nalini.elkins@insidethestack.com>
> &= gt;>>> Cc: Andrew Yourtchenko <ayourtch@cisco.com>; IET= F v6ops list
> >>>> <v6ops@ietf.org>
> >>&= gt;> Sent: Tuesday, February 5, 2013 8:50 AM
> >>>> Su= bject: Re: [v6ops] new draft:
> draft-elkins-v6ops-ipv6-ipid-needed> >>>>
> >>>> FWIW, there are two obvious solu= tions that work for both IPv4 and IPv6:
> >>>>
> &g= t;>>> 1) send fragmented (or fragmentable) packets
> >>= ;>>    presuming you have control over a source
> &g= t;>>>
> >>>> 2) compare either full packets or h= ashes of the full packets
> >>>>
> >>>>= "convenience" of an existing field that is not always available isn't
&= gt; >>>> a solution.
> >>>>
> >>&= gt;> Joe
> >>>>
> >>>>
> >&= gt;>>
> >>>>
> >
> >
> >=
> >_______________________________________________
> >v6= ops mailing list
> >v6ops@ietf.org
> >htt= ps://www.ietf.org/mailman/listinfo/v6ops
> >
> >
&= gt; >
>
>
> ________________________________________= _______
> v6ops mailing list
> v6ops@ietf.org
> https://www.i= etf.org/mailman/listinfo/v6ops

--
"Have you got any previous = convictions?"

"Well, I dunno... I suppose I used to believe very fir= mly that a penny saved is a penny earned--"
-- Terry Pratchett




--186841555-1420596130-1360165478=:32768-- From rajiva@cisco.com Wed Feb 6 07:48: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 44C5321F87E1 for ; Wed, 6 Feb 2013 07:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.243 X-Spam-Level: X-Spam-Status: No, score=-9.243 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3xPas1Yr8Nf for ; Wed, 6 Feb 2013 07:48:10 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 19BF621F85F3 for ; Wed, 6 Feb 2013 07:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2551; q=dns/txt; s=iport; t=1360165690; x=1361375290; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EOzVOUSleatH3ot6o27dhbKksvaOn0QD5yEHzMiR97U=; b=L+jYFo4CkHQN+HCpelQA4F3lT3Eowa8WIbGgHXZb4bBU38y0oDjrLHe0 Xi/TpSG1kPFruumrXene5T8VYMg2keVczv57a0btJtPQtoM8DjrcxOhgB W6zHo6kjFTltX+IFA7NEP18TaDJCdDElHPdkPBMINlZfYMwpDVa3qkTU6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADV6ElGtJXG//2dsb2JhbABFwEYWc4IfAQEBBAEBAWsLDAYBCBEDAQEBCxkELgsUCQgCBAENBQgTh3YMvDAEgk2OLWEDpnOCfoIk X-IronPort-AV: E=Sophos;i="4.84,616,1355097600"; d="scan'208";a="174055776" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 06 Feb 2013 15:48:09 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r16Fm9Su020957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Feb 2013 15:48:09 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 09:48:09 -0600 From: "Rajiv Asati (rajiva)" To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= , Ole Troan , joel jaeggli Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBIFcg7Qzvwn0bkCMyeeF78VjuQ== Date: Wed, 6 Feb 2013 15:48:09 +0000 Message-ID: In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.82.232.75] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 06 Feb 2013 15:48:14 -0000 I agree with Ales to translation being better in mobile environment. Overall, I do think that if 464XLAT were to be "informational", then we would be better off. Also, let's not forget that there is MAP-T as well - all about translation. :-) The challenge in all of this is that the UE needs to be mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE dependency.=20 Cheers, Rajiv -----Original Message----- From: V=EDzdal Ale=B9 Date: Wednesday, February 6, 2013 10:26 AM To: Ole Troan , Joel jaeggli Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>Of Ole >> Troan >> Sent: Wednesday, February 06, 2013 2:42 PM >> To: joel jaeggli >> Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org >> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful >>andStateless >> Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >>=20 >> I'm fine with publishing this considering the IPR. >>=20 >> I would much have preferred this to be an informational document though. >> as it can hardly be said to be best current practice for how to deliver >>IPv4 service. >> - native IPv4 is. >> - even in an IPv6 only access network, there are better solutions; e.g. >>MAP-E, DS- >> lite... > >There are better solutions, there is no doubt about it, but there are >also scenarios where >the encapsulation may be seen as too much of an overhead (e.g. mobile, >where there >is enough encapsulation/tunnelling overhead already), so translation can >be a better >fit. > >> 464xlat is what's left when the operator (or your host implementation) >>doesn't support >> anything else. >> the smallest common denominator isn't best current practice. > >I don't think I can agree to it. 464xlat extends NAT64 with the 4-to-6 >function on the host, >so it can carry IPv4 traffic over NAT64. Again referring to mobile where >tunnelling would >work, but translation less of an overhead from transport point of view.. > >> cheers, >> Ole > >Cheers, >Ales >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From mackermann@bcbsm.com Wed Feb 6 08:11: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 7430321F854A for ; Wed, 6 Feb 2013 08:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1rRi2dwHdyr for ; Wed, 6 Feb 2013 08:11:37 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC521F8552 for ; Wed, 6 Feb 2013 08:11:35 -0800 (PST) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 91E6817E368 for ; Wed, 6 Feb 2013 10:11:34 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 24CED17E3DB; Wed, 6 Feb 2013 10:11:33 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 89B332F0050; Wed, 6 Feb 2013 11:10:00 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id 795922F004F; Wed, 6 Feb 2013 11:10:00 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Wed, 6 Feb 2013 11:11:32 -0500 From: "Ackermann, Michael" To: Nalini Elkins , Warren Kumari Thread-Topic: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed Thread-Index: AQHOAUuM1HW/honYFEqflvqFkL2wsZhnE/yA//+vKCCAAbRXgIAByViA//+6i8CAATMIAIAABu4AgAA61oCAAFrmgIAACBsAgAABfgCAAAdIAIAAEGAAgAABJQCAABHcgIAAA8CAgAADEYCAATv3AIAAEN4A//+x+zA= Date: Wed, 6 Feb 2013 16:11:31 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A0E7F17@PWN401EA160.ent.corp.bcbsm.com> References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1360094003.76755.YahooMailNeo@web2811.biz.mail.ne1.yahoo.com> <1360165478.32768.YahooMailNeo@web2817.biz.mail.ne1.yahoo.com> In-Reply-To: <1360165478.32768.YahooMailNeo@web2817.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A0E7F17PWN401EA160entc_" MIME-Version: 1.0 Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 16:11:39 -0000 --_000_4FC37E442D05A748896589E468752CAA0A0E7F17PWN401EA160entc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHdvICBxdWljayByZWFjdGlvbnMgIHRvIHRoZSBkaXNjb3Vyc2VzIGJlbG93Og0KDQojMywg IFRoZXNlIHdvdWxkIGFwcGVhciB0byBiZSBwcm9wcmlldGFyeSBzb2x1dGlvbnMuICAgQXMg YSBjdXN0b21lciBJIHdvdWxkIHByZWZlciB0byBOT1QgZGVwZW5kIG9uIGFueXRoaW5nIHBy b3ByaWV0YXJ5IGlmIHBvc3NpYmxlIGFuZCB3b3VsZCBncmVhdGx5IHByZWZlciAgU3RhbmRh cmQgc29sdXRpb25zICBpbnRlbmRlZCB0byB3b3JrIG9uIGFsbCBwbGF0Zm9ybXMgYW5kIHNp dHVhdGlvbnMuDQoNClJlZ2FyZHMgdG8gdGhpcyBiZWluZyBhbiBlZmZvcnQgZm9yIE5hbGlu aSB0byBtYXJrZXQgaGVyIHByb2R1Y3RzLiAgIEkgbWF5IGJlIHRlcnJpYmx5IGNvbmZ1c2Vk LCBidXQgSSB3b3VsZCB0aGluayBqdXN0IHRoZSBvcHBvc2l0ZS4gICBBcyBhIGN1c3RvbWVy LCBpZiBJIGJlZ2luIHRvIGxvc2UgdHJpZWQgYW5kIHRydWUgZmFjaWxpdGllcyBzdWNoIGFz IElQSUQsIHdoaWNoIGhhdmUgYmVlbiBpbnN0cnVtZW50YWwgaW4gc29sdmluZyBzb21lIG9m IG91ciBtb3JlIGNvbXBsZXggc2l0dWF0aW9ucywgdGhlbiBJIHdvdWxkIHNlZSBteXNlbGYg YmVjb21pbmcgbW9yZSBkZXBlbmRhbnQgYW5kIHJlbGlhbnQgb24gcHJvZHVjdHMgc3VjaCBh cyBOYWxpbmnigJlzIENvbXBhbnkgbWFya2V0cy4gICAgSSB2aWV3IGhlciBhY3Rpb25zL2lu dm9sdmVtZW50IGFzIHdoYXQgc2hvdWxkIGJlIGJlc3QgZm9yIGVuZCB1c2VycyBhbmQgbmV0 d29ya3MgaW4gZ2VuZXJhbC4NCg0KVGhhbmtzLA0KDQpNaWtlDQoNCg0KDQpGcm9tOiB2Nm9w cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE5hbGluaSBFbGtpbnMNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDYs IDIwMTMgMTA6NDUgQU0NClRvOiBXYXJyZW4gS3VtYXJpDQpDYzogSUVURiB2Nm9wcyBsaXN0 DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWVsa2lucy12Nm9wcy1p cHY2LWlwaWQtbmVlZGVkDQoNCldhcnJlbiwNCg0KSSB3aWxsIGFuc3dlciBmZXcgb2YgeW91 ciBjb21tZW50cyAoaG9wZWZ1bGx5ISkgaW4gYSBtb3JlIHBvc2l0aXZlIHNwaXJpdCB0aGFu IHlvdXJzLg0KDQoxLiAgWW91ciBjb21tZW50OiBXZSBkaWRuJ3Qgc2VlIHlvdXIgImxhcmdl IGNvcnBvcmF0ZSBjdXN0b21lcnMiIChub3IsIEkgc3VzcGVjdCBkaWQgd2UgcmVhbGx5IHdh bnQgdG8pLA0KDQpNeSBhbnN3ZXI6ICBSZWFsbHk/ICAgV2h5IGluIHRoZSB3b3JsZCB3b3Vs ZCB5b3Ugbm90IHdhbnQgdG8/ICAgV2hhdCB3b3VsZCBtYWtlIHlvdSBzYXkgc29tZXRoaW5n IGxpa2UgdGhhdD8gIEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIElFVEYg d2FzIG9wZW4gdG8gZXZlcnlvbmUgd2l0aCBjb25jZXJucy4gIEJUVywgdGhlcmUgYXJlIHR3 byBsYXJnZSBjb3Jwb3JhdGUgY3VzdG9tZXJzIHdobyBoYXZlIGFjdHVhbGx5IGNvLWF1dGhv cmVkIHRoZSBSRkMgLSBCbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBV UyBCYW5rLiAgIFRoZSBvdGhlciBjby1hdXRob3IgaXMgSUJNLiAgWW91IG1heSBoYXZlIGhl YXJkIG9mIHRoZW0uICAgSSB3b25kZXIgd2h5IHlvdSB0aGluayB0aGV5IHBhcnRpY2lwYXRl ZCBpbiB0aGlzIGVmZm9ydC4NCg0KMi4gICBJIGludmVzdGlnYXRlZCBkb2luZyBhIGhhc2gg b24gdGhlIHBhY2tldHMgYW5kIGl0IHdpbGwgbm90IHdvcmsuICBJdCBvbmx5IGluZGljYXRl cyBpZiB0aGVyZSBhcmUgZHVwbGljYXRlIHBhY2tldHMuICBBdCBsZWFzdCBvbmUgcHJvYmxl bSB3aXRoIHRoYXQgaXMgdGhhdCBJIGhhdmUgcnVuIGludG8gbWlkZGxld2FyZSB3aGljaCBj cmVhdGVzIGR1cGxpY2F0ZSBwYWNrZXRzIGluIHRyYWNlcyB3aGljaCBhcmUgcmVhbGx5IG5v dCBvbiB0aGUgd2lyZS4gIEkgYmVsaWV2ZSB3ZSBkaXNjdXNzZWQgd2h5IGhhc2hpbmcgd291 bGQgbm90IHdvcmsgaW4gdGhlIFJGQyB0aGF0IHdlIHN1Ym1pdHRlZC4NCg0KMy4gIE5ldGZs b3csIEFDTHMsIGxvZ3MsIGV0YyBhcmUgYWxsIG9mdGVuIHF1aXRlIGltcG9zc2libGUgdG8g ZG8gYmVjYXVzZSB3ZSBkbyBub3QgbmVjZXNzYXJpbHkgb3duIHRoZSBuZXR3b3JrIGVuZCB0 byBlbmQgb3IgaXQgbWF5IGJlIGEgbmV0d29yayB3aGVyZSBhIGJ1c2luZXNzIHBhcnRuZXIg aXMgaW52b2x2ZWQuDQoNCjMuICBJIHN1c3BlY3QgdGhhdCB0aGUgdHJvdWJsZXNob290aW5n IHRoZSBvcGVyYXRvcnMgYXQgdGhlIElFVEYgcGVyZm9ybSBpcyBwb3NzaWJseSBub3QgZW5k LXRvLWVuZC4gIFNvLCB0aGV5IG1heSBub3QgaGF2ZSBydW4gaW50byB0aGUgcHJvYmxlbXMg dGhhdCB3ZSBoYXZlLg0KDQo0LiAgIEEgYmV0dGVyIHN0YXRlbWVudCBvZiB0aGUgcHJvYmxl bSBpcyBhY3R1YWxseSBhIGdvb2QgaWRlYSBhbmQgeW91IG1heSB3YW50IHRvIGxvb2sgdGhl IHBvc2l0aXZlIGFwcHJvYWNoIHRha2VuIGJ5IEFuZHJldyBZLg0KDQpodHRwczovL2RvY3Mu Z29vZ2xlLmNvbS9kb2N1bWVudC9kLzFUbk9OemRiaWN4d2t0dUZ6ZmpzWkFEZEZTU05naEsw R0J6dlBLQUZuZU9jL2VkaXQ/dXNwPXNoYXJpbmcNCg0KV2Ugd2lsbCBiZSB1cGRhdGluZyB0 aGUgYWJvdmUgZG9jdW1lbnQgd2l0aCBvdXIgdGhvdWdodHMuDQoNClRvIGVuZCB3aXRoLCBw bGVhc2UgZG8gbWUgdGhlIGNvdXJ0ZXN5IG9mIHRoaW5raW5nIHRoYXQgSSBhbSBub3QgbWVy ZWx5IHRyeWluZyB0byBtYXJrZXQgbXkgcHJvZHVjdHMuICAgSSBiZWxpZXZlIHRoZXJlIGFy ZSBvdGhlciB2ZW51ZXMgdGhhdCB3b3VsZCBiZSBtb3JlIGNvc3QgZWZmZWN0aXZlIHRoYW4g dGhlIGVtYWlsIGxpc3Qgb2YgdGhlIElFVEYuDQoNCg0KVGhhbmtzLA0KTmFsaW5pIEVsa2lu cw0KSW5zaWRlIFByb2R1Y3RzLCBJbmMuDQooODMxKSA2NTktODM2MA0Kd3d3Lmluc2lkZXRo ZXN0YWNrLmNvbTxodHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNvbT4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3Vt YXJpLm5ldDxtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQ+Pg0KVG86IE5hbGluaSBFbGtpbnMg PG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPG1haWx0bzpuYWxpbmkuZWxraW5z QGluc2lkZXRoZXN0YWNrLmNvbT4+DQpDYzogV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFy aS5uZXQ8bWFpbHRvOndhcnJlbkBrdW1hcmkubmV0Pj47IE1hcmsgU21pdGggPG1hcmt6enpz bWl0aEB5YWhvby5jb20uYXU8bWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU+Pjsg Sm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PG1haWx0bzp0b3VjaEBpc2kuZWR1Pj47IEFuZHJl dyBZb3VydGNoZW5rbyA8YXlvdXJ0Y2hAY2lzY28uY29tPG1haWx0bzpheW91cnRjaEBjaXNj by5jb20+PjsgSUVURiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+Pg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSA2LCAyMDEzIDY6NDQgQU0N ClN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZWxraW5zLXY2b3BzLWlw djYtaXBpZC1uZWVkZWQNCg0KDQpPbiBGZWIgNSwgMjAxMywgYXQgMjo1MyBQTSwgTmFsaW5p IEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb208bWFpbHRvOm5hbGlu aS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPj4gd3JvdGU6DQoNCj4gTWFyaywNCj4NCj4g VG9vbHMgYXJlIGEgZGlmZmVyZW50IHRvcGljLiAgQSBudW1iZXIgb2YgY29tcGFuaWVzLCBp bmNsdWRpbmcgbWluZSwgaGF2ZSBpbnRlbGxpZ2VudCBwYWNrZXQgYW5hbHl6ZXJzLg0KDQpJ IGJlbGlldmUgeW91IHNlbGwgcGFja2V0IGFuYWx5emVycywgbm8/IChUaGUgd29yZCAiaGF2 ZSIgaW4gdGhlIGFib3ZlIG1hZGUgaXQgc291bmQgbGlrZSB5b3UgcHVyY2hhc2VkIC8gb3du IGEgcGFja2V0IGFuYWx5emVyIGZyb20gc29tZW9uZSBlbHNlKS4NCg0KPiBGb3IgdXMsIHRo ZXJlIGlzIG5vdGhpbmcgb3VyIHByb2R1Y3RzIGxpa2UgYmV0dGVyIHRoYW4gdGhvdXNhbmRz IG9mIHBhY2tldHMgdGhhdCB3ZSBjYW4gcmVhZCBpbiBhbmQgdGhlbiBoZWxwIHRoZSBjdXN0 b21lciB0byBwaW5wb2ludCBwcm9ibGVtcyB0byB0aGUgZXhhY3QgcGFja2V0LiAgVGhpcyBp cyB0aGUgdHJlbmQgb2YgdGhlIGZ1dHVyZS4NCg0KQWhoaGghIFRoZSB0cmVuZCBvZiB0aGUg ZnV0dXJlLiBXZWxsLCB0aGF0J3MgYWxsIGFscmlnaHQgdGhlbuKApi4NCg0KDQo+ICBUaGUg dm9sdW1lIG9mIGRhdGEgYW5kIHBhY2tldHMgc29vbiBvdXRwYWNlcyB3aGF0IHdlIG1lcmUg aHVtYW5zIGNhbiBkby4gIFdlIG5lZWQgYSBwYXJ0bmVyc2hpcCBiZXR3ZWVuIGludGVsbGln ZW50IHRvb2xzIGFuZCBpbnRlbGxpZ2VudCBodW1hbnMuDQo+DQoNCk9oIGRlYXLigKYgICJ2 b2x1bWUgb2YgZGF0YSBhbmQgcGFja2V0cyBzb29uIG91dHBhY2VzIHdoYXQgd2UgbWVyZSBo dW1hbnMgY2FuIGRvIi4gIFRoYXQncyB3b3JyeWluZywgYmVjYXVzZSB1cCB0aWxsIG5vdyBJ J3ZlIGJlZW4gcGlja2luZyBiaXRzIG9mZiB0aGUgd2lyZSB3aXRoIGFuIG9zY2lsbG9zY29w ZSwgc2NyaWJibGluZyB0aGVtIGRvd24gb24gYSBwaWVjZSBvZiBwYXBlciAqcmVhbGx5IHF1 aWNrbHkqLCBjb252ZXJ0aW5nIHRoZSBiaXRzIHRvIGhleCBpbiBteSBoZWFkIGFuZCB0aGVu IHJlYXNzZW1ibGluZyB0aGUgcGFja2V0cyBhbmQgc3RyZWFtc+KApiBTb21ldGltZXMgY2Fs Y3VsYXRpbmcgdGhlIGNoZWNrc3VtIG9uIG15IGZpbmdlcnMgaXMgdHJpY2t5LCBidXQgSSB1 c3VhbGx5IGdldCBpdCByaWdodCB0aGUgc2Vjb25kIG9yIHRoaXJkIHRpbWUuIE9oLCBhbmQg ZG9uJ3QgZXZlbiBnZXQgbWUgc3RhcnRlZCBvbiB0cnlpbmcgdG8gZG8gdGhpcyB3aXRoIFZv SVAgb3IgdmlkZW8gLS0gdGhlIGNvZGVjIGRlc2lnbmVycyByZWFsbHkgc2hvdWxkIHRha2Ug aW50byBhY2NvdW50IGhvdyBoYXJkIGRlY29kaW5nIGlzIGZvciBhIGh1bWFu4oCmDQoNCg0K PiBJIHdvdWxkIGFjdHVhbGx5IGxvdmUgdG8gaGF2ZSBhIGRpc2N1c3Npb24gYXQgc29tZSBw b2ludCBvbiBiZXN0IHByYWN0aWNlcyBpbiB0cm91Ymxlc2hvb3RpbmcuDQoNClNv4oCmLg0K DQpUaGUgbGFzdCB0aW1lIHRoaXMgY2FtZSB1cCAoYXJvdW5kIEF1Z3VzdCAyMDExIGluIHRo ZSAiZHJhZnQtZWxraW5zLTZtYW4taXB2Ni1kaWFnbm9zdGljLWhlYWRlciIgdGhyZWFkLCBw YXJ0IG9mIHdoaWNoIGlzIGhlcmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi92Nm9wcy9jdXJyZW50L21zZzEwMjc1Lmh0bWwpIGEgbnVtYmVyIG9mIG9wZXJhdG9y cyB3aG8gYWN0dWFsbHkgKmRvKiB0cm91Ymxlc2hvb3RpbmcgcHJvdmlkZWQgYSBudW1iZXIg b2YgaWRlYXMuDQoNCkFGQUNUIC8gQUZBSVIsIG5vbmUgb2YgdGhlbSBzYWlkIHRoYXQgdGhl eSB1c2UgSVBJRCBpbiB2NCB2ZXJ5IG9mdGVuIGF0IGFsbC4gVGhleSBkaWQgcHJvdmlkZSBh IG51bWJlciBvZiB0aGVpciB0cm91Ymxlc2hvb3RpbmcgdGVjaG5pcXVlcyBmb3IgdGhlc2Ug c29ydHMgb2YgaXNzdWVzLi4uDQoNClNvbWUgc25pcHBldHMgZnJvbSB0aGF0IHRocmVhZDoN CkZyb20geW91cnNlbGYgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3Y2b3BzL2N1cnJlbnQvbXNnMTAyNjAuaHRtbDoNCiJJIGFtIHdvcmtpbmcgb24gY29udGFj dGluZyBhIG51bWJlciBvZiBvdXIgbGFyZ2UgY29ycG9yYXRlIGN1c3RvbWVycyB0byB3ZWln aCBpbiBvbiB0aGlzIHRvcGljLiAgSSB0aGluayB0aGF0IHRoZSBiaWdnZXN0IGlzc3VlIGhl cmUgaXMgdGhhdCB3aGVuIGEgbGFyZ2UgY29tbWVyY2lhbCBuZXR3b3JrIGlzIGhhdmluZyBw cm9ibGVtcywgYW55dGhpbmcgdGhhdCBjYW4gaGVscCBzcGVlZCBkaWFnbm9zdGljcyBpcyB3 b3J0aCBkb2luZy4gT3V0YWdlcyBhbmQgcG9vciBwZXJmb3JtYW5jZSBjYW4gY29zdCBhIGdy ZWF0IGRlYWwgb2YgbW9uZXkuDQoNClNpdHVhdGlvbnMgc3VjaCBhcyBjb21wYXJpbmcgcGFj a2V0cyBhdCB2YXJpb3VzIHBvaW50cyBvbiB0aGUgbmV0d29yayB0byBkZXRlcm1pbmUgcGFj a2V0IGxvc3MgaXMgYSBuZWNlc3NhcnkgcGFydCBvZiBuZXR3b3JrIHByb2JsZW0gZGV0ZXJt aW5hdGlvbi4gIEkgYW0gd29ya2luZyB0byBnZXQgdGhlIHRlY2huaWNpYW5zIGZyb20gdGhl IGNvcnBvcmF0aW9ucyB0aGVtc2VsdmVzIHRvIGdldCBvbnRvIHRoaXMgZW1haWwgbGlzdCBh bmQgdGVsbCB0aGVpciBvcGluaW9ucyB0aGVtc2VsdmVzLiINCg0KV2UgZGlkbid0IHNlZSB5 b3VyICJsYXJnZSBjb3Jwb3JhdGUgY3VzdG9tZXJzIiAobm9yLCBJIHN1c3BlY3QgZGlkIHdl IHJlYWxseSB3YW50IHRvKSwgYnV0IHdlIGRpZCBoYXZlIGEgbnVtYmVyIG9mIGZvbGsgcHJl c2VudCBhIGJ1bmNoIG9mIGlkZWFzIChtYW55IG9mIHRoZW0gb3BlcmF0b3JzIHdobyBwZXJm b3JtIHRyb3VibGVzaG9vdGluZyBvbiBsYXJnZSBuZXR3b3JrcyBvbiBhIGRhaWx5IGJhc2lz KQ0KDQpGb3IgZXhhbXBsZSwgQ2FybG9zIHN1Z2dlc3RlZCAoaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTAyNjYuaHRtbCk6DQoiVG8g Y29tcGFyZSBwYWNrZXRzLCB3ZSBjb3VsZCBwb3RlbnRpYWxseSBoYXZlIHRoZQ0KbmV0d29y ayBwcm90b2NvbCBhbmFseXplciAoZS5nLiwgV2lyZXNoYXJrKSBjb21wdXRlIGEgaGFzaCBv biBpbnZhcmlhbnQNCmZpZWxkcyBvZiB0aGUgcGFja2V0IChpLmUuLCBleGNsdWRlIEhvcCBM aW1pdCwgZXRjKSwgYW5kIHByZXNlbnQgdGhhdCBhcw0KcGFja2V0IG1ldGFkYXRhIHRoYXQg aXMgbm90IGFjdHVhbGx5IGNhcnJpZWQgb24gdGhlIHdpcmUuIg0KDQp5b3UgcmVwbGllZDoN CiJXZWxsLCB0aGF0IGlzIGEgcmVhbGx5IGdvb2QgaWRlYSB0aGF0IHdlIGhhZCBleHBsb3Jl ZCBhbHNvLiAgTm93LCB3ZSBvdXJzZWx2ZXMgbWFrZSBhbiBpbnRlbGxpZ2VudCBwYWNrZXQg YW5hbHl6ZXIgYW5kIHdvcmsgd2l0aCB0aGUgV2lyZVNoYXJrIGZvbGtzLiAgSWYgSSBsb29r IGF0IHRoaXMgc2VsZmlzaGx5IGZvciBoYXZpbmcgYW4gZXh0cmEgc2VsbGluZyBwb2ludCBm b3IgbXkgcHJvZHVjdHMsIHRoZW4gSSBjYW4gc2F5LCAnWWVzLCB3ZSBhbGxvdyB5b3UgdG8g ZG8gdGhpcyEgIEJ1eSBteSBwcm9kdWN0IScgIEJ1dCwgSSB3YXMgdHJ5aW5nIHRvIGJlIGEg Z29vZCBjaXRpemVuIGFuZCBhbGxvdyBhbGwgdG8gZG8gdGhpcyB3aXRob3V0IG91ciBwcm9k dWN0cy4gIE5vdywgaWYgb3VyIHByb3Bvc2FsIGlzIG5vdCBhZG9wdGVkLCB0aGVuIHdlIHdp bGwgZG8gdGhlIGNoZWNrc3VtIG9yIGhhc2ggb24gdGhlIHBhY2tldHMgaW4gb3VyIHByb2R1 Y3RzIGFzIEkgdGhpbmsgaXQgaXMgbmVlZGVkIGZvciBkaWFnbm9zdGljcy4gIg0KDQpEaWQg eW91IGltcGxlbWVudCB0aGlzPyAoSSdkIGxpa2UgdG8gbm90ZSB0aGF0IHRoaXMgZXhhY3Qg c2FtZSBzdWdnZXN0aW9uIGNhbWUgdXAgaW4gdGhpcyB0aHJlYWQpLg0KDQpTaGFuZSBBbWFu dGUgc3VnZ2VzdGVkIChpbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv djZvcHMvY3VycmVudC9tc2cxMDI3MC5odG1sDQoiSGF2ZSB5b3UgdGFrZW4gYSBsb29rIGF0 IGZsb3ctc3BlYyBmb3IgSVB2NDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1 NzUNCg0KLi4uIGFuZCwgZmxvdy1zcGVjIGZvciBJUHY2Og0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItZmxvdy1zcGVjLXY2LTAwDQoNCihCb3RoIHRoZSBS RkMgYW5kIEktRCBhcmUgd2l0aGluIHRoZSBJRFIgV0cpLg0KDQpJbiBzdW1tYXJ5LCB1c2lu ZyBmbG93LXNwZWMgb25lIGNhbiBkZWZpbmUgYW4gQUNMIHRoYXQgdGhlbiBnZXQgZGlzdHJp YnV0ZWQgYWNyb3NzIGFsbCByb3V0ZXJzIHdpdGhpbiBhbiBBU04sIHZpYSBCR1AsIHRoYXQg Y2FuIHRoZW4gYmUgdXNlZCB0byBjb3VudCBtYXRjaGluZyBwYWNrZXRzLCBsb2cgcGFja2V0 IGhlYWRlciBpbmZvcm1hdGlvbiwgZXRjLiAgSXQncyB1cCB0byB0aGUgb3BlcmF0b3IgdG8g ZGVjaWRlIHdoYXQgQUNMIHRvIGJlIGFwcGxpZWQgYW5kIHdoYXQgJ2FjdGlvbicgKGxvZ2dp bmcsIGNvdW50aW5nLCBldGMuKSB0byBiZSB0YWtlbiBmb3IgcGFja2V0cyB0aGF0IG1hdGNo IGEgZ2l2ZW4gJ3J1bGUnLg0KDQpGcm9tIHdoZXJlIEknbSBzaXR0aW5nLCB0aGlzIHNlZW1z IGxpa2UgaXQgbWlnaHQgYWxyZWFkeSBzb2x2ZSB0aGUgcHJvYmxlbSB5b3UncmUgaGF2aW5n LCB3aXRob3V0IGhhdmluZyB0byBpbnZlbnQgYSB3aG9sbHkgbmV3IElQdjYgRGVzdGluYXRp b24gSGVhZGVyIE9wdGlvbi4gIFNvLCBJIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB5b3UgaGF2 ZSB0YWtlbiBhIGxvb2sgYXQgZmxvdy1zcGVjIGFuZCwgaWYgc28sIHdoeSBpdCB3YXMgcnVs ZWQgb3V0PyINCg0KYW5kIHRoZW4gYW5zd2VyZWQgYSBidW5jaCBvZiB5b3VyIHF1ZXN0aW9u cyAoZnJvbSB3aGljaCBpdCBzZWVtZWQgeW91IGhhZG4ndCByZWFkIHRoZSByZWZlcmVuY2Vz IGhlIHNlbnQpLg0KU2hhbmUgYWxzbyBzdWdnZXN0ZWQgc0Zsb3cgLyBOZXRGbG93IC8gSVBG SVggYW5kIEFDTHMgd2l0aCBSU1BBTi4NCg0KRGlkIHlvdSBpbnZlc3RpZ2F0ZSAvIGltcGxl bWVudCB0aGVzZT8gSSBkb24ndCBzZWUgYSBmbG93IGNvbGxlY3RvciAvIHNwYW4gZW5kcG9p bnQgbGVzdGVyIGluIHlvdXIgcHJvZHVjdHMuLi4NCg0KDQoNCkFzIHdhcyBzYWlkIGluIHRo ZSBwcmV2aW91cyBnby1yb3VuZCBvbiB0aGlzLCBhbmQgaW4gdGhpcyB0aHJlYWQsIGl0IGlz IHVuY2xlYXIgd2hhdCBleGFjdGx5IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpcy4NCkFwYXJ0 IGZyb20gZmVlbGluZyB2ZXJ5IG1hcmtldHlbMF0sIG11Y2ggb2YgdGhpcyBzb3VuZHMgbGlr ZSAiSWYgYWxsIHlvdSBoYXZlIGlzIGEgaGFtbWVyLCBldmVyeXRoaW5nIGxvb2tzIGxpa2Ug YSBuYWlsIi4NCg0KQSBzaW1wbGUsIGNsZWFyLCBjb25jaXNlIGRlc2NyaXB0aW9uIG9mICp3 aGF0KiBwcm9ibGVtIHlvdSBhcmUgdHJ5aW5nIHRvIHNvbHZlICh3aXRob3V0IGFueSByZWZl cmVuY2VzIHRvIGhvdyBtdWNoIHRpbWUgeW91IGhhdmUgc2F2ZWQgdXNpbmcgSVBJRCwgaG93 IGl0IGlzIHRoZSBtb3N0IHdvbmRlcmZ1bCwgYXdlc29tZXN0IHRoaW5nIGV2ZXIsIGV0Yykg d291bGQgaGVscCBhIGJ1bmNoLi4uDQoNClcNCg0KWzBdOiBXaGljaCBtaWdodCBiZSBjYXVz aW5nIG11Y2ggb2YgbXkgZ3J1bXBpbmVzcyBpbiB0aGlzIHJlc3BvbnNlLi4uDQoNCg0KPiBP dXIgdWx0aW1hdGUgZ29hbCBpcyB0byBoYXZlIHRoZSByaWdodCBwZXJmb3JtYW5jZSBhbmQg dHJvdWJsZXNob290aW5nIG1ldHJpeCBidWlsdCByaWdodCBpbnRvIHRoZSBwcm90b2NvbHMg ZnJvbSB0aGUgZ2V0LWdvIQ0KPg0KPiBUaGFua3MsDQo+DQo+IE5hbGluaSBFbGtpbnMNCj4g SW5zaWRlIFByb2R1Y3RzLCBJbmMuDQo+ICg4MzEpIDY1OS04MzYwDQo+IHd3dy5pbnNpZGV0 aGVzdGFjay5jb208aHR0cDovL3d3dy5pbnNpZGV0aGVzdGFjay5jb20+DQo+DQo+IEZyb206 IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU8bWFpbHRvOm1hcmt6enpz bWl0aEB5YWhvby5jb20uYXU+Pg0KPiBUbzogTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2lu c0BpbnNpZGV0aGVzdGFjay5jb208bWFpbHRvOm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3Rh Y2suY29tPj47IEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdTxtYWlsdG86dG91Y2hAaXNpLmVk dT4+OyBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbTxtYWlsdG86YXlv dXJ0Y2hAY2lzY28uY29tPj4NCj4gQ2M6IElFVEYgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkg NSwgMjAxMyAxMTo0MiBBTQ0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRy YWZ0LWVsa2lucy12Nm9wcy1pcHY2LWlwaWQtbmVlZGVkDQo+DQo+DQo+DQo+DQo+DQo+DQo+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IE5hbGluaSBF bGtpbnMgPG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPG1haWx0bzpuYWxpbmku ZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4+DQo+ID5UbzogSm9lIFRvdWNoIDx0b3VjaEBp c2kuZWR1PG1haWx0bzp0b3VjaEBpc2kuZWR1Pj47IEFuZHJldyBZb3VydGNoZW5rbyA8YXlv dXJ0Y2hAY2lzY28uY29tPG1haWx0bzpheW91cnRjaEBjaXNjby5jb20+Pg0KPiA+Q2M6IElF VEYgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4N Cj4gPlNlbnQ6IFdlZG5lc2RheSwgNiBGZWJydWFyeSAyMDEzIDY6MjggQU0NCj4gPlN1Ympl Y3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBp ZC1uZWVkZWQNCj4gPg0KPiA+DQo+ID5Kb2UsDQo+ID4NCj4gPg0KPiA+V2VsbCwgZHVwbGlj YXRlIHBhY2tldHMgYXJlIG9mdGVuIHJldHJhbnNtaXNzaW9ucy4NCj4gPg0KPiA+DQo+DQo+ IFRoaXMgY2FuIGJlIHF1aXRlIGVhc2lseSBkZXRlcm1pbmVkIGJ5IGNvbXBhcmluZyBzZW50 IHBhY2tldCBjb3VudHMgYXQgb25lIGVuZCB3aXRoIHJlY2VpdmVkIHBhY2tldCBjb3VudHMg YXQgdGhlIG90aGVyLiBJJ2QgY29uc2lkZXIgZG9pbmcgdGhhdCB0byBiZSBtdWNoIGVhc2ll ciB0aGFuIGNhcHR1cmluZyAxMDAwcyBvZiBwYWNrZXRzIGFuZCB0aGVuIGxvb2tpbmcgdGhy b3VnaCB0aGVtIHdpdGggYW4gYW5hbHlzZXIgdG8gdHJ5IHRvIHNwb3QgZHVwbGljYXRlIHBh Y2tldHMuIEkgY29uc2lkZXIgdXNpbmcgYSBwYWNrZXQgYW5hbHlzZXIgdG8gYmUgYSBsYXN0 IHJlc29ydCB3aGVuIHRyb3VibGVzaG9vdGluZyBiZWNhdXNlIHlvdSdyZSB1c3VhbGx5IGRl YWxpbmcgd2l0aCAxMDAwcywgMTAgMDAwcyBvciAxMDAgMDAwcyBvZiBwYWNrZXRzLCBhbmQg dHJ5aW5nIHRvIHNwb3QgYSB0cmVuZCBvciBwaWNrIHRoZSBiYWQgaW5kaXZpZHVhbCBwYWNr ZXQuIEl0IGNhbiBhbHNvIGJlIHF1aXRlIG9uZXJvdXMgdG8gc2V0dXAgdGhlIHBhY2tldCBj YXB0dXJlIGFuZCB0aGUgdm9sdW1lIG9mIGRhdGEgY2FuIGh1Z2UuDQo+DQo+IFNvbWUgb2Yg dGhlc2UgZXhhbXBsZXMgYXJlIHN0YXJ0aW5nIHNvdW5kIGxpa2UgeW91J3ZlIGJlZW4gdGFr aW5nIHRoZSBhcHByb2FjaCBvZiAiaG93IGNhbiB3ZSB1c2UgSVBJRCB0byB0cm91Ymxlc2hv b3QgdGhpcyIgcmF0aGVyIHRoYW4gIndoYXQgaXMgdGhlIG1vc3QgZWZmZWN0aXZlIHRvb2wg dG8gdHJvdWJsZXNob290IHRoaXMiLCBvZiB3aGljaCBJUElEIG1pZ2h0IGJlIG9uZSBmb3Ig YSBwYXJ0aWN1bGFyIHNpdHVhdGlvbi4NCj4NCj4gPg0KPiA+DQo+ID4gIElmIHlvdSBoYXZl IHJldHJhbnNtaXNzaW9ucywgdGhlbiB0aGUgb3RoZXIgZW5kIChvciB0aGUgbmV0d29yaykg aXMgbm90IGFic29yYmluZyB0aGUgZmxvdyBwcm9wZXJseS4gIFRoZW4sIG9uIG91ciBlbmQs IHdlIG5lZWQgdG8gc2VlIGlmIHdlIGhhdmUgYWxsb2NhdGVkIGVub3VnaCBiYW5kd2lkdGgs IGl0IGlzIGdvaW5nIG92ZXIgYSBzdWItb3B0aW1hbCByb3V0ZSwgZXRjLg0KPiA+DQo+ID5U aGFua3MsDQo+ID4NCj4gPg0KPiA+TmFsaW5pIEVsa2lucw0KPiA+SW5zaWRlIFByb2R1Y3Rz LCBJbmMuDQo+ID4oODMxKSA2NTktODM2MA0KPiA+d3d3Lmluc2lkZXRoZXN0YWNrLmNvbTxo dHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNvbT4NCj4gPg0KPiA+DQo+ID4NCj4gPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRnJvbTogSm9lIFRvdWNoIDx0b3Vj aEBpc2kuZWR1PG1haWx0bzp0b3VjaEBpc2kuZWR1Pj4NCj4gPlRvOiBBbmRyZXcgWW91cnRj aGVua28gPGF5b3VydGNoQGNpc2NvLmNvbTxtYWlsdG86YXlvdXJ0Y2hAY2lzY28uY29tPj4N Cj4gPkNjOiBOYWxpbmkgRWxraW5zIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNv bTxtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20+PjsgSUVURiB2Nm9w cyBsaXN0IDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KPiA+U2Vu dDogVHVlc2RheSwgRmVicnVhcnkgNSwgMjAxMyAxMDoyNSBBTQ0KPiA+U3ViamVjdDogUmU6 IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRl ZA0KPiA+DQo+ID5QUyAtIEknbSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBhbiBleHBs YW5hdGlvbiBvZiB3aHkgZHVwbGljYXRlDQo+ID5wYWNrZXRzIHdvdWxkIGJlIGFuIGluZGlj YXRpb24gb2YgY29uZ2VzdGlvbiwgRldJVy4NCj4gPg0KPiA+Sm9lDQo+ID4NCj4gPk9uIDIv NS8yMDEzIDEwOjIwIEFNLCBKb2UgVG91Y2ggd3JvdGU6DQo+ID4+IEhpLCBBbmRyZXcsDQo+ ID4+DQo+ID4+IEkgY29tcGxldGVseSBhZ3JlZTsgSSBsb29rIGZvcndhcmQgdG8gYSBkZXNj cmlwdGlvbiBvZiB0aGUgcHJvYmxlbS4NCj4gPj4NCj4gPj4gSm9lDQo+ID4+DQo+ID4+IE9u IDIvNS8yMDEzIDk6MjIgQU0sIEFuZHJldyBZb3VydGNoZW5rbyB3cm90ZToNCj4gPj4+IE5h bGluaSwgSm9lLA0KPiA+Pj4NCj4gPj4+IFRoaXMgdHdvLW1haWwgZXhjaGFuZ2Ugdml2aWRs eSBpbGx1c3RyYXRlcyB3aHkgaXQncyBiZW5lZmljaWFsIHRvDQo+ID4+PiBkZXNjcmliZSB0 aGUgcHJvYmxlbSBiZXR0ZXIsIGFuZCB0aGUgcHJvcGVydGllcyBvZiB0aGUgaWRlYWwgc29s dXRpb24NCj4gPj4+IChzdGFydGluZyB3aXRoIHRoYXQgb2YgSVAgSUQsIGJ1dCBub3QgbmVj ZXNzYXJpbHkgbGltaXRlZCB0byBpdCksIGJ1dA0KPiA+Pj4gbm90IGp1bXAgdG8gc29sdXRp b25zIHRoZW1zZWx2ZXMgc3RyYWlnaHQgYXdheS4NCj4gPj4+DQo+ID4+PiBPdGhlcndpc2Ug aXQncyB0b28gZWFzeSB0byBnZXQgaW50byBhIHNpdHVhdGlvbiBvZiBhIGZpc2ggYW5kIGEg Z3VsbA0KPiA+Pj4gYXJndWluZyBhYm91dCB0aGUgc2VhIHdhdGVyLg0KPiA+Pj4NCj4gPj4+ IC0tYQ0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBPbiBUdWUsIDUgRmViIDIwMTMsIE5hbGluaSBF bGtpbnMNCj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+IENvbXBhcmluZyBoYXNoZXMgb3IgcGFj a2V0cyBpcyBub3QgcmVhbGx5IGEgd29ya2FibGUgc29sdXRpb24gYmVjYXVzZQ0KPiA+Pj4+ IHRoZXJlIGNhbiBiZSB0cnVlIGR1cGxpY2F0ZSBwYWNrZXRzLiAgQSBoYXNoIHdpbGwgb25s eSBzaG93IGlmDQo+ID4+Pj4gdGhlIHBhY2tldHMgYXJlIHRoZSBzYW1lLiAgVW5sZXNzIEkg YW0gbWlzc2luZyBzb21ldGhpbmcuICBTb21ldGltZXMNCj4gPj4+PiB0aGUgcHJvYmxlbSB3 ZSBhcmUgdHJ5aW5nIHRvIGRpYWdub3NlIGlzIGhvdyBtYW55IGR1cGxpY2F0ZXMNCj4gPj4+ PiB0aGVyZSBhcmUuICBUaGlzIGlzIGFuIGluZGljYXRpb24gb2YgY29uZ2VzdGlvbi4gIFNv bWUgZGV2aWNlcyBjcmVhdGUNCj4gPj4+PiAnZmFsc2UnIGR1cGxpY2F0ZXMuICBUaGF0IGlz IGEgcGFja2V0IHRyYWNlIHRha2VuIGF0IHRoYXQNCj4gPj4+PiBwb2ludCB3aWxsIHNob3cg dGhhdCB0aGUgcGFja2V0IGlzIHRoZSBzYW1lIGJ1dCBpdCBpcyBvbmx5IHRoZSBkZXZpY2UN Cj4gPj4+PiBvciB0aGUgdHJhY2UgbWVjaGFuaXNtIHRyYWNpbmcgaW5jb3JyZWN0bHkuICBC ZWxpZXZlIG1lLCB0aGlzDQo+ID4+Pj4gaXMgbm90IGFuIGluZnJlcXVlbnQgcHJvYmxlbS4N Cj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcywNCj4gPj4+Pg0KPiA+Pj4+IE5hbGluaSBFbGtpbnMN Cj4gPj4+PiBJbnNpZGUgUHJvZHVjdHMsIEluYy4NCj4gPj4+PiAoODMxKSA2NTktODM2MA0K PiA+Pj4+IHd3dy5pbnNpZGV0aGVzdGFjay5jb208aHR0cDovL3d3dy5pbnNpZGV0aGVzdGFj ay5jb20+DQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEZyb206IEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVk dTxtYWlsdG86dG91Y2hAaXNpLmVkdT4+DQo+ID4+Pj4gVG86IE5hbGluaSBFbGtpbnMgPG5h bGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPG1haWx0bzpuYWxpbmkuZWxraW5zQGlu c2lkZXRoZXN0YWNrLmNvbT4+DQo+ID4+Pj4gQ2M6IEFuZHJldyBZb3VydGNoZW5rbyA8YXlv dXJ0Y2hAY2lzY28uY29tPG1haWx0bzpheW91cnRjaEBjaXNjby5jb20+PjsgSUVURiB2Nm9w cyBsaXN0DQo+ID4+Pj4gPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+ DQo+ID4+Pj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgNSwgMjAxMyA4OjUwIEFNDQo+ID4+ Pj4gU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0Og0KPiBkcmFmdC1lbGtpbnMtdjZv cHMtaXB2Ni1pcGlkLW5lZWRlZA0KPiA+Pj4+DQo+ID4+Pj4gRldJVywgdGhlcmUgYXJlIHR3 byBvYnZpb3VzIHNvbHV0aW9ucyB0aGF0IHdvcmsgZm9yIGJvdGggSVB2NCBhbmQgSVB2NjoN Cj4gPj4+Pg0KPiA+Pj4+IDEpIHNlbmQgZnJhZ21lbnRlZCAob3IgZnJhZ21lbnRhYmxlKSBw YWNrZXRzDQo+ID4+Pj4gICAgcHJlc3VtaW5nIHlvdSBoYXZlIGNvbnRyb2wgb3ZlciBhIHNv dXJjZQ0KPiA+Pj4+DQo+ID4+Pj4gMikgY29tcGFyZSBlaXRoZXIgZnVsbCBwYWNrZXRzIG9y IGhhc2hlcyBvZiB0aGUgZnVsbCBwYWNrZXRzDQo+ID4+Pj4NCj4gPj4+PiAiY29udmVuaWVu Y2UiIG9mIGFuIGV4aXN0aW5nIGZpZWxkIHRoYXQgaXMgbm90IGFsd2F5cyBhdmFpbGFibGUg aXNuJ3QNCj4gPj4+PiBhIHNvbHV0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gSm9lDQo+ID4+Pj4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPg0KPiA+DQo+ID4NCj4gPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID52Nm9wcyBtYWlsaW5n IGxpc3QNCj4gPnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPg0KPiA+DQo+ ID4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2 Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KDQotLQ0KIkhhdmUgeW91IGdvdCBhbnkgcHJldmlvdXMgY29udmljdGlvbnM/ Ig0KDQoiV2VsbCwgSSBkdW5uby4uLiBJIHN1cHBvc2UgSSB1c2VkIHRvIGJlbGlldmUgdmVy eSBmaXJtbHkgdGhhdCBhIHBlbm55IHNhdmVkIGlzIGEgcGVubnkgZWFybmVkLS0iDQotLSBU ZXJyeSBQcmF0Y2hldHQNCg0KDQoNCg0KCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0 aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdp bmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3Jt YXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVj dHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGll cy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJl IE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGlu ZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQg QXNzb2NpYXRpb24uCg== --_000_4FC37E442D05A748896589E468752CAA0A0E7F17PWN401EA160entc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZl dGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFo b21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlR3 byAmbmJzcDtxdWljayByZWFjdGlvbnMgJm5ic3A7dG8gdGhlIGRpc2NvdXJzZXMgYmVsb3c6 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiMzLCZuYnNwOyBUaGVzZSB3b3VsZCBhcHBl YXIgdG8gYmUgcHJvcHJpZXRhcnkgc29sdXRpb25zLiZuYnNwOyZuYnNwOyBBcyBhIGN1c3Rv bWVyIEkgd291bGQgcHJlZmVyIHRvIE5PVCBkZXBlbmQgb24gYW55dGhpbmcgcHJvcHJpZXRh cnkgaWYgcG9zc2libGUgYW5kIHdvdWxkIGdyZWF0bHkgcHJlZmVyDQogJm5ic3A7U3RhbmRh cmQgc29sdXRpb25zICZuYnNwO2ludGVuZGVkIHRvIHdvcmsgb24gYWxsIHBsYXRmb3JtcyBh bmQgc2l0dWF0aW9ucy4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRz IHRvIHRoaXMgYmVpbmcgYW4gZWZmb3J0IGZvciBOYWxpbmkgdG8gbWFya2V0IGhlciBwcm9k dWN0cy4mbmJzcDsmbmJzcDsgSSBtYXkgYmUgdGVycmlibHkgY29uZnVzZWQsIGJ1dCBJIHdv dWxkIHRoaW5rIGp1c3QgdGhlIG9wcG9zaXRlLiZuYnNwOyZuYnNwOyBBcyBhIGN1c3RvbWVy LCBpZiBJDQogYmVnaW4gdG8gbG9zZSB0cmllZCBhbmQgdHJ1ZSBmYWNpbGl0aWVzIHN1Y2gg YXMgSVBJRCwgd2hpY2ggaGF2ZSBiZWVuIGluc3RydW1lbnRhbCBpbiBzb2x2aW5nIHNvbWUg b2Ygb3VyIG1vcmUgY29tcGxleCBzaXR1YXRpb25zLCB0aGVuIEkgd291bGQgc2VlIG15c2Vs ZiBiZWNvbWluZyBtb3JlIGRlcGVuZGFudCBhbmQgcmVsaWFudCBvbiBwcm9kdWN0cyBzdWNo IGFzIE5hbGluaeKAmXMgQ29tcGFueSBtYXJrZXRzLiZuYnNwOyZuYnNwOyZuYnNwOyBJIHZp ZXcgaGVyIGFjdGlvbnMvaW52b2x2ZW1lbnQNCiBhcyB3aGF0IHNob3VsZCBiZSBiZXN0IGZv ciBlbmQgdXNlcnMgYW5kIG5ldHdvcmtzIGluIGdlbmVyYWwuJm5ic3A7IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5hbGluaSBFbGtp bnM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAwNiwgMjAxMyAxMDo0 NSBBTTxicj4NCjxiPlRvOjwvYj4gV2FycmVuIEt1bWFyaTxicj4NCjxiPkNjOjwvYj4gSUVU RiB2Nm9wcyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIG5ldyBkcmFm dDogZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVkZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM0NTQ1NDUiPldhcnJlbiw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNDU0NTQ1Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM0NTQ1NDUiPkkgd2lsbCBhbnN3ZXIgZmV3IG9mIHlvdXIgY29tbWVudHMg KGhvcGVmdWxseSEpIGluIGEgbW9yZSBwb3NpdGl2ZSBzcGlyaXQgdGhhbiB5b3Vycy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NTQ1NDUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ1NDU0NSI+ MS4gJm5ic3A7WW91ciBjb21tZW50OiZuYnNwO1dlIGRpZG4ndCBzZWUgeW91ciAmcXVvdDts YXJnZSBjb3Jwb3JhdGUgY3VzdG9tZXJzJnF1b3Q7IChub3IsIEkgc3VzcGVjdCBkaWQgd2Ug cmVhbGx5IHdhbnQgdG8pLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzQ1NDU0NSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij5NeSBhbnN3ZXI6ICZuYnNwO1JlYWxseT8gJm5i c3A7IFdoeSBpbiB0aGUgd29ybGQgd291bGQgeW91IG5vdCB3YW50IHRvPyAmbmJzcDsgV2hh dCB3b3VsZCBtYWtlIHlvdSBzYXkgc29tZXRoaW5nIGxpa2UgdGhhdD8gJm5ic3A7SSB3YXMg dW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUgSUVURiB3YXMNCiBvcGVuIHRvIGV2ZXJ5 b25lIHdpdGggY29uY2VybnMuICZuYnNwO0JUVywgdGhlcmUgYXJlIHR3byBsYXJnZSBjb3Jw b3JhdGUgY3VzdG9tZXJzIHdobyBoYXZlIGFjdHVhbGx5IGNvLWF1dGhvcmVkIHRoZSBSRkMg LSBCbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBVUyBCYW5rLiAmbmJz cDsgVGhlIG90aGVyIGNvLWF1dGhvciBpcyBJQk0uICZuYnNwO1lvdSBtYXkgaGF2ZSBoZWFy ZCBvZiB0aGVtLiAmbmJzcDsgSSB3b25kZXIgd2h5IHlvdSB0aGluayB0aGV5IHBhcnRpY2lw YXRlZA0KIGluIHRoaXMgZWZmb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzQ1NDU0NSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij4yLiAmbmJzcDsgSSBpbnZlc3RpZ2F0ZWQgZG9p bmcgYSBoYXNoIG9uIHRoZSBwYWNrZXRzIGFuZCBpdCB3aWxsIG5vdCB3b3JrLiAmbmJzcDtJ dCBvbmx5IGluZGljYXRlcyBpZiB0aGVyZSBhcmUgZHVwbGljYXRlIHBhY2tldHMuICZuYnNw O0F0IGxlYXN0IG9uZSBwcm9ibGVtIHdpdGggdGhhdCBpcw0KIHRoYXQgSSBoYXZlIHJ1biBp bnRvIG1pZGRsZXdhcmUgd2hpY2ggY3JlYXRlcyBkdXBsaWNhdGUgcGFja2V0cyBpbiB0cmFj ZXMgd2hpY2ggYXJlIHJlYWxseSBub3Qgb24gdGhlIHdpcmUuICZuYnNwO0kgYmVsaWV2ZSB3 ZSBkaXNjdXNzZWQgd2h5IGhhc2hpbmcgd291bGQgbm90IHdvcmsgaW4gdGhlIFJGQyB0aGF0 IHdlIHN1Ym1pdHRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM0NTQ1NDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzQ1NDU0NSI+My4gJm5ic3A7TmV0ZmxvdywgQUNMcywgbG9ncywgZXRjIGFy ZSBhbGwgb2Z0ZW4gcXVpdGUgaW1wb3NzaWJsZSB0byBkbyBiZWNhdXNlIHdlIGRvIG5vdCBu ZWNlc3NhcmlseSBvd24gdGhlIG5ldHdvcmsgZW5kIHRvIGVuZCBvciBpdCBtYXkgYmUgYSBu ZXR3b3JrIHdoZXJlIGEgYnVzaW5lc3MNCiBwYXJ0bmVyIGlzIGludm9sdmVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ1NDU0NSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij4zLiAm bmJzcDtJIHN1c3BlY3QgdGhhdCB0aGUgdHJvdWJsZXNob290aW5nIHRoZSBvcGVyYXRvcnMg YXQgdGhlIElFVEYgcGVyZm9ybSBpcyBwb3NzaWJseSBub3QgZW5kLXRvLWVuZC4gJm5ic3A7 U28sIHRoZXkgbWF5IG5vdCBoYXZlIHJ1biBpbnRvIHRoZSBwcm9ibGVtcyB0aGF0IHdlIGhh dmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0 NTQ1NDUiPjQuICZuYnNwOyBBIGJldHRlciBzdGF0ZW1lbnQgb2YgdGhlIHByb2JsZW0gaXMg YWN0dWFsbHkgYSBnb29kIGlkZWEgYW5kIHlvdSBtYXkgd2FudCB0byBsb29rIHRoZSBwb3Np dGl2ZSBhcHByb2FjaCB0YWtlbiBieSBBbmRyZXcgWS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NTQ1NDUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ1NDU0NSI+PGEgaHJlZj0iaHR0cHM6Ly9k b2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xVG5PTnpkYmljeHdrdHVGemZqc1pBRGRGU1NO Z2hLMEdCenZQS0FGbmVPYy9lZGl0P3VzcD1zaGFyaW5nIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOiMyNzk3REEiPmh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3Vt ZW50L2QvMVRuT056ZGJpY3h3a3R1RnpmanNaQURkRlNTTmdoSzBHQnp2UEtBRm5lT2MvZWRp dD91c3A9c2hhcmluZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM0NTQ1NDUiPldlIHdpbGwgYmUgdXBkYXRpbmcgdGhlIGFi b3ZlIGRvY3VtZW50IHdpdGggb3VyIHRob3VnaHRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ1NDU0NSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij5UbyBlbmQgd2l0aCwgcGxlYXNl IGRvIG1lIHRoZSBjb3VydGVzeSBvZiB0aGlua2luZyB0aGF0IEkgYW0gbm90IG1lcmVseSB0 cnlpbmcgdG8gbWFya2V0IG15IHByb2R1Y3RzLiAmbmJzcDsgSSBiZWxpZXZlIHRoZXJlIGFy ZSBvdGhlciB2ZW51ZXMgdGhhdCB3b3VsZCBiZSBtb3JlDQogY29zdCBlZmZlY3RpdmUgdGhh biB0aGUgZW1haWwgbGlzdCBvZiB0aGUgSUVURi4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDU0NTQ1Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TmFs aW5pIEVsa2luczxicj4NCkluc2lkZSBQcm9kdWN0cywgSW5jLjxicj4NCig4MzEpIDY1OS04 MzYwPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pbnNpZGV0aGVzdGFjay5jb20iPnd3dy5p bnNpZGV0aGVzdGFjay5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAw JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiBXYXJyZW4gS3VtYXJpICZsdDs8YSBocmVmPSJtYWls dG86d2FycmVuQGt1bWFyaS5uZXQiPndhcnJlbkBrdW1hcmkubmV0PC9hPiZndDs8YnI+DQo8 Yj5Ubzo8L2I+IE5hbGluaSBFbGtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpuYWxpbmkuZWxr aW5zQGluc2lkZXRoZXN0YWNrLmNvbSI+bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5j b208L2E+Jmd0Ow0KPGJyPg0KPGI+Q2M6PC9iPiBXYXJyZW4gS3VtYXJpICZsdDs8YSBocmVm PSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiPndhcnJlbkBrdW1hcmkubmV0PC9hPiZndDs7 IE1hcmsgU21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrenp6c21pdGhAeWFob28uY29t LmF1Ij5tYXJrenp6c21pdGhAeWFob28uY29tLmF1PC9hPiZndDs7IEpvZSBUb3VjaCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRvdWNoQGlzaS5lZHUiPnRvdWNoQGlzaS5lZHU8L2E+Jmd0Ozsg QW5kcmV3IFlvdXJ0Y2hlbmtvICZsdDs8YSBocmVmPSJtYWlsdG86YXlvdXJ0Y2hAY2lzY28u Y29tIj5heW91cnRjaEBjaXNjby5jb208L2E+Jmd0OzsNCiBJRVRGIHY2b3BzIGxpc3QgJmx0 OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0 OyA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSA2LCAyMDEzIDY6NDQg QU08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1l bGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRlZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KT24gRmViIDUsIDIwMTMsIGF0 IDI6NTMgUE0sIE5hbGluaSBFbGtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpuYWxpbmkuZWxr aW5zQGluc2lkZXRoZXN0YWNrLmNvbSI+bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IE1hcmssPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFRvb2xzIGFyZSBhIGRpZmZlcmVudCB0b3BpYy4mbmJzcDsgQSBudW1iZXIgb2Yg Y29tcGFuaWVzLCBpbmNsdWRpbmcgbWluZSwgaGF2ZSBpbnRlbGxpZ2VudCBwYWNrZXQgYW5h bHl6ZXJzLiZuYnNwOw0KPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHlvdSBzZWxsIHBhY2tldCBh bmFseXplcnMsIG5vPyAoVGhlIHdvcmQgJnF1b3Q7aGF2ZSZxdW90OyBpbiB0aGUgYWJvdmUg bWFkZSBpdCBzb3VuZCBsaWtlIHlvdSBwdXJjaGFzZWQgLyBvd24gYSBwYWNrZXQgYW5hbHl6 ZXIgZnJvbSBzb21lb25lIGVsc2UpLjxicj4NCjxicj4NCiZndDsgRm9yIHVzLCB0aGVyZSBp cyBub3RoaW5nIG91ciBwcm9kdWN0cyBsaWtlIGJldHRlciB0aGFuIHRob3VzYW5kcyBvZiBw YWNrZXRzIHRoYXQgd2UgY2FuIHJlYWQgaW4gYW5kIHRoZW4gaGVscCB0aGUgY3VzdG9tZXIg dG8gcGlucG9pbnQgcHJvYmxlbXMgdG8gdGhlIGV4YWN0IHBhY2tldC4mbmJzcDsgVGhpcyBp cyB0aGUgdHJlbmQgb2YgdGhlIGZ1dHVyZS48YnI+DQo8YnI+DQpBaGhoaCEgVGhlIHRyZW5k IG9mIHRoZSBmdXR1cmUuIFdlbGwsIHRoYXQncyBhbGwgYWxyaWdodCB0aGVu4oCmLjxicj4N Cjxicj4NCjxicj4NCiZndDsmbmJzcDsgVGhlIHZvbHVtZSBvZiBkYXRhIGFuZCBwYWNrZXRz IHNvb24gb3V0cGFjZXMgd2hhdCB3ZSBtZXJlIGh1bWFucyBjYW4gZG8uJm5ic3A7IFdlIG5l ZWQgYSBwYXJ0bmVyc2hpcCBiZXR3ZWVuIGludGVsbGlnZW50IHRvb2xzIGFuZCBpbnRlbGxp Z2VudCBodW1hbnMuPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQpPaCBkZWFy4oCmJm5ic3A7ICZx dW90O3ZvbHVtZSBvZiBkYXRhIGFuZCBwYWNrZXRzIHNvb24gb3V0cGFjZXMgd2hhdCB3ZSBt ZXJlIGh1bWFucyBjYW4gZG8mcXVvdDsuJm5ic3A7IFRoYXQncyB3b3JyeWluZywgYmVjYXVz ZSB1cCB0aWxsIG5vdyBJJ3ZlIGJlZW4gcGlja2luZyBiaXRzIG9mZiB0aGUgd2lyZSB3aXRo IGFuIG9zY2lsbG9zY29wZSwgc2NyaWJibGluZyB0aGVtIGRvd24gb24gYSBwaWVjZSBvZiBw YXBlciAqcmVhbGx5IHF1aWNrbHkqLCBjb252ZXJ0aW5nIHRoZSBiaXRzIHRvDQogaGV4IGlu IG15IGhlYWQgYW5kIHRoZW4gcmVhc3NlbWJsaW5nIHRoZSBwYWNrZXRzIGFuZCBzdHJlYW1z 4oCmIFNvbWV0aW1lcyBjYWxjdWxhdGluZyB0aGUgY2hlY2tzdW0gb24gbXkgZmluZ2VycyBp cyB0cmlja3ksIGJ1dCBJIHVzdWFsbHkgZ2V0IGl0IHJpZ2h0IHRoZSBzZWNvbmQgb3IgdGhp cmQgdGltZS4gT2gsIGFuZCBkb24ndCBldmVuIGdldCBtZSBzdGFydGVkIG9uIHRyeWluZyB0 byBkbyB0aGlzIHdpdGggVm9JUCBvciB2aWRlbyAtLSB0aGUNCiBjb2RlYyBkZXNpZ25lcnMg cmVhbGx5IHNob3VsZCB0YWtlIGludG8gYWNjb3VudCBob3cgaGFyZCBkZWNvZGluZyBpcyBm b3IgYSBodW1hbuKApjxicj4NCjxicj4NCjxicj4NCiZndDsgSSB3b3VsZCBhY3R1YWxseSBs b3ZlIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGF0IHNvbWUgcG9pbnQgb24gYmVzdCBwcmFjdGlj ZXMgaW4gdHJvdWJsZXNob290aW5nLiZuYnNwOw0KPGJyPg0KPGJyPg0KU2/igKYuPGJyPg0K PGJyPg0KVGhlIGxhc3QgdGltZSB0aGlzIGNhbWUgdXAgKGFyb3VuZCBBdWd1c3QgMjAxMSBp biB0aGUgJnF1b3Q7ZHJhZnQtZWxraW5zLTZtYW4taXB2Ni1kaWFnbm9zdGljLWhlYWRlciZx dW90OyB0aHJlYWQsIHBhcnQgb2Ygd2hpY2ggaXMgaGVyZToNCjxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50L21zZzEwMjc1Lmh0 bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi92Nm9wcy9jdXJyZW50L21zZzEwMjc1Lmh0bWw8L2E+KSBhIG51bWJlciBvZiBvcGVy YXRvcnMgd2hvIGFjdHVhbGx5ICpkbyogdHJvdWJsZXNob290aW5nIHByb3ZpZGVkIGEgbnVt YmVyIG9mIGlkZWFzLjxicj4NCjxicj4NCkFGQUNUIC8gQUZBSVIsIG5vbmUgb2YgdGhlbSBz YWlkIHRoYXQgdGhleSB1c2UgSVBJRCBpbiB2NCB2ZXJ5IG9mdGVuIGF0IGFsbC4gVGhleSBk aWQgcHJvdmlkZSBhIG51bWJlciBvZiB0aGVpciB0cm91Ymxlc2hvb3RpbmcgdGVjaG5pcXVl cyBmb3IgdGhlc2Ugc29ydHMgb2YgaXNzdWVzLi4uPGJyPg0KPGJyPg0KU29tZSBzbmlwcGV0 cyBmcm9tIHRoYXQgdGhyZWFkOjxicj4NCkZyb20geW91cnNlbGYgaW4gPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTAy NjAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTAyNjAuaHRtbDwvYT46PGJyPg0KJnF1b3Q7 SSBhbSB3b3JraW5nIG9uIGNvbnRhY3RpbmcgYSBudW1iZXIgb2Ygb3VyIGxhcmdlIGNvcnBv cmF0ZSBjdXN0b21lcnMgdG8gd2VpZ2ggaW4gb24gdGhpcyB0b3BpYy4mbmJzcDsgSSB0aGlu ayB0aGF0IHRoZSBiaWdnZXN0IGlzc3VlIGhlcmUgaXMgdGhhdCB3aGVuIGEgbGFyZ2UgY29t bWVyY2lhbCBuZXR3b3JrIGlzIGhhdmluZyBwcm9ibGVtcywgYW55dGhpbmcgdGhhdCBjYW4g aGVscCBzcGVlZCBkaWFnbm9zdGljcyBpcyB3b3J0aCBkb2luZy4gT3V0YWdlcw0KIGFuZCBw b29yIHBlcmZvcm1hbmNlIGNhbiBjb3N0IGEgZ3JlYXQgZGVhbCBvZiBtb25leS4mbmJzcDsg PGJyPg0KPGJyPg0KU2l0dWF0aW9ucyBzdWNoIGFzIGNvbXBhcmluZyBwYWNrZXRzIGF0IHZh cmlvdXMgcG9pbnRzIG9uIHRoZSBuZXR3b3JrIHRvIGRldGVybWluZSBwYWNrZXQgbG9zcyBp cyBhIG5lY2Vzc2FyeSBwYXJ0IG9mIG5ldHdvcmsgcHJvYmxlbSBkZXRlcm1pbmF0aW9uLiZu YnNwOyBJIGFtIHdvcmtpbmcgdG8gZ2V0IHRoZSB0ZWNobmljaWFucyBmcm9tIHRoZSBjb3Jw b3JhdGlvbnMgdGhlbXNlbHZlcyB0byBnZXQgb250byB0aGlzIGVtYWlsIGxpc3QgYW5kIHRl bGwgdGhlaXINCiBvcGluaW9ucyB0aGVtc2VsdmVzLiZxdW90Ozxicj4NCjxicj4NCldlIGRp ZG4ndCBzZWUgeW91ciAmcXVvdDtsYXJnZSBjb3Jwb3JhdGUgY3VzdG9tZXJzJnF1b3Q7IChu b3IsIEkgc3VzcGVjdCBkaWQgd2UgcmVhbGx5IHdhbnQgdG8pLCBidXQgd2UgZGlkIGhhdmUg YSBudW1iZXIgb2YgZm9sayBwcmVzZW50IGEgYnVuY2ggb2YgaWRlYXMgKG1hbnkgb2YgdGhl bSBvcGVyYXRvcnMgd2hvIHBlcmZvcm0gdHJvdWJsZXNob290aW5nIG9uIGxhcmdlIG5ldHdv cmtzIG9uIGEgZGFpbHkgYmFzaXMpPGJyPg0KPGJyPg0KRm9yIGV4YW1wbGUsIENhcmxvcyBz dWdnZXN0ZWQgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi92Nm9wcy9jdXJyZW50L21zZzEwMjY2Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cxMDI2Ni5o dG1sPC9hPik6PGJyPg0KJnF1b3Q7VG8gY29tcGFyZSBwYWNrZXRzLCB3ZSBjb3VsZCBwb3Rl bnRpYWxseSBoYXZlIHRoZTxicj4NCm5ldHdvcmsgcHJvdG9jb2wgYW5hbHl6ZXIgKGUuZy4s IFdpcmVzaGFyaykgY29tcHV0ZSBhIGhhc2ggb24gaW52YXJpYW50PGJyPg0KZmllbGRzIG9m IHRoZSBwYWNrZXQgKGkuZS4sIGV4Y2x1ZGUgSG9wIExpbWl0LCBldGMpLCBhbmQgcHJlc2Vu dCB0aGF0IGFzPGJyPg0KcGFja2V0IG1ldGFkYXRhIHRoYXQgaXMgbm90IGFjdHVhbGx5IGNh cnJpZWQgb24gdGhlIHdpcmUuJnF1b3Q7PGJyPg0KPGJyPg0KeW91IHJlcGxpZWQ6PGJyPg0K JnF1b3Q7V2VsbCwgdGhhdCBpcyBhIHJlYWxseSBnb29kIGlkZWEgdGhhdCB3ZSBoYWQgZXhw bG9yZWQgYWxzby4mbmJzcDsgTm93LCB3ZSBvdXJzZWx2ZXMgbWFrZSBhbiBpbnRlbGxpZ2Vu dCBwYWNrZXQgYW5hbHl6ZXIgYW5kIHdvcmsgd2l0aCB0aGUgV2lyZVNoYXJrIGZvbGtzLiZu YnNwOyBJZiBJIGxvb2sgYXQgdGhpcyBzZWxmaXNobHkgZm9yIGhhdmluZyBhbiBleHRyYSBz ZWxsaW5nIHBvaW50IGZvciBteSBwcm9kdWN0cywgdGhlbiBJIGNhbiBzYXksICdZZXMsIHdl IGFsbG93DQogeW91IHRvIGRvIHRoaXMhJm5ic3A7IEJ1eSBteSBwcm9kdWN0IScmbmJzcDsg QnV0LCBJIHdhcyB0cnlpbmcgdG8gYmUgYSBnb29kIGNpdGl6ZW4gYW5kIGFsbG93IGFsbCB0 byBkbyB0aGlzIHdpdGhvdXQgb3VyIHByb2R1Y3RzLiZuYnNwOyBOb3csIGlmIG91ciBwcm9w b3NhbCBpcyBub3QgYWRvcHRlZCwgdGhlbiB3ZSB3aWxsIGRvIHRoZSBjaGVja3N1bSBvciBo YXNoIG9uIHRoZSBwYWNrZXRzIGluIG91ciBwcm9kdWN0cyBhcyBJIHRoaW5rIGl0IGlzIG5l ZWRlZCBmb3IgZGlhZ25vc3RpY3MuDQogJnF1b3Q7PGJyPg0KPGJyPg0KRGlkIHlvdSBpbXBs ZW1lbnQgdGhpcz8gKEknZCBsaWtlIHRvIG5vdGUgdGhhdCB0aGlzIGV4YWN0IHNhbWUgc3Vn Z2VzdGlvbiBjYW1lIHVwIGluIHRoaXMgdGhyZWFkKS48YnI+DQo8YnI+DQpTaGFuZSBBbWFu dGUgc3VnZ2VzdGVkIChpbiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cxMDI3MC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9t c2cxMDI3MC5odG1sPC9hPiA8YnI+DQomcXVvdDtIYXZlIHlvdSB0YWtlbiBhIGxvb2sgYXQg Zmxvdy1zcGVjIGZvciBJUHY0Ojxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzU1NzUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1NTc1PC9hPjxicj4NCjxicj4NCi4uLiBhbmQsIGZsb3ctc3BlYyBmb3IgSVB2 Njo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlkci1mbG93LXNwZWMtdjYtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1mbG93LXNwZWMtdjYtMDA8L2E+PGJyPg0KPGJy Pg0KKEJvdGggdGhlIFJGQyBhbmQgSS1EIGFyZSB3aXRoaW4gdGhlIElEUiBXRykuPGJyPg0K PGJyPg0KSW4gc3VtbWFyeSwgdXNpbmcgZmxvdy1zcGVjIG9uZSBjYW4gZGVmaW5lIGFuIEFD TCB0aGF0IHRoZW4gZ2V0IGRpc3RyaWJ1dGVkIGFjcm9zcyBhbGwgcm91dGVycyB3aXRoaW4g YW4gQVNOLCB2aWEgQkdQLCB0aGF0IGNhbiB0aGVuIGJlIHVzZWQgdG8gY291bnQgbWF0Y2hp bmcgcGFja2V0cywgbG9nIHBhY2tldCBoZWFkZXIgaW5mb3JtYXRpb24sIGV0Yy4mbmJzcDsg SXQncyB1cCB0byB0aGUgb3BlcmF0b3IgdG8gZGVjaWRlIHdoYXQgQUNMIHRvIGJlIGFwcGxp ZWQNCiBhbmQgd2hhdCAnYWN0aW9uJyAobG9nZ2luZywgY291bnRpbmcsIGV0Yy4pIHRvIGJl IHRha2VuIGZvciBwYWNrZXRzIHRoYXQgbWF0Y2ggYSBnaXZlbiAncnVsZScuJm5ic3A7DQo8 YnI+DQo8YnI+DQpGcm9tIHdoZXJlIEknbSBzaXR0aW5nLCB0aGlzIHNlZW1zIGxpa2UgaXQg bWlnaHQgYWxyZWFkeSBzb2x2ZSB0aGUgcHJvYmxlbSB5b3UncmUgaGF2aW5nLCB3aXRob3V0 IGhhdmluZyB0byBpbnZlbnQgYSB3aG9sbHkgbmV3IElQdjYgRGVzdGluYXRpb24gSGVhZGVy IE9wdGlvbi4mbmJzcDsgU28sIEkgd291bGQgbGlrZSB0byBrbm93IGlmIHlvdSBoYXZlIHRh a2VuIGEgbG9vayBhdCBmbG93LXNwZWMgYW5kLCBpZiBzbywgd2h5IGl0IHdhcyBydWxlZCBv dXQ/JnF1b3Q7PGJyPg0KPGJyPg0KYW5kIHRoZW4gYW5zd2VyZWQgYSBidW5jaCBvZiB5b3Vy IHF1ZXN0aW9ucyAoZnJvbSB3aGljaCBpdCBzZWVtZWQgeW91IGhhZG4ndCByZWFkIHRoZSBy ZWZlcmVuY2VzIGhlIHNlbnQpLg0KPGJyPg0KU2hhbmUgYWxzbyBzdWdnZXN0ZWQgc0Zsb3cg LyBOZXRGbG93IC8gSVBGSVggYW5kIEFDTHMgd2l0aCBSU1BBTi48YnI+DQo8YnI+DQpEaWQg eW91IGludmVzdGlnYXRlIC8gaW1wbGVtZW50IHRoZXNlPyBJIGRvbid0IHNlZSBhIGZsb3cg Y29sbGVjdG9yIC8gc3BhbiBlbmRwb2ludCBsZXN0ZXIgaW4geW91ciBwcm9kdWN0cy4uLjxi cj4NCjxicj4NCjxicj4NCjxicj4NCkFzIHdhcyBzYWlkIGluIHRoZSBwcmV2aW91cyBnby1y b3VuZCBvbiB0aGlzLCBhbmQgaW4gdGhpcyB0aHJlYWQsIGl0IGlzIHVuY2xlYXIgd2hhdCBl eGFjdGx5IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpcy4NCjxicj4NCkFwYXJ0IGZyb20gZmVl bGluZyB2ZXJ5IG1hcmtldHlbMF0sIG11Y2ggb2YgdGhpcyBzb3VuZHMgbGlrZSAmcXVvdDtJ ZiBhbGwgeW91IGhhdmUgaXMgYSBoYW1tZXIsIGV2ZXJ5dGhpbmcgbG9va3MgbGlrZSBhIG5h aWwmcXVvdDsuPGJyPg0KPGJyPg0KQSBzaW1wbGUsIGNsZWFyLCBjb25jaXNlIGRlc2NyaXB0 aW9uIG9mICp3aGF0KiBwcm9ibGVtIHlvdSBhcmUgdHJ5aW5nIHRvIHNvbHZlICh3aXRob3V0 IGFueSByZWZlcmVuY2VzIHRvIGhvdyBtdWNoIHRpbWUgeW91IGhhdmUgc2F2ZWQgdXNpbmcg SVBJRCwgaG93IGl0IGlzIHRoZSBtb3N0IHdvbmRlcmZ1bCwgYXdlc29tZXN0IHRoaW5nIGV2 ZXIsIGV0Yykgd291bGQgaGVscCBhIGJ1bmNoLi4uPGJyPg0KPGJyPg0KVzxicj4NCjxicj4N ClswXTogV2hpY2ggbWlnaHQgYmUgY2F1c2luZyBtdWNoIG9mIG15IGdydW1waW5lc3MgaW4g dGhpcyByZXNwb25zZS4uLjxicj4NCjxicj4NCjxicj4NCiZndDsgT3VyIHVsdGltYXRlIGdv YWwgaXMgdG8gaGF2ZSB0aGUgcmlnaHQgcGVyZm9ybWFuY2UgYW5kIHRyb3VibGVzaG9vdGlu ZyBtZXRyaXggYnVpbHQgcmlnaHQgaW50byB0aGUgcHJvdG9jb2xzIGZyb20gdGhlIGdldC1n byE8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgPGJyPg0K Jmd0OyBOYWxpbmkgRWxraW5zPGJyPg0KJmd0OyBJbnNpZGUgUHJvZHVjdHMsIEluYy48YnI+ DQomZ3Q7ICg4MzEpIDY1OS04MzYwPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3Lmlu c2lkZXRoZXN0YWNrLmNvbSI+d3d3Lmluc2lkZXRoZXN0YWNrLmNvbTwvYT48YnI+DQomZ3Q7 IDxicj4NCiZndDsgRnJvbTogTWFyayBTbWl0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmt6 enpzbWl0aEB5YWhvby5jb20uYXUiPm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU8L2E+Jmd0 Ozxicj4NCiZndDsgVG86IE5hbGluaSBFbGtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpuYWxp bmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbSI+bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVz dGFjay5jb208L2E+Jmd0OzsgSm9lIFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hA aXNpLmVkdSI+dG91Y2hAaXNpLmVkdTwvYT4mZ3Q7OyBBbmRyZXcgWW91cnRjaGVua28gJmx0 OzxhIGhyZWY9Im1haWx0bzpheW91cnRjaEBjaXNjby5jb20iPmF5b3VydGNoQGNpc2NvLmNv bTwvYT4mZ3Q7DQo8YnI+DQomZ3Q7IENjOiBJRVRGIHY2b3BzIGxpc3QgJmx0OzxhIGhyZWY9 Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0OyA8YnI+DQom Z3Q7IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDUsIDIwMTMgMTE6NDIgQU08YnI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZWxraW5zLXY2b3BzLWlw djYtaXBpZC1uZWVkZWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDtfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBGcm9tOiBOYWxpbmkgRWxraW5z ICZsdDs8YSBocmVmPSJtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20i Pm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPC9hPiZndDs8YnI+DQomZ3Q7ICZn dDtUbzogSm9lIFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hAaXNpLmVkdSI+dG91 Y2hAaXNpLmVkdTwvYT4mZ3Q7OyBBbmRyZXcgWW91cnRjaGVua28gJmx0OzxhIGhyZWY9Im1h aWx0bzpheW91cnRjaEBjaXNjby5jb20iPmF5b3VydGNoQGNpc2NvLmNvbTwvYT4mZ3Q7DQo8 YnI+DQomZ3Q7ICZndDtDYzogSUVURiB2Nm9wcyBsaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86 djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDsgPGJyPg0KJmd0OyAmZ3Q7 U2VudDogV2VkbmVzZGF5LCA2IEZlYnJ1YXJ5IDIwMTMgNjoyOCBBTTxicj4NCiZndDsgJmd0 O1N1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtZWxraW5zLXY2b3BzLWlw djYtaXBpZC1uZWVkZWQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Sm9lLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 O1dlbGwsIGR1cGxpY2F0ZSBwYWNrZXRzIGFyZSBvZnRlbiByZXRyYW5zbWlzc2lvbnMuIDxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlz IGNhbiBiZSBxdWl0ZSBlYXNpbHkgZGV0ZXJtaW5lZCBieSBjb21wYXJpbmcgc2VudCBwYWNr ZXQgY291bnRzIGF0IG9uZSBlbmQgd2l0aCByZWNlaXZlZCBwYWNrZXQgY291bnRzIGF0IHRo ZSBvdGhlci4gSSdkIGNvbnNpZGVyIGRvaW5nIHRoYXQgdG8gYmUgbXVjaCBlYXNpZXIgdGhh biBjYXB0dXJpbmcgMTAwMHMgb2YgcGFja2V0cyBhbmQgdGhlbiBsb29raW5nIHRocm91Z2gg dGhlbSB3aXRoIGFuIGFuYWx5c2VyIHRvIHRyeSB0byBzcG90DQogZHVwbGljYXRlIHBhY2tl dHMuIEkgY29uc2lkZXIgdXNpbmcgYSBwYWNrZXQgYW5hbHlzZXIgdG8gYmUgYSBsYXN0IHJl c29ydCB3aGVuIHRyb3VibGVzaG9vdGluZyBiZWNhdXNlIHlvdSdyZSB1c3VhbGx5IGRlYWxp bmcgd2l0aCAxMDAwcywgMTAgMDAwcyBvciAxMDAgMDAwcyBvZiBwYWNrZXRzLCBhbmQgdHJ5 aW5nIHRvIHNwb3QgYSB0cmVuZCBvciBwaWNrIHRoZSBiYWQgaW5kaXZpZHVhbCBwYWNrZXQu IEl0IGNhbiBhbHNvIGJlIHF1aXRlIG9uZXJvdXMNCiB0byBzZXR1cCB0aGUgcGFja2V0IGNh cHR1cmUgYW5kIHRoZSB2b2x1bWUgb2YgZGF0YSBjYW4gaHVnZS48YnI+DQomZ3Q7IDxicj4N CiZndDsgU29tZSBvZiB0aGVzZSBleGFtcGxlcyBhcmUgc3RhcnRpbmcgc291bmQgbGlrZSB5 b3UndmUgYmVlbiB0YWtpbmcgdGhlIGFwcHJvYWNoIG9mICZxdW90O2hvdyBjYW4gd2UgdXNl IElQSUQgdG8gdHJvdWJsZXNob290IHRoaXMmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7d2hh dCBpcyB0aGUgbW9zdCBlZmZlY3RpdmUgdG9vbCB0byB0cm91Ymxlc2hvb3QgdGhpcyZxdW90 Oywgb2Ygd2hpY2ggSVBJRCBtaWdodCBiZSBvbmUgZm9yIGEgcGFydGljdWxhciBzaXR1YXRp b24uDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyBJZiB5b3UgaGF2ZSByZXRyYW5zbWlzc2lvbnMsIHRoZW4gdGhlIG90 aGVyIGVuZCAob3IgdGhlIG5ldHdvcmspIGlzIG5vdCBhYnNvcmJpbmcgdGhlIGZsb3cgcHJv cGVybHkuJm5ic3A7IFRoZW4sIG9uIG91ciBlbmQsIHdlIG5lZWQgdG8gc2VlIGlmIHdlIGhh dmUgYWxsb2NhdGVkIGVub3VnaCBiYW5kd2lkdGgsIGl0IGlzIGdvaW5nIG92ZXIgYSBzdWIt b3B0aW1hbCByb3V0ZSwgZXRjLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDtUaGFu a3MsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7TmFsaW5p IEVsa2luczxicj4NCiZndDsgJmd0O0luc2lkZSBQcm9kdWN0cywgSW5jLjxicj4NCiZndDsg Jmd0Oyg4MzEpIDY1OS04MzYwPGJyPg0KJmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cDovL3d3dy5p bnNpZGV0aGVzdGFjay5jb20iPnd3dy5pbnNpZGV0aGVzdGFjay5jb208L2E+PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgRnJvbTogSm9l IFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hAaXNpLmVkdSI+dG91Y2hAaXNpLmVk dTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7VG86IEFuZHJldyBZb3VydGNoZW5rbyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmF5b3VydGNoQGNpc2NvLmNvbSI+YXlvdXJ0Y2hAY2lzY28uY29tPC9h PiZndDsNCjxicj4NCiZndDsgJmd0O0NjOiBOYWxpbmkgRWxraW5zICZsdDs8YSBocmVmPSJt YWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20iPm5hbGluaS5lbGtpbnNA aW5zaWRldGhlc3RhY2suY29tPC9hPiZndDs7IElFVEYgdjZvcHMgbGlzdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+ DQomZ3Q7ICZndDtTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA1LCAyMDEzIDEwOjI1IEFNPGJy Pg0KJmd0OyAmZ3Q7U3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1lbGtp bnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRlZDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDtQUyAtIEknbSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBhbiBleHBsYW5hdGlvbiBv ZiB3aHkgZHVwbGljYXRlIDxicj4NCiZndDsgJmd0O3BhY2tldHMgd291bGQgYmUgYW4gaW5k aWNhdGlvbiBvZiBjb25nZXN0aW9uLCBGV0lXLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0O0pvZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O09uIDIvNS8yMDEzIDEwOjIw IEFNLCBKb2UgVG91Y2ggd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBIaSwgQW5kcmV3LDxi cj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgY29tcGxldGVseSBhZ3Jl ZTsgSSBsb29rIGZvcndhcmQgdG8gYSBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbS48YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBKb2U8YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPbiAyLzUvMjAxMyA5OjIyIEFNLCBBbmRyZXcgWW91 cnRjaGVua28gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgTmFsaW5pLCBKb2UsPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIHR3by1t YWlsIGV4Y2hhbmdlIHZpdmlkbHkgaWxsdXN0cmF0ZXMgd2h5IGl0J3MgYmVuZWZpY2lhbCB0 bzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGRlc2NyaWJlIHRoZSBwcm9ibGVtIGJldHRlciwg YW5kIHRoZSBwcm9wZXJ0aWVzIG9mIHRoZSBpZGVhbCBzb2x1dGlvbjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IChzdGFydGluZyB3aXRoIHRoYXQgb2YgSVAgSUQsIGJ1dCBub3QgbmVjZXNz YXJpbHkgbGltaXRlZCB0byBpdCksIGJ1dDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IG5vdCBq dW1wIHRvIHNvbHV0aW9ucyB0aGVtc2VsdmVzIHN0cmFpZ2h0IGF3YXkuPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBPdGhlcndpc2UgaXQncyB0b28g ZWFzeSB0byBnZXQgaW50byBhIHNpdHVhdGlvbiBvZiBhIGZpc2ggYW5kIGEgZ3VsbDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IGFyZ3VpbmcgYWJvdXQgdGhlIHNlYSB3YXRlci48YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IC0tYTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyBPbiBUdWUsIDUgRmViIDIwMTMsIE5hbGluaSBFbGtpbnM8YnI+DQomZ3Q7IHdyb3Rl Ojxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IENv bXBhcmluZyBoYXNoZXMgb3IgcGFja2V0cyBpcyBub3QgcmVhbGx5IGEgd29ya2FibGUgc29s dXRpb24gYmVjYXVzZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGVyZSBjYW4gYmUg dHJ1ZSBkdXBsaWNhdGUgcGFja2V0cy4mbmJzcDsgQSBoYXNoIHdpbGwgb25seSBzaG93IGlm PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBwYWNrZXRzIGFyZSB0aGUgc2FtZS4m bmJzcDsgVW5sZXNzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcuJm5ic3A7IFNvbWV0aW1lczxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGUgcHJvYmxlbSB3ZSBhcmUgdHJ5aW5nIHRv IGRpYWdub3NlIGlzIGhvdyBtYW55IGR1cGxpY2F0ZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgdGhlcmUgYXJlLiZuYnNwOyBUaGlzIGlzIGFuIGluZGljYXRpb24gb2YgY29uZ2Vz dGlvbi4mbmJzcDsgU29tZSBkZXZpY2VzIGNyZWF0ZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyAnZmFsc2UnIGR1cGxpY2F0ZXMuJm5ic3A7IFRoYXQgaXMgYSBwYWNrZXQgdHJhY2Ug dGFrZW4gYXQgdGhhdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBwb2ludCB3aWxsIHNo b3cgdGhhdCB0aGUgcGFja2V0IGlzIHRoZSBzYW1lIGJ1dCBpdCBpcyBvbmx5IHRoZSBkZXZp Y2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb3IgdGhlIHRyYWNlIG1lY2hhbmlzbSB0 cmFjaW5nIGluY29ycmVjdGx5LiZuYnNwOyBCZWxpZXZlIG1lLCB0aGlzPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IGlzIG5vdCBhbiBpbmZyZXF1ZW50IHByb2JsZW0uPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg TmFsaW5pIEVsa2luczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJbnNpZGUgUHJvZHVj dHMsIEluYy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgKDgzMSkgNjU5LTgzNjA8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pbnNpZGV0aGVz dGFjay5jb20iPnd3dy5pbnNpZGV0aGVzdGFjay5jb208L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogSm9lIFRv dWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hAaXNpLmVkdSI+dG91Y2hAaXNpLmVkdTwv YT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBOYWxpbmkgRWxraW5zICZs dDs8YSBocmVmPSJtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20iPm5h bGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgQ2M6IEFuZHJldyBZb3VydGNoZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmF5b3VydGNoQGNpc2NvLmNvbSI+YXlvdXJ0Y2hAY2lzY28uY29tPC9hPiZndDs7IElFVEYg djZvcHMgbGlzdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDUsIDIwMTMgODo1MCBB TTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcg ZHJhZnQ6PGJyPg0KJmd0OyBkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRlZDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBG V0lXLCB0aGVyZSBhcmUgdHdvIG9idmlvdXMgc29sdXRpb25zIHRoYXQgd29yayBmb3IgYm90 aCBJUHY0IGFuZCBJUHY2Ojxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyAxKSBzZW5kIGZyYWdtZW50ZWQgKG9yIGZyYWdtZW50YWJsZSkg cGFja2V0czxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgcHJlc3Vt aW5nIHlvdSBoYXZlIGNvbnRyb2wgb3ZlciBhIHNvdXJjZTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAyKSBjb21wYXJlIGVpdGhlciBm dWxsIHBhY2tldHMgb3IgaGFzaGVzIG9mIHRoZSBmdWxsIHBhY2tldHM8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7Y29udmVu aWVuY2UmcXVvdDsgb2YgYW4gZXhpc3RpbmcgZmllbGQgdGhhdCBpcyBub3QgYWx3YXlzIGF2 YWlsYWJsZSBpc24ndDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhIHNvbHV0aW9uLjxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBK b2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgJmd0O3Y2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OzxhIGhy ZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHM8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHY2b3BzIG1haWxp bmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9w c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4NCjxicj4NCi0tPGJyPg0K JnF1b3Q7SGF2ZSB5b3UgZ290IGFueSBwcmV2aW91cyBjb252aWN0aW9ucz8mcXVvdDs8YnI+ DQo8YnI+DQomcXVvdDtXZWxsLCBJIGR1bm5vLi4uIEkgc3VwcG9zZSBJIHVzZWQgdG8gYmVs aWV2ZSB2ZXJ5IGZpcm1seSB0aGF0IGEgcGVubnkgc2F2ZWQgaXMgYSBwZW5ueSBlYXJuZWQt LSZxdW90Ozxicj4NCi0tIFRlcnJ5IFByYXRjaGV0dDxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQoKCjxCUj4KPGh0bWw+CiA8cD5U aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdo bHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3Ig ZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBv ZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3Nh Z2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGllcy48L3A+CiA8cD5CbHVlIENyb3NzIEJsdWUg U2hpZWxkIG9mIE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBh cmUgbm9ucHJvZml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9m IHRoZSBCbHVlIENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlvbi48L3A+CiAgPC9o dG1sPgoK --_000_4FC37E442D05A748896589E468752CAA0A0E7F17PWN401EA160entc_-- From cb.list6@gmail.com Wed Feb 6 09:15:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96A521F8995 for ; Wed, 6 Feb 2013 09:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb1ZePsf8EOb for ; Wed, 6 Feb 2013 09:15:22 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id BDE9721F8633 for ; Wed, 6 Feb 2013 09:15:21 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n3so1397305lbo.34 for ; Wed, 06 Feb 2013 09:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=/rDReX3T3K3q13XUSFlOlFrPuBJ8jyRBSDIxrBiQxEE=; b=fAuxz1d37PjgPWzC6Bsm+9fpXNphDr0sR2NJkPEcQHrxlka4Ho0sxv9nVj0edhnADD GvEMftAZapsTU9q6Jdm+1xzraLOCpDTOSZs4Nt2BZmaRLnC/qxxgoK4lcP2kkFU1GVx9 hRJst/k59MN6MlmV1A3Dk1Kc5qC41QK6YfCSX8hSiTKoVrGtqk/AnndhJRRNz+2yjP3y S7HL24TIS6GSZVu9DmyedItKqmgUEdQAdou17Q0n1i49jCdtAxzNXZKqTYnjFO7EsK6q Jyfc0nbLHB6/u5kD8jaeLZTKrUR7stLpvQsi/6frbPhad72XKAjA2szEPcczYZv4ApRc jziA== MIME-Version: 1.0 X-Received: by 10.112.17.108 with SMTP id n12mr11135301lbd.21.1360170920586; Wed, 06 Feb 2013 09:15:20 -0800 (PST) Received: by 10.112.7.165 with HTTP; Wed, 6 Feb 2013 09:15:20 -0800 (PST) Date: Wed, 6 Feb 2013 09:15:20 -0800 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops-chairs@tools.ietf.org" , IPv6 Operations Subject: [v6ops] More ranting on mobile ... Was Re: Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 06 Feb 2013 17:15:25 -0000 Rajiv, On Wed, Feb 6, 2013 at 7:48 AM, Rajiv Asati (rajiva) wrote: > > I agree with Ales to translation being better in mobile environment. > > Overall, I do think that if 464XLAT were to be "informational", then we > would be better off. > > Also, let's not forget that there is MAP-T as well - all about > translation. :-) The challenge in all of this is that the UE needs to be > mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE > dependency. > Ack, it is a HUGE dependency. And, it has been a huge surprise to me that changing the host is easier than changing the app. But, that seems to be an axiom now. Roll with it. Who in 2001 thought that Skype, a top 10 android app for peer to peer multimedia communication, would adamantly and openly oppose supporting IPv6 in 2013 [1]. But, if you are looking for beauty contest.... The relevant data point is that there is open source code available for 464XLAT. And, a working integration with a mobile network. There is also a known multi-vendor inter-op documented by an amateur [2] The open source code has be merged into a relevant mobile operating systems https://android-review.googlesource.com/#/c/34490/ Look for it on a phone near you RSN :) Hearkening back to this mail http://www.ietf.org/mail-archive/web/v6ops/current/msg15116.html We need more practical solutions, or *A* solution, and less vaporware beauty contest. As a network operator, i look for solutions that are ready to ship. For mobile networks, here is a run down of the solutions: 1. Dual-stack IPv4v6 PDP in 3GPP remains a bridge too far, MAJOR network gear providers don't support it on NEW gear (which also blows my mind, THIS IS NOT A LEGACY PROBLEM, YMMV) 2. IPv6-only + NAT64/DNS64, works but it is only a a 90% solution because Skype and Neflix don't work 3. MAP-T / MAP-E, show it working on a mobile. 4. 464XLAT let me show you it working on mobile, or do it yourself [3] 5. NAT44, this is the vastly most common choice for all GSM / UMTS/ LTE networks. Why? Because 1 - 4 aren't shipping yet. 464XLAT is close. CB [1] http://mailman.nanog.org/pipermail/nanog/2012-December/053918.html [2] https://sites.google.com/site/tmoipv6/464xlat (have not looked at this in a year) [3] http://dan.drown.org/android/clat/ From markzzzsmith@yahoo.com.au Wed Feb 6 11:50: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 D204221F88B6 for ; Wed, 6 Feb 2013 11:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39NwXvui9RuE for ; Wed, 6 Feb 2013 11:50:30 -0800 (PST) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 84E3D21F88B4 for ; Wed, 6 Feb 2013 11:50:30 -0800 (PST) Received: from [98.139.215.142] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 19:50:29 -0000 Received: from [98.139.212.210] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 19:50:29 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 06 Feb 2013 19:50:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 691875.78925.bm@omp1019.mail.bf1.yahoo.com Received: (qmail 95321 invoked by uid 60001); 6 Feb 2013 19:50:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360180229; bh=LLJN4GJuEMyseEKvX85ROA24l3gHAH44UwRuAfNq0Kg=; 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=JDtEnMhTHU7uEEr4De0cXXVuecRpBHsXRkVOrPcT8SkJz4HlA/t8kyGr7Ckv05WUj7EwT9Np8b9iErHR44tn4CWLwQ3zezTuPKpm7DMOkT4IpqmfBN50+Nl3qLCczu3AiBoMRNiYzFvHEOCgSU+7v0OZ2c4jXob/fVxD/S4dfks= 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=EsPpNSgc7F8VD1VPdy8y3w78Rvu8ls+K1jjDeCQI27wsj/PPDoLLt1awZWPWdmumFI5tL+g9fX8Yw82V8lZZ8EdR6CfRprAmf3dYzrfjO5l0fLWVvoYiyQM3fm6u+qNF+la6Vit+WhxjTBB8QJtRhTZweb6ppUfK9lrtmKIj7ec=; X-YMail-OSG: x42Yf8AVM1n4WGtUS8PrFKfptHRboXckJl3iUW938DFzhJF pljIfe5Qwlw5Xu1pTy_UI36y0hLpuJNlvFbydI0trbcxCorY6.nT4aQR8xxW tiGBzhgy8YZ0N6uPhWgyiJXBnCIzRCAgm24Rx1ykmwyTibeNlzYsc9HBSCae rDQS_1MfW1rmIfyPPnK5lXlyq9C7pAzmAeQ_l9U1xU3rtlhJRc0s.t9SOsoq t8PcKdETA.lpg_T.erTNSvYrIYFyrxWB1jsoOpPukJ.2FL.fNp1rj5pt5t.M CtrTwdzM6c6MaG5ky8frpuv_v_6df1NzeIZ9MyPdUqjTkNq63gRREDZaT5XY EfBNeqv8rhysNw7b__I4jWrHwviMCE33VZMokAICLb5ArM2w2zmL5owUYetZ BYPwlOw7IMJaaz93YmhP7jhdCV4wIz9LENwRr9CEyIVk8VX9GdUTyK.2WJJ8 AZw_9LmeJcxtasmbqeIyi8pEUythfZxezB0IFcmvQiMaEtdS4MTOvlQH4VJN jCMMQobUDrnVXtZ5Y.5cwWAGasSIlqvi5eYvuZ10OeT8tTr68o21ASesBKOG UUAmTI0vG8dnmAQavPn8.pXKaWGFHlTH1uLZnMT8bKA-- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Wed, 06 Feb 2013 11:50:29 PST X-Rocket-MIMEInfo: 001.001, Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IE5hbGluaSBFbGtpbnMgPG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPgo.VG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU.OyBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT4gCj5DYzogSUVURiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBXZWRuZXNkYXksIDYgRmVicnVhcnkgMjAxMyA2OjUzIEFNCj5TdWIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <201302021345.r12Dj1k02256@ftpeng-update.cisco.com> <4FC37E442D05A748896589E468752CAA0A0DDD2E@PWN401EA160.ent.corp.bcbsm.com> <4160CF5F-7DD8-4244-87A5-0D2CBEFFF55C@kumari.net> <4FC37E442D05A748896589E468752CAA0A0DE983@PWN401EA160.ent.corp.bcbsm.com> <5110AE3A.6020201@bogus.com> <5110B40A.3080008@isi.edu> <1360081317.11297.YahooMailNeo@web2807.biz.mail.ne1.yahoo.com> <51113872.6010603@isi.edu> <1360083378.11374.YahooMailNeo@web2813.biz.mail.ne1.yahoo.com> <51114D8A.4010901@isi.edu> <51114E80.1090804@isi.edu> <1360092539.13968.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1360093345.42487.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1360094003.76755.YahooMailNeo@web2811.biz.mail.ne1.yahoo.com> Message-ID: <1360180229.90713.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Wed, 6 Feb 2013 11:50:29 -0800 (PST) From: Mark Smith To: Nalini Elkins , Joe Touch , Andrew Yourtchenko In-Reply-To: <1360094003.76755.YahooMailNeo@web2811.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 19:50:32 -0000 =0A>________________________________=0A> From: Nalini Elkins =0A>To: Mark Smith ; Joe Tou= ch ; Andrew Yourtchenko =0A>Cc: IETF v6= ops list =0A>Sent: Wednesday, 6 February 2013 6:53 AM=0A>S= ubject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A> =0A>= =0A>Mark,=0A>=0A>=0A>Tools are a different topic.=0A=0AI don't think they a= re. You are proposing changes to IPv6 to suit troubleshooting and troublesh= ooting tools, and nothing more. Your changes make no improvements to the pe= rformance or utility of the protocol when it is operating and being used co= rrectly. Networks run well most of the time (when built with devices that c= omply with the specifications), so the threshold of acceptance for fundamen= tal changes that just benefit troubleshooting to the already deployed imple= mentations of protocols is going to be high.=0A=0A> =A0A number of companie= s, including mine, have intelligent packet analyzers. =A0 For us, there is = nothing our products like better than thousands of packets that we can read= in and then help the customer to pinpoint problems to the exact packet.=0A= =0ADo you give those packet analysers away for free? The tools I commonly u= se (ping and traceroute) are free.=A0=0A=0AChange creates opportunities for= failure. Changing a device to perform traffic mirroring, or inserting a pa= cket analyser inline with traffic may or will disrupt services. In a proper= ly run network, these changes will have to be done during a scheduled maint= enance window of some form. In the case of enabling traffic mirroring, cons= idering what it is asking the device to do, considering the volume of traff= ic it might be asked to mirror, and how different it is from it's normal op= eration, there is a reasonable risk the device will fail when it is enabled= , causing a service outage. So the safe thing to do is make these changes o= utside of core operating hours. At a residential ISP that was between 5.30 = am and 6.30 am. Organising that=A0is onerous, even if you give me one of yo= ur packet analysers for free. I'm going to try to use my free tools and one= s that don't require any changes to the operation of my devices or my netwo= rk, and no scheduled maintenance window, before I'm going to resort to change management procedures and out= of hours work. I'm sure my users want that too, because I can diagnose the= ir problem sooner, reducing the mean time to repair for the fault.=0A=0A> = =A0This is the trend of the future. =A0The volume of data and packets soon = outpaces what we mere humans can do.=0A=0AThat's always been the case for m= e. I can't even process 300 baud at line rate.=0A=0A=A0> We need a partners= hip between intelligent tools and intelligent humans.=0A>=0A>=0A>I would ac= tually love to have a discussion at some point on best practices in trouble= shooting. =A0 Our ultimate goal is to have the right performance and troubl= eshooting metrix built right into the protocols from the get-go!=0A>=A0=0A= =0AThe get-go for IPv6 was in the mid 1990s.=0A=0AYourself and others seem = to be assuming that it is impossible to troubleshoot IP networks without IP= ID, in particular with statements such as :=0A=0A"Our main issue is that in= formation such as provided by IPID can be critical to reliably running soph= isticated networks today."=0A=0A=0AYet if IPID was the only way to troubles= hoot these problems, it wouldn't be a new technique to me (it'd have been t= aught to me when I learned ping and traceroute), and I have and do work on = "sophisticated networks" that have had critical reliability requirements. I= PID isn't as essential as it is being made out to be.=0A=0A>Thanks,=0A>=0A>= =0A>Nalini Elkins=0A>Inside Products, Inc.=0A>(831) 659-8360=0A>www.insidet= hestack.com=0A>=0A>=0A>=0A>________________________________=0A> From: Mark = Smith =0A>To: Nalini Elkins ; Joe Touch ; Andrew Yourtchenko =0A>Cc: IETF v6ops list =0A>Sent: Tuesday, Februar= y 5, 2013 11:42 AM=0A>Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ip= v6-ipid-needed=0A> =0A>=0A>=0A>=0A>=0A>=0A>>_______________________________= _=0A>> From: Nalini Elkins =0A>>To: Joe T= ouch ; Andrew Yourtchenko =0A>>Cc: IETF= v6ops list =0A>>Sent: Wednesday, 6 February 2013 6:28 AM= =0A>>Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-needed=0A= >> =0A>>=0A>>Joe,=0A>>=0A>>=0A>>Well, duplicate packets are often retransmi= ssions.=A0=0A>>=0A>>=0A>=0A>This can be quite easily determined by comparin= g sent packet counts at one end with received packet counts at the other. I= 'd=0Aconsider doing that to be much easier than capturing 1000s of packets = and then looking through them with an analyser to try to spot duplicate pac= kets. I consider using a packet analyser to be a last resort when troublesh= ooting because you're usually dealing with 1000s, 10 000s or 100 000s of pa= ckets, and trying to spot a trend or pick the bad individual packet. It can= also be quite onerous to setup the packet capture and the volume of data c= an huge.=0A>=0A>Some of these examples are starting sound like you've been = taking the approach of "how can we use IPID to troubleshoot this" rather th= an "what is the most effective tool to troubleshoot this", of which IPID mi= ght be one for a particular situation.=A0=0A>=0A>>=0A>>=0A>>=A0 If you have= retransmissions, then the other end (or the network) is not absorbing the = flow properly. =A0Then, on our end, we need to see if we have allocated eno= ugh bandwidth, it is going over a sub-optimal route,=0Aetc.=0A>>=A0=0A>>Tha= nks,=0A>>=0A>>=0A>>Nalini Elkins=0A>>Inside Products, Inc.=0A>>(831) 659-83= 60=0A>>www.insidethestack.com=0A>>=0A>>=0A>>=0A>>__________________________= ______=0A>> From: Joe Touch =0A>>To: Andrew Yourtchenko =0A>>Cc: Nalini Elkins ;= IETF v6ops list =0A>>Sent: Tuesday, February 5, 2013 10:2= 5 AM=0A>>Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-ipid-neede= d=0A>> =0A>>PS - I'm particularly=0Ainterested in an explanation of why dup= licate =0A>>packets would be an indication of congestion, FWIW.=0A>>=0A>>Jo= e=0A>>=0A>>On 2/5/2013 10:20 AM, Joe Touch wrote:=0A>>> Hi, Andrew,=0A>>>= =0A>>> I completely agree; I look forward to a description of the problem.= =0A>>>=0A>>> Joe=0A>>>=0A>>> On 2/5/2013 9:22 AM, Andrew Yourtchenko wrote:= =0A>>>> Nalini, Joe,=0A>>>>=0A>>>> This two-mail exchange vividly illustrat= es why it's beneficial to=0A>>>> describe the problem better, and the prope= rties of the ideal solution=0A>>>> (starting with that of IP ID, but not ne= cessarily limited to it), but=0A>>>> not jump to solutions themselves strai= ght away.=0A>>>>=0A>>>> Otherwise it's too easy to get into a situation of = a fish and a gull=0A>>>> arguing about the sea water.=0A>>>>=0A>>>>=0A--a= =0A>>>>=0A>>>>=0A>>>> On Tue, 5 Feb 2013, Nalini Elkins=0A>wrote:=0A>>>>=0A= >>>>> Comparing hashes or packets is not really a workable solution because= =0A>>>>> there can be true duplicate packets.=A0 A hash will only show if= =0A>>>>> the packets are the same.=A0=A0=A0Unless I am missing something.= =A0=A0=A0Sometimes=0A>>>>> the problem we are trying to diagnose is how man= y duplicates=0A>>>>> there are.=A0 This is an indication of congestion.=A0= =A0=A0Some devices create=0A>>>>> 'false' duplicates.=A0 That is a packet t= race taken at that=0A>>>>> point will show that the packet is the same but = it is only the device=0A>>>>> or the trace mechanism tracing incorrectly.= =A0 Believe me, this=0A>>>>> is not an infrequent problem.=0A>>>>>=0A>>>>>= =0AThanks,=0A>>>>>=0A>>>>> Nalini Elkins=0A>>>>> Inside Products, Inc.=0A>>= >>> (831) 659-8360=0A>>>>> www.insidethestack.com=0A>>>>>=0A>>>>> _________= ___________________________________________________________________________= _______________________________________________________=0A>>>>>=0A>>>>>=0A>= >>>> From: Joe Touch =0A>>>>> To: Nalini Elkins =0A>>>>> Cc: Andrew Yourtchenko ;= IETF v6ops list=0A>>>>> =0A>>>>> Sent: Tuesday, February 5= , 2013 8:50 AM=0A>>>>> Subject: Re: [v6ops] new draft:=0A>draft-elkins-v6op= s-ipv6-ipid-needed=0A>>>>>=0A>>>>> FWIW, there are two obvious solutions th= at work for both IPv4 and IPv6:=0A>>>>>=0A>>>>> 1) send fragmented (or frag= mentable) packets=0A>>>>>=A0 =A0=A0=A0presuming you have control over a sou= rce=0A>>>>>=0A>>>>> 2) compare either full packets or hashes of the full pa= ckets=0A>>>>>=0A>>>>> "convenience" of an existing field that is not always= available isn't=0A>>>>> a solution.=0A>>>>>=0A>>>>> Joe=0A>>>>>=0A>>>>>=0A= >>>>>=0A>>>>>=0A>>=0A>>=0A>>=0A>>__________________________________________= _____=0A>>v6ops mailing list=0A>>v6ops@ietf.org=0A>>https://www.ietf.org/ma= ilman/listinfo/v6ops=0A>>=0A>>=0A>>=0A>=0A>=0A>=0A>=0A> From ales.vizdal@t-mobile.cz Wed Feb 6 13:53: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 BA6DD21F855F for ; Wed, 6 Feb 2013 13:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb32+nHpLnkQ for ; Wed, 6 Feb 2013 13:53:19 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5EF21F8470 for ; Wed, 6 Feb 2013 13:53:19 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 772D2285800; Wed, 6 Feb 2013 22:53:17 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 6 Feb 2013 22:53:17 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "Rajiv Asati (rajiva)" , Ole Troan , joel jaeggli Date: Wed, 6 Feb 2013 22:54:09 +0100 Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBIFcg7Qzvwn0bkCMyeeF78VjuZhtRnoA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 06 Feb 2013 21:53:19 -0000 Rajiv, Guys, > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Wednesday, February 06, 2013 4:48 PM > To: V=EDzdal Ale=B9; Ole Troan; joel jaeggli > Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful a= ndStateless > Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >=20 > I agree with Ales to translation being better in mobile environment. Thanks, the industry needs a shipping solution soon as dual-stack is not so= lving the ipv4 exhaustion problem (that's why I believe it's taking so much time = to introduce it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze ipv6 int= roduction. > Overall, I do think that if 464XLAT were to be "informational", then we > would be better off. BCP will give the industry the signal what to support ... this is not clear= to them yet.=09 > Also, let's not forget that there is MAP-T as well - all about > translation. :-) The challenge in all of this is that the UE needs to be > mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE > dependency. btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IPR'd by= =20 ChinaMobile as well claiming the same patent as for 464xlat. Given that MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat=20 are equal from this point of view, but 464xlat is more advanced as there=20 is a running code available (at lest for android) and this is something tha= t=20 should really matter to the IETF. > Cheers, > Rajiv PS. To my experience the business is not taking the best / nicest solution available, but the one that fits the business the best. Cheers, Ales From rogaglia@cisco.com Wed Feb 6 14:27: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 3A6D521F8645 for ; Wed, 6 Feb 2013 14:27:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vap-+Fbol552 for ; Wed, 6 Feb 2013 14:27:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 512A921F862A for ; Wed, 6 Feb 2013 14:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4012; q=dns/txt; s=iport; t=1360189632; x=1361399232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JUd78ySrSHdx2T7O+8oADRINxxlAAE3GF0PsLRHuglE=; b=Zk5ZFgbEB22Doz5vYUGzJfNnEv60pCd6ab6J6zxhHBP7PBEIamRFiKat r9x3xQHlk5ofoI8HBmW1pnJ+KQ+nXGUqugzjqD0kByos+3SfdlG4fWlwy Ja6sWgtQEOJ0Q3OnmdRvZUBofgEtEBIPTAlkWMKWWQUTvujuIoym9UN6M w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGHXElGtJXG9/2dsb2JhbABFg3i8WBZzgh8BAQEDAQEBATc0BgMCBQcEAgEIDgMBAgECCxQQJwsXBggCBA4FCAESh3AGBwW8bpB4YQOXPo81gn6CJA X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208";a="173992709" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 06 Feb 2013 22:27:11 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r16MRBhg003085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Feb 2013 22:27:11 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.64]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 16:27:11 -0600 From: "Roque Gagliano (rogaglia)" To: Arturo Servin Thread-Topic: [v6ops] New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt Thread-Index: AQHOBLka8XMCp+cnrEmaQd8N8wUZlQ== Date: Wed, 6 Feb 2013 22:27:10 +0000 Message-ID: References: <20130205215743.30106.77867.idtracker@ietfa.amsl.com> <5111A72B.2000804@lacnic.net> In-Reply-To: <5111A72B.2000804@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.108.42] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 22:27:13 -0000 Hi Arturo, Thanks for the update. Without reading the document in detail, I was wondering why do you think it= should be published as "Standards Track". This WG published similar docume= nts (such as RFC 5963) as Informational. Regards, Roque On Feb 6, 2013, at 1:43 AM, Arturo Servin wrote: > Hi, >=20 > We have submitted a new version of draft-lopez-v6ops-dc-ipv6-04. Some > of the changes we made: >=20 > - We expanded the security section as suggested in the list. We included > the attacks and security issues that we considered more important in DC > infrastructure. Please let us know if you wanted to see more, or if some > need to be expanded. > - We added a new section "Other Operational Considerations" and we > included topics such as Addressing, Cost and Monitoring/Management. If > it want to include more topics let us know. > - We re-organized some text in the introduction to be now under a > renamed section "Architecture and Transition Stages" > - We added text suggesting how to start moving applications to IPv6 > within the DC > - We added some text to explaining the motivations from moving from > Dual-stack to IPv6-only as suggested in the list > - We changed some text to improve reading as suggested by some people > off-list > - We fixed some typos > - We updated some references > - And we added a new author >=20 > And I think that is all. >=20 > Please let us know your comments. >=20 > Best regards > as >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt > Date: Tue, 05 Feb 2013 13:57:43 -0800 > From: internet-drafts@ietf.org > To: aservin@lacnic.net > CC: tina.tsou.zouting@huawei.com, diego@tid.es, cathy.zhou@huawei.com, > 18918588897@189.cn >=20 >=20 > A new version of I-D, draft-lopez-v6ops-dc-ipv6-04.txt > has been successfully submitted by Arturo Servin and posted to the > IETF repository. >=20 > Filename: draft-lopez-v6ops-dc-ipv6 > Revision: 04 > Title: IPv6 Operational Guidelines for Datacenters > Creation date: 2013-02-05 > WG ID: Individual Submission > Number of pages: 20 > URL: > http://www.ietf.org/internet-drafts/draft-lopez-v6ops-dc-ipv6-04.txt > Status: http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv= 6 > Htmlized: http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-04 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-lopez-v6ops-dc-ipv6-04 >=20 > 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. >=20 > 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 DC > infrastructure. >=20 > 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. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Wed Feb 6 18:17: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 B611A21F8481 for ; Wed, 6 Feb 2013 18:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoxgksXGoYYj for ; Wed, 6 Feb 2013 18:17:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5D09421F8447 for ; Wed, 6 Feb 2013 18:17:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3H3L-000L1i-GB; Thu, 07 Feb 2013 02:17:31 +0000 Date: Wed, 06 Feb 2013 18:17:30 -0800 Message-ID: From: Randy Bush To: Ole Troan In-Reply-To: <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 02:17:35 -0000 > - even in an IPv6 only access network, there are better solutions; > e.g. MAP-E, DS-lite... ds-lite is soooo wonderful. it has all the advantages of nat in the core and having to replace all the cpe. map-e, aka stateless a+p, is about as clean a solution as you're gonna get in this space. and, as you point out, 464xlat is not a really good practice let alone best. and it is encumbered. randy From cb.list6@gmail.com Wed Feb 6 18:49: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 2333521F84F2 for ; Wed, 6 Feb 2013 18:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MziiytnBTLY for ; Wed, 6 Feb 2013 18:49:58 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A97A21F84DC for ; Wed, 6 Feb 2013 18:49:58 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so2126936lab.19 for ; Wed, 06 Feb 2013 18:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BwK15MQyWlPnzWuJ0CsooLqg5PGB5yzBf71EyKYejTI=; b=JYb9Lm/aEv0byqSdUL1ztL7yA2W1wIfoHuVmm+4KAKQV1/lMM8FdlvqdFAA3WZ4kyp YDjkHM65O2GUH/tFcfGvcxFMKjajZuIP9NOHmH6dxomXIirsSQpHTm1e8EYODuL7CVPE FU+rsmU6cSHRtRITTg3afSuZFkvpt3Hprak4uoXajoJplN3RUOpdTQ64IJ1f8Lm1NLNR qj8kTF3QqBvVuYzgnmrNqsdZLlxJlu7emSBZ7UW/bH/rO/Tx0pM9SNCQWTYWTWitF5+p PFYCELetT06W5AJgmg5YQ+y3GSoeT34+3RReMnzYEjwbHXNc3gp3DUbZeRfcYjKmnFMn jF7w== MIME-Version: 1.0 X-Received: by 10.112.38.164 with SMTP id h4mr66668lbk.123.1360205397191; Wed, 06 Feb 2013 18:49:57 -0800 (PST) Received: by 10.112.7.165 with HTTP; Wed, 6 Feb 2013 18:49:56 -0800 (PST) Received: by 10.112.7.165 with HTTP; Wed, 6 Feb 2013 18:49:56 -0800 (PST) In-Reply-To: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> Date: Wed, 6 Feb 2013 18:49:56 -0800 Message-ID: From: Cameron Byrne To: Randy Bush Content-Type: multipart/alternative; boundary=e0cb4efe2f80856daa04d5197f3d Cc: IETF v6ops list Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 02:49:59 -0000 --e0cb4efe2f80856daa04d5197f3d Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Feb 6, 2013 6:17 PM, "Randy Bush" wrote: > > > - even in an IPv6 only access network, there are better solutions; > > e.g. MAP-E, DS-lite... > > ds-lite is soooo wonderful. it has all the advantages of nat in the > core and having to replace all the cpe. > > map-e, aka stateless a+p, is about as clean a solution as you're gonna > get in this space. > Send code > and, as you point out, 464xlat is not a really good practice let alone > best. and it is encumbered. > > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --e0cb4efe2f80856daa04d5197f3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Feb 6, 2013 6:17 PM, "Randy Bush" <randy@psg.com> wrote:
>
> > - even in an IPv6 only access network, there are better solutions= ;
> > =A0 e.g. MAP-E, DS-lite...
>
> ds-lite is soooo wonderful. =A0it has all the advantages of nat in the=
> core and having to replace all the cpe.
>
> map-e, aka stateless a+p, is about as clean a solution as you're g= onna
> get in this space.
>

Send code

> and, as you point out, 464xlat is not a really good pra= ctice let alone
> best. =A0and it is encumbered.
>
> randy
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--e0cb4efe2f80856daa04d5197f3d-- From randy@psg.com Wed Feb 6 18:59: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 37E7E21E8034 for ; Wed, 6 Feb 2013 18:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxJ3oqm2L4nh for ; Wed, 6 Feb 2013 18:59:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AA4E921F8456 for ; Wed, 6 Feb 2013 18:59:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3Hhw-000L8T-Ow; Thu, 07 Feb 2013 02:59:28 +0000 Date: Wed, 06 Feb 2013 18:59:28 -0800 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 02:59:30 -0000 >> map-e, aka stateless a+p, is about as clean a solution as you're gonna >> get in this space. > Send code running at janog https://www.seil.jp/community/node/71 From randy@psg.com Wed Feb 6 19:02: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 1EBFF21F8467 for ; Wed, 6 Feb 2013 19:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXyguR4iGVQ7 for ; Wed, 6 Feb 2013 19:02:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB2321F843F for ; Wed, 6 Feb 2013 19:02:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3Hki-000L9C-Ay; Thu, 07 Feb 2013 03:02:20 +0000 Date: Wed, 06 Feb 2013 19:02:20 -0800 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 03:02:21 -0000 >>> map-e, aka stateless a+p, is about as clean a solution as you're gonna >>> get in this space. >> Send code > > running at janog > > https://www.seil.jp/community/node/71 sorry, wrong url https://www.seil.jp/community/node/97 From cb.list6@gmail.com Wed Feb 6 19:06: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 0862A21F843F for ; Wed, 6 Feb 2013 19:06:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTKeXq0MkNF6 for ; Wed, 6 Feb 2013 19:06:34 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id D012721F8467 for ; Wed, 6 Feb 2013 19:06:33 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id ge1so1775612lbb.15 for ; Wed, 06 Feb 2013 19:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ouUIM5bt/adgy5KIto0zKDCOF18wXJgB8tvaQeNsRC8=; b=T/vddp7Fh2NnWgdyCNxAO0yVJDH9uIYC6hjLw3+k+KqlipXjwXbw23CisYhnbGapH/ g9YAQn+KsztVsePWQLaQIj0KYhToI6O7XitvcxcigkCbSg/FBwyP95iQFIpN+2o6O1P9 K0gnBEWZ659t22rudRIXVb2hTj6nkNyqCETinGvk9J7s3RdHbvLeSgYg8mAh1UIjfJCe 9AHVlJtdgM1+CLvA39V8jAg63wo16WWa2VPz4NtA73k/16/9gPASNyPtmQX8+OueHdrt 8ywoBfuH17LyXmInkorPs5RJGztQvPLONgLKaXGJA7Da5OULHgeGAdiJ/GbDhu+xO29W GrJg== MIME-Version: 1.0 X-Received: by 10.112.38.67 with SMTP id e3mr86583lbk.105.1360206392638; Wed, 06 Feb 2013 19:06:32 -0800 (PST) Received: by 10.112.7.165 with HTTP; Wed, 6 Feb 2013 19:06:32 -0800 (PST) Received: by 10.112.7.165 with HTTP; Wed, 6 Feb 2013 19:06:32 -0800 (PST) In-Reply-To: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> Date: Wed, 6 Feb 2013 19:06:32 -0800 Message-ID: From: Cameron Byrne To: Randy Bush Content-Type: multipart/alternative; boundary=e0cb4efe2c24dabdcd04d519ba03 Cc: IETF v6ops list Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 03:06:35 -0000 --e0cb4efe2c24dabdcd04d519ba03 Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Feb 6, 2013 7:02 PM, "Randy Bush" wrote: > > >>> map-e, aka stateless a+p, is about as clean a solution as you're gonna > >>> get in this space. > >> Send code > > > > running at janog > > > > https://www.seil.jp/community/node/71 > > sorry, wrong url > > https://www.seil.jp/community/node/97 On a 3gpp mobile network? Thought so. CB --e0cb4efe2c24dabdcd04d519ba03 Content-Type: text/html; charset=ISO-8859-1

Sent from ipv6-only Android
On Feb 6, 2013 7:02 PM, "Randy Bush" <randy@psg.com> wrote:
>
> >>> map-e, aka stateless a+p, is about as clean a solution as you're gonna
> >>> get in this space.
> >> Send code
> >
> > running at janog
> >
> > https://www.seil.jp/community/node/71
>
> sorry, wrong url
>
> https://www.seil.jp/community/node/97

On a 3gpp mobile network?

Thought so.

CB

--e0cb4efe2c24dabdcd04d519ba03-- From randy@psg.com Wed Feb 6 19:07:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0083521F84F3 for ; Wed, 6 Feb 2013 19:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0rzunrH0PUs for ; Wed, 6 Feb 2013 19:07:05 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96D21F843F for ; Wed, 6 Feb 2013 19:07:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3HpI-000L9n-K9; Thu, 07 Feb 2013 03:07:04 +0000 Date: Wed, 06 Feb 2013 19:07:04 -0800 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 03:07:06 -0000 >>> Send code >> running at janog > https://www.seil.jp/community/node/97 oops. confession. siel is the cpe which iij ($dayjob) produces. randy From randy@psg.com Wed Feb 6 19:17: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 C886721F8472 for ; Wed, 6 Feb 2013 19:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq6B99JeGORO for ; Wed, 6 Feb 2013 19:17:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4C72621F846E for ; Wed, 6 Feb 2013 19:17:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U3HzM-000LB0-FK; Thu, 07 Feb 2013 03:17:28 +0000 Date: Wed, 06 Feb 2013 19:17:27 -0800 Message-ID: From: Randy Bush To: Cameron Byrne In-Reply-To: References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 03:17:29 -0000 >>> send code >> https://www.seil.jp/community/node/97 > On a 3gpp mobile network? next you're gonna say you don't want it in magenta comic sans :). gimme a break. randy From mawatari@jpix.ad.jp Wed Feb 6 19:21: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 45D4F21E804D for ; Wed, 6 Feb 2013 19:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71z81Nrqqqjg for ; Wed, 6 Feb 2013 19:21:16 -0800 (PST) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6551821F846E for ; Wed, 6 Feb 2013 19:21:16 -0800 (PST) Received: from [192.168.0.230] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id EB3FEFC040; Thu, 7 Feb 2013 12:21:14 +0900 (JST) Date: Thu, 07 Feb 2013 12:21:14 +0900 From: MAWATARI Masataka To: ales.vizdal@t-mobile.cz In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> Message-Id: <20130207122114.B2BB.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Cc: v6ops-chairs@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 03:21:17 -0000 Hi, Thank you all for your comments. * On Wed, 6 Feb 2013 22:54:09 +0100 * Vizdal Ales wrote: > Rajiv, Guys, > > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Wednesday, February 06, 2013 4:48 PM > > To: Vizdal Ales; Ole Troan; joel jaeggli > > Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org > > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless > > Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) > > > > I agree with Ales to translation being better in mobile environment. > > Thanks, the industry needs a shipping solution soon as dual-stack is not solving > the ipv4 exhaustion problem (that's why I believe it's taking so much time to introduce > it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze ipv6 introduction. Excuse me. Today's discussion is not whether a solution is better or not depending on using encap/decap or translation. I believe that it depends on operators and their operating networks, and it is not time to do competition. We are essentially discussing which document category should we adopt for the draft with IPR. (Validity of the IPR is another story) > > Overall, I do think that if 464XLAT were to be "informational", then we > > would be better off. > > BCP will give the industry the signal what to support ... this is not clear to them yet. Yes. > > Also, let's not forget that there is MAP-T as well - all about > > translation. :-) The challenge in all of this is that the UE needs to be > > mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE > > dependency. > > btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IPR'd by > ChinaMobile as well claiming the same patent as for 464xlat. Given that > MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat > are equal from this point of view, but 464xlat is more advanced as there > is a running code available (at lest for android) and this is something that > should really matter to the IETF. I am aware that MAP-T also is IPR'd. Sad. > > Cheers, > > Rajiv > > PS. To my experience the business is not taking the best / nicest solution > available, but the one that fits the business the best. > > Cheers, > Ales > > Kind Regards, Masataka MAWATARI From xing@cernet.edu.cn Wed Feb 6 19:55: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 95A6521E8051 for ; Wed, 6 Feb 2013 19:55:06 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UwXPq6WQung for ; Wed, 6 Feb 2013 19:55:06 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5793421E804E for ; Wed, 6 Feb 2013 19:55:03 -0800 (PST) Received: from [127.0.0.1] (unknown [119.41.192.188]) by centos (Coremail) with SMTP id AQAAf3B7OgVTJRNRIsIIAA--.23711S5; Thu, 07 Feb 2013 11:53:58 +0800 (CST) Message-ID: <51132576.7000200@cernet.edu.cn> Date: Thu, 07 Feb 2013 11:54:30 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3B7OgVTJRNRIsIIAA--.23711S5 X-Coremail-Antispam: 1UD129KBjvdXoWrKFyDXr43Zr18Kr1UKF43GFg_yoWDGrbE9F 9YkFykt3WUXFsrWw15GrnxArW8WrZ3Wr12qrWkXr1fCa4UZr4DJFsrKFnrCF4fK3yxArn8 J3y8u3s5A3y7XjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUjRkFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2z4x0Y4vE2Ix0cI8IcVAFwI 0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AK xVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UM2AIxVAIcxkEcVAq07x20x vEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6I8E87Iv67AKxVWUJVW8JwAm72CE 4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7MxAIw2 8IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWl x4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r 1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j 6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr UvcSsGvfC2KfnxnUUI43ZEXa7VU1gyCJUUUUU== X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: IPv6 Operations , Wojciech Dec , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 03:55:07 -0000 Hi, Vízdal and All, Vízdal AleÅ¡ 写é“: > Rajiv, Guys, > > > > >> Also, let's not forget that there is MAP-T as well - all about >> translation. :-) The challenge in all of this is that the UE needs to be >> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE >> dependency. >> > > btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IPR'd by > ChinaMobile as well claiming the same patent as for 464xlat. Given that > MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat > are equal from this point of view, but 464xlat is more advanced as there > is a running code available (at lest for android) and this is something that > should really matter to the IETF. > > FYI: The stateless double translation (one of the origins of MAP-T) is introduced in Section 5.2 "Double IVI" of http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is published on June 13, 2009, earlier than June 26，2009. Regards, xing From owen@delong.com Wed Feb 6 20:09: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 19F3021E8034 for ; Wed, 6 Feb 2013 20:09:29 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmEhM3uhC7qy for ; Wed, 6 Feb 2013 20:09:28 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 388F121F8501 for ; Wed, 6 Feb 2013 20:09:28 -0800 (PST) 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 r1747xWK002789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Feb 2013 20:07:59 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1747xWK002789 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360210080; bh=MJB1doSeTp5aYD1EIPFZNqUqDk0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lt3BU+xPrw/X5NQekPMG6q0JAg5+QKtpapCyIyU2Di8Xr+bgGKE4Lxx8yiHzI7Z6D a8WqEWO058hk5Xtr9O/41z9784FPIcMhLqUR8UAeuQy4OwW/rZH4T9DkyTWzCQPGFK olW3ED/UZ2B0UfBGxMmXNm0ZvPoZNCl/3tW8a0k4= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> Date: Wed, 6 Feb 2013 20:07:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 06 Feb 2013 20:08:00 -0800 (PST) Cc: "v6ops-chairs@tools.ietf.org" , IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 04:09:29 -0000 On Feb 6, 2013, at 13:54 , V=EDzdal Ale=B9 = wrote: > Rajiv, Guys, >=20 > >=20 >> -----Original Message----- >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >> Sent: Wednesday, February 06, 2013 4:48 PM >> To: V=EDzdal Ale=B9; Ole Troan; joel jaeggli >> Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org >> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of = Stateful andStateless >> Translation' to Best CurrentPractice = (draft-ietf-v6ops-464xlat-09.txt) >>=20 >> I agree with Ales to translation being better in mobile environment. >=20 > Thanks, the industry needs a shipping solution soon as dual-stack is = not solving > the ipv4 exhaustion problem (that's why I believe it's taking so much = time to introduce > it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze = ipv6 introduction. How does IPv4-over-IPv6 do anything that dual-stack doesn't accomplish? Neither one addresses IPv4 exhaustion except to the extent that IPv6 = implementation reduces dependence on IPv4. Owen From dougb@dougbarton.us Wed Feb 6 20:27: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 80F6221E8042 for ; Wed, 6 Feb 2013 20:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr56bsa7jnKv for ; Wed, 6 Feb 2013 20:27:52 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD421E8034 for ; Wed, 6 Feb 2013 20:27:52 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:f867:9276:536d:d303] (unknown [IPv6:2001:470:d:5e7:f867:9276:536d:d303]) by dougbarton.us (Postfix) with ESMTPSA id B2D4622B2A for ; Thu, 7 Feb 2013 04:27:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1360211271; bh=nPQeaA8lO2TnxGY+Ms+sNR1axD74SBZprAFsbG5Ucl8=; h=Date:From:To:Subject:References:In-Reply-To; b=k3yavxhyNNnaVQHvtaep/H8Nxb5A5k8Vgf7jZy1meqK3bqhXY2qnZOOPkzblzbIOY 2r8+WAEpv/CWPMFO6PBd9CEptInE1KtgKAMSxTz461pF4We7e1GkfBRRVrxZQSfKvj R6PSSd1rxmFglrHx1HlxHNWafRUKfY0qwT+vQ4gA= Message-ID: <51132D47.8030704@dougbarton.us> Date: Wed, 06 Feb 2013 20:27:51 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 04:27:52 -0000 On 02/06/2013 08:07 PM, Owen DeLong wrote: > How does IPv4-over-IPv6 do anything that dual-stack doesn't accomplish? v4 over v6 is looking forward to the day when IPv6-only networks are the rule rather than the exception, but there is still a need to reach v4-only resources outside the network. The problem is that for this purpose it's worse in many ways than the current solution for end-user networks, NAT on the inside network (i.e, dual stack). Doug From shtsuchi@cisco.com Wed Feb 6 20:48:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77A21F84E3 for ; Wed, 6 Feb 2013 20:48:07 -0800 (PST) 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_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZfsdnJVzEIy for ; Wed, 6 Feb 2013 20:48:06 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25021F84E2 for ; Wed, 6 Feb 2013 20:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=751; q=dns/txt; s=iport; t=1360212486; x=1361422086; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0j9jBIWm89JASeWFkE8OIfztVwy+OdpLvXepefJwAJs=; b=bhY1/4N76VzUijipROLRLnsbJznMjJsshamy25mWpvR88RyXv5onNk+R ku4AExK/XNjHf0D3xHKHJYyb9/fkMVvm1Fe4W3qjQDPsOVAxf/YuxDN3k pviSha460BNYkyGak2jliK4WfIoyDL2ak2vBDMJh/rmROCemowAeL6Dhz Y=; X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; d="scan'208";a="174305152" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 07 Feb 2013 04:48:06 +0000 Received: from [10.141.32.249] (dhcp-10-141-32-249.cisco.com [10.141.32.249]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r174m4U8009206; Thu, 7 Feb 2013 04:48:05 GMT Message-ID: <51133204.8090407@cisco.com> Date: Thu, 07 Feb 2013 13:48:04 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: cb.list6@gmail.com References: <20130130225129.15191.13703.idtracker@ietfa.amsl.com> <00bd01cdffad$01522c40$4001a8c0@gateway.2wire.net> <6.2.5.6.2.20130131141627.0a209458@resistor.net> <510AFDC0.5020300@bogus.com> <8D23D4052ABE7A4490E77B1A012B63074747801D@mbx-01.win.nominum.com> <510B4EC6.5050308@bogus.com> <510B77E4.2060001@gmail.com> <6.2.5.6.2.20130201071229.0a26fed0@resistor.net> <007701ce00a1$92029320$4001a8c0@gateway.2wire.net> <2CF4CB03E2AA464BA0982EC92A02CE2501E7A46E@BY2PRD0512MB653.namprd05.prod.outlook.com> <510C47F0.5040808@bogus.com> <46184C51-95C6-4BD1-949E-CEAE84411C32@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 04:48:07 -0000 (2013/02/07 12:06), Cameron Byrne wrote: > Sent from ipv6-only Android > On Feb 6, 2013 7:02 PM, "Randy Bush" > wrote: > > > > >>> map-e, aka stateless a+p, is about as clean a solution as you're gonna > > >>> get in this space. > > >> Send code > > > > > > running at janog > > > > > > https://www.seil.jp/community/node/71 > > > > sorry, wrong url > > > > https://www.seil.jp/community/node/97 > > On a 3gpp mobile network? > > Thought so. MAP-E implementation report is here. http://tools.ietf.org/html/draft-janog-softwire-report-01 There are 7 vendors and 9 implementations,include 2 Open sources(OpenWRT and ASAMAP) and Linux/BSD Kernel(by IPI). Regards, -Shishio From shtsuchi@cisco.com Wed Feb 6 21:19:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E5921F84BF; Wed, 6 Feb 2013 21:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVXvX4YXzV4W; Wed, 6 Feb 2013 21:19:06 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2421F84B9; Wed, 6 Feb 2013 21:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1360214345; x=1361423945; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tM18OA0HnCji+8UyJv3z3mskjsinBQAFmw3mwfGSIcE=; b=czVAQpzbMMmnWjMl7jgGAnzrdAM+t3JCXYpU/n5utFo1FMOw8Vsfx2QM a5k6LkEVztlwAxhE09uieOLfbznSxk7RDMzUkicixYB89wFxwi/EwYjts v6+VrIGOZtXxtJgBSUNs9+CX14TynPgtsrqc+oeLj4z2xEdO4zaMQoT/W I=; X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; d="scan'208";a="25013123" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 07 Feb 2013 05:19:01 +0000 Received: from [10.141.32.249] (dhcp-10-141-32-249.cisco.com [10.141.32.249]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r175J0Ap013573; Thu, 7 Feb 2013 05:19:00 GMT Message-ID: <51133943.30605@cisco.com> Date: Thu, 07 Feb 2013 14:18:59 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: joelja@bogus.com References: <51100E9D.6050803@bogus.com> In-Reply-To: <51100E9D.6050803@bogus.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: wgchairs@ietf.org, v6ops@ietf.org Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 05:19:06 -0000 I supports publish this draft as "informational". XLAT464 is good solution. It could minimize configuration parameters and utilize current implementation. I can understand it is very useful for both IPv6 PDP only 3G environment(Wireless) and non-managed CPE network(Wireline). But I don't think this is current BEST. Especially there are many implementation of MAP-E/MAP-E/DS-lite in wireline network. This should publish RFC as "informational". Regards, -Shishio (2013/02/05 4:40), joel jaeggli wrote: > To emphasize Fred's request, please share you opinion on whether this document should be published intact (as a BCP), with with a lower state (informational), or not at all, given the IPR disclosure associated with it. > > The document can be reviewed here: > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > > the known IPR disclosure is here: > > https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-v6ops-464xlat > > if you have registered your opinion on this subject already you will be counted. > > The deadline for commentary is Monday Feb 11th 2012. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From mawatari@jpix.ad.jp Wed Feb 6 23:34: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 EC49C21F886A for ; Wed, 6 Feb 2013 23:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwkHgDnFjpSz for ; Wed, 6 Feb 2013 23:34:45 -0800 (PST) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 11D7A21F885B for ; Wed, 6 Feb 2013 23:34:44 -0800 (PST) Received: from [192.168.0.230] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 92588FC040; Thu, 7 Feb 2013 16:34:43 +0900 (JST) Date: Thu, 07 Feb 2013 16:34:41 +0900 From: MAWATARI Masataka To: xing@cernet.edu.cn In-Reply-To: <51132576.7000200@cernet.edu.cn> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <51132576.7000200@cernet.edu.cn> Message-Id: <20130207163440.C1BD.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Cc: v6ops@ietf.org, wdec@cisco.com, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 07:34:46 -0000 Hi, * On Thu, 07 Feb 2013 11:54:30 +0800 * Xing Li wrote: > Hi, Vizdal and All, > > > Rajiv, Guys, > > > > > > > > > >> Also, let's not forget that there is MAP-T as well - all about > >> translation. :-) The challenge in all of this is that the UE needs to be > >> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE > >> dependency. > >> > > > > btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IPR'd by > > ChinaMobile as well claiming the same patent as for 464xlat. Given that > > MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat > > are equal from this point of view, but 464xlat is more advanced as there > > is a running code available (at lest for android) and this is something that > > should really matter to the IETF. > > > > > FYI: The stateless double translation (one of the origins of MAP-T) is > introduced in Section 5.2 "Double IVI" of > http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is > published on June 13, 2009, earlier than June 26$B!$(B2009. It's a really mystery-shrouded claim. Thank you for your information. > Regards, > > xing Kind Regards, Masataka MAWATARI From diego@tid.es Thu Feb 7 02:17: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 0C5A821F8472 for ; Thu, 7 Feb 2013 02:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vbc2VqFeHpSR for ; Thu, 7 Feb 2013 02:17:27 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3026B21F846E for ; Thu, 7 Feb 2013 02:17:26 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MHU003SIHWXG5@tid.hi.inet> for v6ops@ietf.org; Thu, 07 Feb 2013 11:17:21 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id A3.CF.02896.13F73115; Thu, 07 Feb 2013 11:17:21 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MHU003SCHWXG5@tid.hi.inet> for v6ops@ietf.org; Thu, 07 Feb 2013 11:17:21 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS7-MAD.hi.inet ([fe80::4ccc:bab7:84dc:7c6e%15]) with mapi id 14.02.0328.009; Thu, 07 Feb 2013 11:17:19 +0100 Date: Thu, 07 Feb 2013 10:17:19 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "Roque Gagliano (rogaglia)" Message-id: Content-id: <7282A363359E6C42978AF0A61D2B59E9@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [v6ops] New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt Thread-index: AQHOBLkw2sxGZueaWkmwzKtNygDtvphuHmUA X-AuditID: 0a5f4e69-b7f636d000000b50-bc-51137f31013b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhivcz1DWsFw40aFoiY3H62F5mB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlvNgwk7lgklnFsul/mRsYH5h0MXJySAiYSLxc9IkFwhaTuHBv PVsXIxeHkMA2RombF+ZBOT8YJfpO/GWHcDYxSryY8g6shUVAVWLtlg5mEJsNyH7U/JsdxBYW CJFYvuwPWA2ngK/E+jfNbBArFCT+nHsMFOfgEAFavXKVNUiYWcBb4veC3awgNi+QvXTNZHaI uJnE06YnUHFBiR+T74G1MguoS0yZkgtRIi7R3HqTBcJWlJi2qIERxGYUkJV4N38+WKuIQKjE ras32CFsI4lVCz5BXSMgsWTPeWYIW1Ti5eN/rBAvLmGUePRjFvsERolZSM6YheSMWQhnzEJy xiwkZyxgZF3FKFacVJSZnlGSm5iZk25gpJeRqZeZl1qyiRESdZk7GJfvVDnEKMDBqMTD2/BO KFCINbGsuDL3EKMEB7OSCO/JGuFAId6UxMqq1KL8+KLSnNTiQ4xMHJxSDYy9TuGrWQU95dec mBb2kffM39wnd7NdVSYtyHWTnvKCiWu1gKnkphmeoTv35+iLz3bavFF26hXxiW5zK/Ycmzy9 m38PM0/LnArliss/D/gEvGuaXtn296lqUGC8u8fyzR8Kzv+cnmPl8Z7nE/82Jp3c2hUHeWv9 PrE93Nv8basf16zlS12dvgUosRRnJBpqMRcVJwIA+mhc9pgCAAA= References: <20130205215743.30106.77867.idtracker@ietfa.amsl.com> <5111A72B.2000804@lacnic.net> Cc: "" Subject: Re: [v6ops] New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 10:17:28 -0000 SGkgUm9xdWUsDQoNCllvdSBhcmUgdG90YWxseSByaWdodC4gSSB0aGluayBpdCBpcyBteSBmYXVs dCBmcm9tIHRoZSBvcmlnaW5hbCB2ZXJzaW9uLCBhbmQgaGFzIGJlZW4gcHJvcGFnYXRpbmcgdGhy b3VnaCB0aGUgc3VjY2Vzc2l2ZSBvbmVzLg0KDQpCZSBnb29kZSwNCg0KT24gNiBGZWIgMjAxMywg YXQgMjM6MjcgLCBSb3F1ZSBHYWdsaWFubyAocm9nYWdsaWEpIHdyb3RlOg0KDQo+IEhpIEFydHVy bywNCj4NCj4gVGhhbmtzIGZvciB0aGUgdXBkYXRlLg0KPg0KPiBXaXRob3V0IHJlYWRpbmcgdGhl IGRvY3VtZW50IGluIGRldGFpbCwgSSB3YXMgd29uZGVyaW5nIHdoeSBkbyB5b3UgdGhpbmsgaXQg c2hvdWxkIGJlIHB1Ymxpc2hlZCBhcyAiU3RhbmRhcmRzIFRyYWNrIi4gVGhpcyBXRyBwdWJsaXNo ZWQgc2ltaWxhciBkb2N1bWVudHMgKHN1Y2ggYXMgUkZDIDU5NjMpIGFzIEluZm9ybWF0aW9uYWwu DQo+DQo+IFJlZ2FyZHMsDQo+IFJvcXVlDQo+DQo+DQo+IE9uIEZlYiA2LCAyMDEzLCBhdCAxOjQz IEFNLCBBcnR1cm8gU2VydmluIDxhc2VydmluQGxhY25pYy5uZXQ+IHdyb3RlOg0KPg0KPj4gSGks DQo+Pg0KPj4gICAgICBXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWxv cGV6LXY2b3BzLWRjLWlwdjYtMDQuIFNvbWUNCj4+IG9mIHRoZSBjaGFuZ2VzIHdlIG1hZGU6DQo+ Pg0KPj4gLSBXZSBleHBhbmRlZCB0aGUgc2VjdXJpdHkgc2VjdGlvbiBhcyBzdWdnZXN0ZWQgaW4g dGhlIGxpc3QuIFdlIGluY2x1ZGVkDQo+PiB0aGUgYXR0YWNrcyBhbmQgc2VjdXJpdHkgaXNzdWVz IHRoYXQgd2UgY29uc2lkZXJlZCBtb3JlIGltcG9ydGFudCBpbiBEQw0KPj4gaW5mcmFzdHJ1Y3R1 cmUuIFBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3Ugd2FudGVkIHRvIHNlZSBtb3JlLCBvciBpZiBz b21lDQo+PiBuZWVkIHRvIGJlIGV4cGFuZGVkLg0KPj4gLSBXZSBhZGRlZCBhIG5ldyBzZWN0aW9u ICJPdGhlciBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyIgYW5kIHdlDQo+PiBpbmNsdWRlZCB0 b3BpY3Mgc3VjaCBhcyBBZGRyZXNzaW5nLCBDb3N0IGFuZCBNb25pdG9yaW5nL01hbmFnZW1lbnQu IElmDQo+PiBpdCB3YW50IHRvIGluY2x1ZGUgbW9yZSB0b3BpY3MgbGV0IHVzIGtub3cuDQo+PiAt IFdlIHJlLW9yZ2FuaXplZCBzb21lIHRleHQgaW4gdGhlIGludHJvZHVjdGlvbiB0byBiZSBub3cg dW5kZXIgYQ0KPj4gcmVuYW1lZCBzZWN0aW9uICJBcmNoaXRlY3R1cmUgYW5kIFRyYW5zaXRpb24g U3RhZ2VzIg0KPj4gLSBXZSBhZGRlZCB0ZXh0IHN1Z2dlc3RpbmcgaG93IHRvIHN0YXJ0IG1vdmlu ZyBhcHBsaWNhdGlvbnMgdG8gSVB2Ng0KPj4gd2l0aGluIHRoZSBEQw0KPj4gLSBXZSBhZGRlZCBz b21lIHRleHQgdG8gZXhwbGFpbmluZyB0aGUgbW90aXZhdGlvbnMgZnJvbSBtb3ZpbmcgZnJvbQ0K Pj4gRHVhbC1zdGFjayB0byBJUHY2LW9ubHkgYXMgc3VnZ2VzdGVkIGluIHRoZSBsaXN0DQo+PiAt IFdlIGNoYW5nZWQgc29tZSB0ZXh0IHRvIGltcHJvdmUgcmVhZGluZyBhcyBzdWdnZXN0ZWQgYnkg c29tZSBwZW9wbGUNCj4+IG9mZi1saXN0DQo+PiAtIFdlIGZpeGVkIHNvbWUgdHlwb3MNCj4+IC0g V2UgdXBkYXRlZCBzb21lIHJlZmVyZW5jZXMNCj4+IC0gQW5kIHdlIGFkZGVkIGEgbmV3IGF1dGhv cg0KPj4NCj4+ICAgICAgQW5kIEkgdGhpbmsgdGhhdCBpcyBhbGwuDQo+Pg0KPj4gICAgICBQbGVh c2UgbGV0IHVzIGtub3cgeW91ciBjb21tZW50cy4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMNCj4+IGFz DQo+Pg0KPj4NCj4+IC0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NCj4+IFN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2 Ni0wNC50eHQNCj4+IERhdGU6IFR1ZSwgMDUgRmViIDIwMTMgMTM6NTc6NDMgLTA4MDANCj4+IEZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4gVG86IGFzZXJ2aW5AbGFjbmljLm5ldA0K Pj4gQ0M6IHRpbmEudHNvdS56b3V0aW5nQGh1YXdlaS5jb20sIGRpZWdvQHRpZC5lcywgY2F0aHku emhvdUBodWF3ZWkuY29tLA0KPj4gMTg5MTg1ODg4OTdAMTg5LmNuDQo+Pg0KPj4NCj4+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2LTA0LnR4dA0KPj4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBcnR1cm8gU2VydmluIGFuZCBwb3N0ZWQg dG8gdGhlDQo+PiBJRVRGIHJlcG9zaXRvcnkuDQo+Pg0KPj4gRmlsZW5hbWU6ICAgICBkcmFmdC1s b3Blei12Nm9wcy1kYy1pcHY2DQo+PiBSZXZpc2lvbjogICAgIDA0DQo+PiBUaXRsZTogICAgICAg ICAgICAgICAgSVB2NiBPcGVyYXRpb25hbCBHdWlkZWxpbmVzIGZvciBEYXRhY2VudGVycw0KPj4g Q3JlYXRpb24gZGF0ZTogICAgICAgIDIwMTMtMDItMDUNCj4+IFdHIElEOiAgICAgICAgICAgICAg ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+IE51bWJlciBvZiBwYWdlczogMjANCj4+IFVSTDoN Cj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvcGV6LXY2b3Bz LWRjLWlwdjYtMDQudHh0DQo+PiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ng0KPj4gSHRtbGl6ZWQ6ICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2LTA0 DQo+PiBEaWZmOg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbG9w ZXotdjZvcHMtZGMtaXB2Ni0wNA0KPj4NCj4+IEFic3RyYWN0Og0KPj4gIFRoaXMgZG9jdW1lbnQg aXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBvcGVyYXRpb25hbCBndWlkZWxpbmVzIGZvcg0KPj4gIGRh dGFjZW50ZXIgb3BlcmF0b3JzIHBsYW5uaW5nIHRvIGRlcGxveSBJUHY2IGluIHRoZWlyDQo+PiAg aW5mcmFzdHJ1Y3R1cmVzLiAgSXQgYWltcyB0byBvZmZlciBhIHJlZmVyZW5jZSBmcmFtZXdvcmsg Zm9yDQo+PiAgZXZhbHVhdGluZyBkaWZmZXJlbnQgcHJvZHVjdHMgYW5kIGFyY2hpdGVjdHVyZXMs IGFuZCB0aGVyZWZvcmUgaXQgaXMNCj4+ICBhbHNvIGFkZHJlc3NlZCB0byBtYW51ZmFjdHVyZXJz IGFuZCBzb2x1dGlvbiBwcm92aWRlcnMsIHNvIHRoZXkgY2FuDQo+PiAgdXNlIGl0IHRvIGdhdWdl IHRoZWlyIHNvbHV0aW9ucy4gIFdlIGJlbGlldmUgdGhpcyB3aWxsIHRyYW5zbGF0ZSBpbiBhDQo+ PiAgc21vb3RoZXIgYW5kIGZhc3RlciBJUHY2IHRyYW5zaXRpb24gZm9yIGRhdGFjZW50ZXJzIG9m IHRoZXNlDQo+PiAgaW5mcmFzdHVjdHVyZXMuDQo+Pg0KPj4gIFRoZSBkb2N1bWVudCBmb2N1c2Vz IG9uIHRoZSBEQyBpbmZyYXN0cnVjdHVyZSBpdHNlbGYsIGl0cyBvcGVyYXRpb24sDQo+PiAgYW5k IHRoZSBhc3BlY3RzIHJlbGF0ZWQgdG8gREMgaW50ZXJjb25uZWN0aW9uIHRocm91Z2ggSVB2Ni4g IEl0IGRvZXMNCj4+ICBub3QgY29uc2lkZXIgdGhlIHBhcnRpY3VsYXIgbWVjaGFuaXNtcyBmb3Ig bWFraW5nIEludGVybmV0IHNlcnZpY2VzDQo+PiAgcHJvdmlkZWQgYnkgYXBwbGljYXRpb25zIGhv c3RlZCBpbiB0aGUgREMgYXZhaWxhYmxlIHRocm91Z2ggSVB2Ng0KPj4gIGJleW9uZCB0aGUgc3Bl Y2lmaWMgYXNwZWN0cyByZWxhdGVkIHRvIGhvdyB0aGVpciBkZXBsb3ltZW50IG9uIHRoZSBEQw0K Pj4gIGluZnJhc3RydWN0dXJlLg0KPj4NCj4+ICBBcGFydCBmcm9tIGZhY2lsaXRhdGluZyB0aGUg dHJhbnNpdGlvbiB0byBJUHY2LCB0aGUgbWVjaGFuaXNtcw0KPj4gIG91dGxpbmVkIGhlcmUgYXJl IGludGVuZGVkIHRvIG1ha2UgdGhpcyB0cmFuc2l0aW9uIGFzIHRyYW5zcGFyZW50IGFzDQo+PiAg cG9zc2libGUgKGlmIG5vdCBjb21wbGV0ZWx5IHRyYW5zcGFyZW50KSB0byBhcHBsaWNhdGlvbnMg YW5kIHNlcnZpY2VzDQo+PiAgcnVubmluZyBvbiB0aGUgREMgaW5mcmFzdHJ1Y3R1cmUsIGFzIHdl bGwgYXMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YNCj4+ICBJUHY2IGZlYXR1cmVzIHRvIHNpbXBsaWZ5 IERDIG9wZXJhdGlvbnMsIGludGVybmFsbHkgYW5kIGFjcm9zcyB0aGUNCj4+ICBJbnRlcm5ldC4N Cj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+DQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHY2b3Bz IG1haWxpbmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQot LQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28g Ui4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Bl ei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2Jp bGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNh amUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25z dWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8g ZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2Vu ZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6 DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From arturo.servin@gmail.com Thu Feb 7 04:53: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 C028621F846C for ; Thu, 7 Feb 2013 04:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsP4UHUUvGq1 for ; Thu, 7 Feb 2013 04:53:11 -0800 (PST) Received: from mail-gg0-x231.google.com (mail-gg0-x231.google.com [IPv6:2607:f8b0:4002:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6891921F862A for ; Thu, 7 Feb 2013 04:53:03 -0800 (PST) Received: by mail-gg0-f177.google.com with SMTP id q1so275973gge.22 for ; Thu, 07 Feb 2013 04:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FmpDz8X6NAnFX6dOBVR08zG7T1GiSv3FyQrmA+3gYiE=; b=tIQf6xI7jxNtDidBnj9dm6XC5YJBImZbNepWidXfEOZr/smuRJA30DhQMNw78opTkO O/e89JzlopfJ96/iGRAnkFfr7yovlEDP1Jx+CLPDpGIYK0+6IHnj4Vo+2L4c6OFaWmgJ JG7j09F00GAF9xR+O67tGN6BxGjFBOaUGs4pTDW6ixo90k7X2w3k22mSsf8hh4x7EOIM 7KN0QGrXUSg2aKrB8H6IsEEeqnfPlkZ5FN+H6HTuoNIV0gyC+SUmgWB81HDK50gyncNx uvTTCEXB5a5LrG9Om58d0nZQdAEXoAm8MFxaH58W/el/Q4pJR7uZ/08o364yNPM6tTyM rqUg== X-Received: by 10.236.147.166 with SMTP id t26mr1292760yhj.0.1360241581845; Thu, 07 Feb 2013 04:53:01 -0800 (PST) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:58c0:4190:404e:22a3]) by mx.google.com with ESMTPS id w19sm3620767anh.15.2013.02.07.04.52.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 04:53:00 -0800 (PST) Message-ID: <5113A3A8.2070309@gmail.com> Date: Thu, 07 Feb 2013 10:52:56 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <51100E9D.6050803@bogus.com> In-Reply-To: <51100E9D.6050803@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 12:53:12 -0000 Informational. Before the IPRs claims I could have lived with it as BCP (although I did not fully agree), but now I think that the best approach the IETF should follow is to publish the document as informational. Regards, as On 04/02/2013 17:40, joel jaeggli wrote: > To emphasize Fred's request, please share you opinion on whether this > document should be published intact (as a BCP), with with a lower state > (informational), or not at all, given the IPR disclosure associated with > it. > > The document can be reviewed here: > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > > the known IPR disclosure is here: > > https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-v6ops-464xlat > > > if you have registered your opinion on this subject already you will be > counted. > > The deadline for commentary is Monday Feb 11th 2012. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ales.vizdal@t-mobile.cz Thu Feb 7 09:04: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 EA4C921F8481 for ; Thu, 7 Feb 2013 09:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3Ke6VX+w8Mu for ; Thu, 7 Feb 2013 09:04:29 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 13BD321F8206 for ; Thu, 7 Feb 2013 09:04:29 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id B30CC285800 for ; Thu, 7 Feb 2013 18:04:26 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 7 Feb 2013 18:04:26 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: IPv6 Operations Date: Thu, 7 Feb 2013 18:05:21 +0100 Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4E69rXEQQscOx6Tr+4Y+GWNHEPvQAaHKqQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 17:04:30 -0000 > >> -----Original Message----- > >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > >> Sent: Wednesday, February 06, 2013 4:48 PM > >> To: V=EDzdal Ale=B9; Ole Troan; joel jaeggli > >> Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org > >> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Statefu= l > andStateless > >> Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) > >> > >> I agree with Ales to translation being better in mobile environment. > > > > Thanks, the industry needs a shipping solution soon as dual-stack is no= t solving > > the ipv4 exhaustion problem (that's why I believe it's taking so much t= ime to > introduce > > it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze ipv6= introduction. >=20 > How does IPv4-over-IPv6 do anything that dual-stack doesn't accomplish? It's the other way around as dual-stack does not accomplish what ipv4-over-= ipv6 in some cases can. Dual-Stack still requires an IPv4 address to be assigned= to an end=20 host and consumes an IPv4 address & IPv6 prefix per subscriber. I am lookin= g for=20 an IPv6 only solution that does not require an IPv4 address to be assigned = to an end=20 host by the Operator. =20 > Neither one addresses IPv4 exhaustion except to the extent that IPv6 impl= ementation > reduces dependence on IPv4. 464xlat does as Operator does not need to assign an IPv4 address to an end = host. =20 > Owen Ales From owen@delong.com Thu Feb 7 11:40: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 E165021F88DB for ; Thu, 7 Feb 2013 11:40:02 -0800 (PST) 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.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYTGlrBQZR6v for ; Thu, 7 Feb 2013 11:40:01 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A731A21F88CC for ; Thu, 7 Feb 2013 11:40:01 -0800 (PST) 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 r17JZZFV022078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Feb 2013 11:35:36 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r17JZZFV022078 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360265736; bh=baSJjflYvrZYlptQtfxNFYyp0UE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=2sI6Dw24URKDwZKcZ9FUSoq0cCkSZBc/oIIrLIo8izr+vsReY1/2qr1+Y4SSIdkNo 41E1anFlod1hLGJeRbm6dwDkGw9Y70ivOUui52nqEsOoaqjHLzZkZj+yfbhac5KxzA dVaCLwDKKBI75aATPstp4L0Ldom14UMKNv2lqdOA= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> Date: Thu, 7 Feb 2013 11:35:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 07 Feb 2013 11:35:36 -0800 (PST) Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 19:40:03 -0000 On Feb 7, 2013, at 09:05 , V=EDzdal Ale=B9 = wrote: >>>> -----Original Message----- >>>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >>>> Sent: Wednesday, February 06, 2013 4:48 PM >>>> To: V=EDzdal Ale=B9; Ole Troan; joel jaeggli >>>> Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org >>>> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of = Stateful >> andStateless >>>> Translation' to Best CurrentPractice = (draft-ietf-v6ops-464xlat-09.txt) >>>>=20 >>>> I agree with Ales to translation being better in mobile = environment. >>>=20 >>> Thanks, the industry needs a shipping solution soon as dual-stack is = not solving >>> the ipv4 exhaustion problem (that's why I believe it's taking so = much time to >> introduce >>> it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze = ipv6 introduction. >>=20 >> How does IPv4-over-IPv6 do anything that dual-stack doesn't = accomplish? >=20 > It's the other way around as dual-stack does not accomplish what = ipv4-over-ipv6 > in some cases can. Dual-Stack still requires an IPv4 address to be = assigned to an end=20 > host and consumes an IPv4 address & IPv6 prefix per subscriber. I am = looking for=20 > an IPv6 only solution that does not require an IPv4 address to be = assigned to an end=20 > host by the Operator. >=20 464xlat requires an IPv4 address on the end host as well. I don't see = any difference between 464xlat vs. CGN other than having an IPv6 tunnel carrying the = middle traffic instead of an IPv4 intermediary address range. It's still IPv4 = through two layers of NAT. Who cares whether the middle layer is IPv6 or IPv4? I = don't see a meaningful difference. >> Neither one addresses IPv4 exhaustion except to the extent that IPv6 = implementation >> reduces dependence on IPv4. >=20 > 464xlat does as Operator does not need to assign an IPv4 address to an = end host. The network operator doesn't assign an IPv4 address to the end host = today. What you really mean is that the operator doesn't have to assign a globally = unique address to the subscriber gateway WAN port, but that's equally addressed in = dual-stack with the use of 100.0.0.0/10 space and CGN. 6 of one, half-dozen of the other. Owen From pkern@spike.0x539.de Thu Feb 7 13:08: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 18FC021F8753 for ; Thu, 7 Feb 2013 13:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIqi3iUwGWmQ for ; Thu, 7 Feb 2013 13:08:14 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 729E821F871D for ; Thu, 7 Feb 2013 13:08:13 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U3YhR-0003q1-EI; Thu, 07 Feb 2013 22:08:05 +0100 Received: from p2003006b0d028201d829e077d094148b.dip.t-dialin.net ([2003:6b:d02:8201:d829:e077:d094:148b] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1U3YhS-0005hE-MK; Thu, 07 Feb 2013 22:08:06 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1U3YhR-0005dc-UY; Thu, 07 Feb 2013 22:08:05 +0100 Date: Thu, 7 Feb 2013 22:08:05 +0100 From: Philipp Kern To: Owen DeLong Message-ID: <20130207210805.GA14134@spike.0x539.de> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 21:08:15 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Owen, am Thu, Feb 07, 2013 at 11:35:35AM -0800 hast du folgendes geschrieben: > 464xlat requires an IPv4 address on the end host as well. I don't see any difference > between 464xlat vs. CGN other than having an IPv6 tunnel carrying the middle > traffic instead of an IPv4 intermediary address range. It's still IPv4 through two > layers of NAT. Who cares whether the middle layer is IPv6 or IPv4? I don't see > a meaningful difference. you need to maintain and distribute that further intermediary address range. To be honest I'd like to have 4to6 translation on the end hosts by provisioning them with the NAT64 prefix. This would allow me to only hand out IPv6 instead of having to maintain two routing planes, which is at least one cost, as this might involve two separate routing protocols for IPv4 and IPv6. Clients that don't care about IPv4 anymore (because they don't use legacy software employing IPv4 literals, for instance) can then simply deactivate it and there's less IPv4. Yay. So I care about the middle layer, even though it might not matter much for the regular end-user of a mobile hotspot. Kind regards Philipp Kern --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJRFBe1AAoJEERuJUU10Fbs8KYH/jpQwJFBXqoPkThREfNTO5e0 6XbHqTEQQPCgpI4R1V2QyUF5S9LjTY/bU9JpnmOGQ/bf1N1rRx3xm0qy+C6HJg7e rcpW7r4ArSjPFlmr8R58Dp/2oC+nTLJXqRUPuvf0PB0kMv6e1mUTsg3LrHDwkxHG 9Yo0N3HLpoG7QLiqQBY5EQFXOgJZgPuD14rQfAE3gzwh4SzVW3OHi+6ntR5Q+dY2 yTSKENCT05WoIj+BZXNJAPiZM9SVSH1n6zJ7uWYzCv3OTEvaYshVnHFnVRWMDzGN mHIRaqUdtcfoobkiAViSzXyb0cGyI8ARLloUvBBgrGK2ngnueNG/7BXLzN6Ps9o= =fgE0 -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From jouni.nospam@gmail.com Thu Feb 7 13:38: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 89D7721F88E4 for ; Thu, 7 Feb 2013 13:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0w44sOtozJ3 for ; Thu, 7 Feb 2013 13:38:37 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 317B521F84D5 for ; Thu, 7 Feb 2013 13:38:31 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so1370732eaa.5 for ; Thu, 07 Feb 2013 13:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=0bX6IvyjtheweC50RU9deR2kCu+Vg1z2QDRrOtYKWj4=; b=kEQhlYz6Gghtcfp/KCt9tky5EWuM6+cAjKZ7EHWK7F+96rCyA+wyvxFU5Tq8TcGaJV AqxF4HMdzdx0QY00+Lj5OyzpQj/dTrxblkk23PUbNeA+dLwZAcU9fqWM32BDSbGzZR+6 /i4KhnxLUPLyo8Qh9ut2GLBdNZp5F97eTjLSE6Ft2YWMGSQ7wpNOuwm0KCnk4AMHHbUO zK3ME407aM/YFwIV6XNimSTpj6aS+aUoF/ZEM2mgjVh6WeVOzf+pavS6DraC8aZF+ETf CShi+zbMt0HEkp8AkbPCyiMXTclR+/reGZTQpGWpJsPYYftniUipILOHOZlHdLmyUOjs EuCg== X-Received: by 10.14.200.137 with SMTP id z9mr8145055een.20.1360273111193; Thu, 07 Feb 2013 13:38:31 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:c49f:a7bf:baa4:c8ad? ([2001:1bc8:101:f101:c49f:a7bf:baa4:c8ad]) by mx.google.com with ESMTPS id 44sm44136252eek.5.2013.02.07.13.38.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 13:38:30 -0800 (PST) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> Date: Thu, 7 Feb 2013 23:38:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 21:38:38 -0000 On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: >=20 >>> Neither one addresses IPv4 exhaustion except to the extent that IPv6 = implementation >>> reduces dependence on IPv4. >>=20 >> 464xlat does as Operator does not need to assign an IPv4 address to = an end host. >=20 > The network operator doesn't assign an IPv4 address to the end host = today. What you > really mean is that the operator doesn't have to assign a globally = unique address to > the subscriber gateway WAN port, but that's equally addressed in = dual-stack with > the use of 100.0.0.0/10 space and CGN. Ales speaks here about 3GPP networks and there the operator assigns = every end device (UE) with a private or global IPv4 address if a dual-stack = capable bearer is used (I'll leave now the deferred address allocation away for = a reason). 464XLAT really does help here in that sense.. in 3GPP networks. - Jouni >=20 > 6 of one, half-dozen of the other. >=20 > Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Thu Feb 7 13:46:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC26B21F8B4C for ; Thu, 7 Feb 2013 13:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY4-FwivR0vv for ; Thu, 7 Feb 2013 13:46:54 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C34F021F8A64 for ; Thu, 7 Feb 2013 13:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3102; q=dns/txt; s=iport; t=1360273614; x=1361483214; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XxKY9tUWJUjBur2r7f279ymko2JD5tHUKs9AdvLaW8k=; b=grTLm9orFqbpC+TzaKSHZWdkQnVFvjG/gli4d39zf+nX4dyA5eNiEDVo pLWRomgQ1SxRpEiRFRk8FIfNBeP9dswcKtE09CGsFMQiGeOSoscC6LWcY VdgkYXOLNy2SqF9qzA65n4TrB+ByM9J7RLoUfkPA1aG2Z2fvxTYodZLHc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIcgFFGtJV2Z/2dsb2JhbABFwGwWc4IfAQEBAwF5BQcGAQgRAwEBAQsZBDkUCQgCBAENBQgTh3AGDMAuBIJNimSDSmEDpnODAIFoPA X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208";a="171654957" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 07 Feb 2013 21:46:54 +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 r17LkslI004450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 21:46:54 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 15:46:54 -0600 From: "Rajiv Asati (rajiva)" To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= , Ole Troan , joel jaeggli Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBIFcg7Qzvwn0bkCMyeeF78VjuZhtRnoAgAG6ioA= Date: Thu, 7 Feb 2013 21:46:53 +0000 Message-ID: In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.82.243.27] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 21:46:55 -0000 Hi Ales,=20 > BCP will give the industry the signal what to support ... this is not >clear=20 > to them yet.=09 Does it really matter, given that the 60-80% of mobile UE industry means iOS and Android? Would Google/Android and Apple/iOS get swayed by BCP vs. Informational status? I do support 464XLAT becoming an RFC sooner than later, because it could take 2-5yrs to be widely available/used on various Android UEs. After all, the users can't be forced to upgrade the software on their mobile UEs to get IPv6, let alone 464XLAT or MAP. Heck, my tablet running Android OS doesn't support IPv6 (and can't be upgraded). With informational status, 464XLAT could bypass the IPR entanglement to become an RFC, IMO. Cheers, Rajiv -----Original Message----- From: V=EDzdal Ale=B9 Date: Wednesday, February 6, 2013 4:54 PM To: Rajiv Asati , Ole Troan , Joel jaeggli Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: RE: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >Rajiv, Guys, > > > >> -----Original Message----- >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >> Sent: Wednesday, February 06, 2013 4:48 PM >> To: V=EDzdal Ale=B9; Ole Troan; joel jaeggli >> Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org >> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful >>andStateless >> Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >>=20 >> I agree with Ales to translation being better in mobile environment. > >Thanks, the industry needs a shipping solution soon as dual-stack is not >solving >the ipv4 exhaustion problem (that's why I believe it's taking so much >time to introduce >it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze ipv6 >introduction. > >> Overall, I do think that if 464XLAT were to be "informational", then we >> would be better off. > >BCP will give the industry the signal what to support ... this is not >clear to them yet.=09 > >> Also, let's not forget that there is MAP-T as well - all about >> translation. :-) The challenge in all of this is that the UE needs to be >> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE >> dependency. > >btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IPR'd >by=20 >ChinaMobile as well claiming the same patent as for 464xlat. Given that >MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat >are equal from this point of view, but 464xlat is more advanced as there >is a running code available (at lest for android) and this is something >that=20 >should really matter to the IETF. > >> Cheers, >> Rajiv > >PS. To my experience the business is not taking the best / nicest solution >available, but the one that fits the business the best. > >Cheers, >Ales > > From fred@cisco.com Thu Feb 7 13:56: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 7031521F8A3F for ; Thu, 7 Feb 2013 13:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP3m4GXKI+q7 for ; Thu, 7 Feb 2013 13:56:13 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8627821F8481 for ; Thu, 7 Feb 2013 13:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1554; q=dns/txt; s=iport; t=1360274173; x=1361483773; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=SkuZYpBOX6R3gGJNvomfJwa19mLND1VbdsUUehUc5FE=; b=Nj4SH797cys37vEbcjRqoOuU1cbjG8o30jHd0wRV8wQr98YoVPNLwEIj CwnbDVsliZI/xk9XgHGsTpvT/zJf3Lv3aWUp2NtQOS8sHTg69crlmYbvk 3qdyu+ilCb/FcTChjUKxoUXs9IoJyEQbRk7A4bFx15wK24VH+Ax3O/aHm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG0iFFGtJV2Z/2dsb2JhbABFwG0Wc4IfAQEBAwE6RAsCARkDAQILFBAyHQgCBBMIiAMGsW6OPpB7YQOmc4MAgiQ X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208";a="174686227" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 07 Feb 2013 21:56:13 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r17LuCnv014454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Feb 2013 21:56:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 15:56:12 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org list" Thread-Topic: sessions for IETF 86 Thread-Index: AQHOBX3xSPPQAORz8ke0Njfw/NMvkA== Date: Thu, 7 Feb 2013 21:56:11 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B771202@xmb-rcd-x09.cisco.com> References: <20130207202707.23214.11940.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <90A39F1FE7366246AC828CBE5BC1A41A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] sessions for IETF 86 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Feb 2013 21:56:14 -0000 Our sessions have been scheduled. This is not final, and if someone sees an= issue, we can discuss that with agenda@ietf.org. Let us know. Begin forwarded message: > From: "\"IETF Secretariat\"" > Subject: v6ops - Requested sessions have been scheduled for IETF 86 > Date: February 7, 2013 12:27:07 PM PST > To: > Cc: , , , >=20 > Dear Joel Jaeggli, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > v6ops Session 1 (2:00:00) > Monday, Afternoon Session I 1300-1530 > Room Name: Caribbean 3 > --------------------------------------------- > v6ops Session 2 (2:00:00) > Wednesday, Afternoon Session II 1510-1710 > Room Name: Caribbean 5 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name:=20 > Area Name:=20 > Session Requester:=20 >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 2 Hours > Number of Attendees: 300 > Conflicts to Avoid:=20 > First Priority: 6man behave homenet softwire opsarea opsawg pcp >=20 >=20 >=20 >=20 > Special Requests: > Meetecho support is requested, if it doesn't work out secheduling/no= n-conflict has primacy > --------------------------------------------------------- >=20 From marka@isc.org Thu Feb 7 14:01: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 5842F21F8936 for ; Thu, 7 Feb 2013 14:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hHp-yNdeN7h for ; Thu, 7 Feb 2013 14:01:01 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1460E21F86D4 for ; Thu, 7 Feb 2013 14:01:01 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 0DBB6C9428; Thu, 7 Feb 2013 22:00:53 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1360274460; bh=NNOvMUfndBzDHn2DcJo9MW/gjDjMG1LG1S84Qs7bQGM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=A+kDcRgLA8z5SIXBnOvRJyla+9+RkfElSa0wLbhRVpmcKl141XkGCpcVayeyOdvrC h57EYyCDxuZud6LOeczxGnHR7Rd06MmaQsnTZmxoa9ZPIAdaMyE8/6WuTgwjT/UnXx u5j6EMes6yv9P+TWsycUZuE6Kq6VhQUrKbD+ulro= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 7 Feb 2013 22:00:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c1:7c92:1e7d:1bd7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C22CA216C3B; Thu, 7 Feb 2013 22:00:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 505302F27983; Fri, 8 Feb 2013 09:00:48 +1100 (EST) To: Jouni Korhonen From: Mark Andrews References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com> In-reply-to: Your message of "Thu, 07 Feb 2013 23:38:26 +0200." <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com> Date: Fri, 08 Feb 2013 09:00:48 +1100 Message-Id: <20130207220048.505302F27983@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 22:01:02 -0000 In message <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com>, Jouni Korhonen wri tes: > > On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: > > > > >>> Neither one addresses IPv4 exhaustion except to the extent that IPv6 impl > ementation > >>> reduces dependence on IPv4. > >> > >> 464xlat does as Operator does not need to assign an IPv4 address to an end > host. > > > > The network operator doesn't assign an IPv4 address to the end host today. > What you > > really mean is that the operator doesn't have to assign a globally unique a > ddress to > > the subscriber gateway WAN port, but that's equally addressed in dual-stack > with > > the use of 100.0.0.0/10 space and CGN. > > Ales speaks here about 3GPP networks and there the operator assigns every > end device (UE) with a private or global IPv4 address if a dual-stack capable > bearer is used (I'll leave now the deferred address allocation away for a > reason). 464XLAT really does help here in that sense.. in 3GPP networks. > > - Jouni And host based DS-lite also works. Both at designed to work with IPv6 only uplinks. With DS-lite you don't have to nat in the handset when tethering as the operator does the natting for you. There is a 20 byte penalty for DS-lite compared to 464XLAT. > > 6 of one, half-dozen of the other. > > > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rajiva@cisco.com Thu Feb 7 14:06: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 04D6E21F84BB for ; Thu, 7 Feb 2013 14:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.304 X-Spam-Level: X-Spam-Status: No, score=-9.304 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpHtki1m9Adu for ; Thu, 7 Feb 2013 14:06:25 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1031D21F8475 for ; Thu, 7 Feb 2013 14:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2195; q=dns/txt; s=iport; t=1360274785; x=1361484385; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oVTH5veXHregg0b9fi/Fg1XqapAlu2fPRdgd17LIZQM=; b=HRGqn2LAzUxWZjjlbDqtQ5EVsdz2IiB+Q7hTxj+ByFqxXo+RsmKKYw/X PbWWiIcP8wcWhZCw1tcF42eCDmRTZFjsZiyo0ocbn2XIyc0vA7+q6ZlQ3 AlU2rVNRzMoNy24QqQhErBzqawkUb5lJ2A4rRAzOyh/Gy8JO0oSA9fhDI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMwkFFGtJXG+/2dsb2JhbABFwG0Wc4IfAQEBBAEBATc0CwwGAQgRAwECAQoUBSwGCx0IAgQBDQUIh3cDDwy2Og2JUgSCTYlJhGVhA5RJjReFE4MAgiQ X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208";a="174659245" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 07 Feb 2013 22:06:24 +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 r17M6OxH023017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 22:06:24 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 16:06:24 -0600 From: "Rajiv Asati (rajiva)" To: Jouni Korhonen , Owen DeLong Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBX9dAkOLyNA2kUKL1S7dLiaMeg== Date: Thu, 7 Feb 2013 22:06:23 +0000 Message-ID: In-Reply-To: <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.82.243.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <56098A411BC4D243B78F834B703BFDD3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 22:06:26 -0000 Actually, 464XLAT could help to simplify the network design involving NAT in a large scale 3GPP deployment. If dual-stack were to be used on 3GPP interface, then using 100.64.0.0/12 would mean using virtualized routing (e.g. L3VPNs) between one or more PGWs and NAT device, since each PGW can easily exhaust 100.64/12 block. Of course, this is not an issue if NAT is done on the PGW (unless PGW supports 1M+ subscribers with 4+ PDNs each, and in that case, we would be back to needing virtualized NAT). Cheers, Rajiv -----Original Message----- From: Jouni Korhonen Date: Thursday, February 7, 2013 4:38 PM To: Owen DeLong Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) > >On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: > >>=20 >>>> Neither one addresses IPv4 exhaustion except to the extent that IPv6 >>>>implementation >>>> reduces dependence on IPv4. >>>=20 >>> 464xlat does as Operator does not need to assign an IPv4 address to an >>>end host. >>=20 >> The network operator doesn't assign an IPv4 address to the end host >>today. What you >> really mean is that the operator doesn't have to assign a globally >>unique address to >> the subscriber gateway WAN port, but that's equally addressed in >>dual-stack with >> the use of 100.0.0.0/10 space and CGN. > >Ales speaks here about 3GPP networks and there the operator assigns every >end device (UE) with a private or global IPv4 address if a dual-stack >capable >bearer is used (I'll leave now the deferred address allocation away for a >reason). 464XLAT really does help here in that sense.. in 3GPP networks. > >- Jouni > >>=20 >> 6 of one, half-dozen of the other. >>=20 >> Owen >>=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 rajiva@cisco.com Thu Feb 7 14:08: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 59F7D21F8431 for ; Thu, 7 Feb 2013 14:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QHOVUMleyqu for ; Thu, 7 Feb 2013 14:08:48 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3861021F842D for ; Thu, 7 Feb 2013 14:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2600; q=dns/txt; s=iport; t=1360274928; x=1361484528; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iZBwR5MEAzfIpS4CoQvjaCN4yxsldla/bvFukmh3wsE=; b=LQiy6YB1Fj5ADOFNBVYsoNBhk6/pnWqfLZIBZqo17pAv8gyjNcQopRRR GSIF6O3GjRdPNQ7LT/TYfa4p2MH0Gc22LYFgUbERY/sCl+wmYxLlp08jZ H320f+n09SZ+Hgh0zObf2LrcWFGllstJsLlX76tRNfo74fzn/xcEOpzuh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAA0lFFGtJXHB/2dsb2JhbABFwG4Wc4IfAQEBBAEBATc0CwwCBAEIEQMBAgEKFAUmBgYLHQgCBAENBQiHdwMPDLY6DYlSBASCSYlJhGVhA5RJjReFE4MAgiQ X-IronPort-AV: E=Sophos;i="4.84,623,1355097600"; d="scan'208";a="174662457" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 07 Feb 2013 22:08:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r17M8l7C004534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 22:08:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 16:08:47 -0600 From: "Rajiv Asati (rajiva)" To: Mark Andrews , Jouni Korhonen Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBX+z0F8H/ruDWU20oAjLKYJRiA== Date: Thu, 7 Feb 2013 22:08:46 +0000 Message-ID: In-Reply-To: <20130207220048.505302F27983@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.82.243.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D335D0365337C418A2A1EF419B9DCF2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 22:08:49 -0000 Mark, Yes, theoretically speaking. However, video optimizers, DPI, transparent caching, URL filtering etc. all of that would break, if they were subjected to tunneled traffic. Cheers, Rajiv -----Original Message----- From: Mark Andrews Date: Thursday, February 7, 2013 5:00 PM To: Jouni Korhonen Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) > >In message <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com>, Jouni >Korhonen wri >tes: >>=20 >> On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: >>=20 >> >=20 >> >>> Neither one addresses IPv4 exhaustion except to the extent that >>IPv6 impl >> ementation >> >>> reduces dependence on IPv4. >> >>=20 >> >> 464xlat does as Operator does not need to assign an IPv4 address to >>an end >> host. >> >=20 >> > The network operator doesn't assign an IPv4 address to the end host >>today.=20 >> What you >> > really mean is that the operator doesn't have to assign a globally >>unique a >> ddress to >> > the subscriber gateway WAN port, but that's equally addressed in >>dual-stack >> with >> > the use of 100.0.0.0/10 space and CGN. >>=20 >> Ales speaks here about 3GPP networks and there the operator assigns >>every >> end device (UE) with a private or global IPv4 address if a dual-stack >>capable >> bearer is used (I'll leave now the deferred address allocation away for >>a >> reason). 464XLAT really does help here in that sense.. in 3GPP networks. >>=20 >> - Jouni > >And host based DS-lite also works. Both at designed to work with IPv6 >only >uplinks. With DS-lite you don't have to nat in the handset when tethering >as the operator does the natting for you. There is a 20 byte penalty for >DS-lite compared to 464XLAT. >=20 >> > 6 of one, half-dozen of the other. >> >=20 >> > Owen >> >=20 >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >--=20 >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Thu Feb 7 14:09: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 C19E421F8436 for ; Thu, 7 Feb 2013 14:09:41 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv3fojnIkFwL for ; Thu, 7 Feb 2013 14:09:40 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4533D21F8431 for ; Thu, 7 Feb 2013 14:09:35 -0800 (PST) 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 r17M4quG026926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Feb 2013 14:04:52 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r17M4quG026926 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360274693; bh=QPivjmwpSUE4mXUYuSJFI2s8pwM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CAmHw0rr48Gi5sZzOUeOuV4/eIq1v1NJoGf0sb6S6k1L8ZnFxlq5RK++Eri0kEBnI wsZOIg6FvVs0UOvVLKUgfrc5Fku6q9jD9NF2vlZ9vE126GS+NeNZXN5HP2enykdpTl KJcxjhExlnlWtEJSGybuN+nlBpemd2in731tdEtg= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com> Date: Thu, 7 Feb 2013 14:04:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 07 Feb 2013 14:04:53 -0800 (PST) Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 22:09:41 -0000 On Feb 7, 2013, at 13:38 , Jouni Korhonen = wrote: >=20 > On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: >=20 >>=20 >>>> Neither one addresses IPv4 exhaustion except to the extent that = IPv6 implementation >>>> reduces dependence on IPv4. >>>=20 >>> 464xlat does as Operator does not need to assign an IPv4 address to = an end host. >>=20 >> The network operator doesn't assign an IPv4 address to the end host = today. What you >> really mean is that the operator doesn't have to assign a globally = unique address to >> the subscriber gateway WAN port, but that's equally addressed in = dual-stack with >> the use of 100.0.0.0/10 space and CGN. >=20 > Ales speaks here about 3GPP networks and there the operator assigns = every > end device (UE) with a private or global IPv4 address if a dual-stack = capable > bearer is used (I'll leave now the deferred address allocation away = for a > reason). 464XLAT really does help here in that sense.. in 3GPP = networks. >=20 I suppose that's one way to think of it. Personally, I think of every = mobile device as a portable router (since mobile hotspot has become such a common technology) and therefore don't really see it as different from the home = gateway in the residential or SMB scenario. Owen From owen@delong.com Thu Feb 7 14:15: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 2E10721F8472 for ; Thu, 7 Feb 2013 14:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErCdUcmuJhz1 for ; Thu, 7 Feb 2013 14:15:36 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EDF2921F8431 for ; Thu, 7 Feb 2013 14:15:28 -0800 (PST) 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 r17MCJfE027562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Feb 2013 14:12:19 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r17MCJfE027562 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360275139; bh=W1RXS9COeOfEx9leUbF1V5Ui2kI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rL+j799YERRleHWsoO0RLejRXdKlWzPIhomb9yG/smh7JFK5v7rn0nvuLqhqYd5xR PFuXCaRvySqPqtYwkCjoed5x3wM3fYsmyNnvQDOIkXLsdjN/ujSOX3V71f1ETCQEih Z51WlSWa2cc0slPIKS5wlz0d0S7OH48OHGH27nlo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Thu, 7 Feb 2013 14:12:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 07 Feb 2013 14:12:19 -0800 (PST) Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 22:15:38 -0000 It's a /10, not a /12, but point taken, you can trade some issues for = other issues by using v6 as the middle-ground addressing instead of v4. Interestingly, I believe your math below (1M+ subscribers @ 4+PDNs) is correct for the /10, but that it would be 1/4 that for a /12. Owen On Feb 7, 2013, at 14:06 , "Rajiv Asati (rajiva)" = wrote: >=20 >=20 > Actually, 464XLAT could help to simplify the network design involving = NAT > in a large scale 3GPP deployment. >=20 > If dual-stack were to be used on 3GPP interface, then using = 100.64.0.0/12 > would mean using virtualized routing (e.g. L3VPNs) between one or more > PGWs and NAT device, since each PGW can easily exhaust 100.64/12 = block. >=20 > Of course, this is not an issue if NAT is done on the PGW (unless PGW > supports 1M+ subscribers with 4+ PDNs each, and in that case, we would = be > back to needing virtualized NAT). >=20 > Cheers, > Rajiv >=20 > -----Original Message----- > From: Jouni Korhonen > Date: Thursday, February 7, 2013 4:38 PM > To: Owen DeLong > Cc: "v6ops@ietf.org" > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of > Stateful andStateless Translation' to Best > CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >=20 >>=20 >> On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: >>=20 >>>=20 >>>>> Neither one addresses IPv4 exhaustion except to the extent that = IPv6 >>>>> implementation >>>>> reduces dependence on IPv4. >>>>=20 >>>> 464xlat does as Operator does not need to assign an IPv4 address to = an >>>> end host. >>>=20 >>> The network operator doesn't assign an IPv4 address to the end host >>> today. What you >>> really mean is that the operator doesn't have to assign a globally >>> unique address to >>> the subscriber gateway WAN port, but that's equally addressed in >>> dual-stack with >>> the use of 100.0.0.0/10 space and CGN. >>=20 >> Ales speaks here about 3GPP networks and there the operator assigns = every >> end device (UE) with a private or global IPv4 address if a dual-stack >> capable >> bearer is used (I'll leave now the deferred address allocation away = for a >> reason). 464XLAT really does help here in that sense.. in 3GPP = networks. >>=20 >> - Jouni >>=20 >>>=20 >>> 6 of one, half-dozen of the other. >>>=20 >>> Owen >>>=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 jouni.nospam@gmail.com Thu Feb 7 14:32: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 334B621F8ABD for ; Thu, 7 Feb 2013 14:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8qFF+JFM97Z for ; Thu, 7 Feb 2013 14:32:20 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9C021F8953 for ; Thu, 7 Feb 2013 14:32:20 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id cz11so2887907veb.3 for ; Thu, 07 Feb 2013 14:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=8Pk7ZVoBTPW5jf9pw+GQCTu4Eh+JrH8OWIxIGToedCo=; b=wZHzcFi2grIWxkb+KjAiOyRD9WTO5Bbc1DSJyAf6Z9/Ug1kDcLHxjJwonnJ49q70xq vEqGCAKQzowXMsbv8+1tetamyf8nCBGbZWztyV0CuPShdjFklZ1aqZk4LoHhXcGxLKnH MviuCrfblTNL6d3HiB/uPu3AiD0igGesGGMXrWYJe6B6L983BuMTh0hjoMFAt1j0mJC0 SqpAfkfmaDJXO1s+O1BX3IF4U3H70hcYwrrC9ySesg0HZvPwiuKcb1oiABlT4Jl5p07v /PefcUSb5NimPfWm0JJqznBLLUPXRg48PFC3DX5DcJO1PvvsdN67TpfZcufhRdEhDwll 1MXw== X-Received: by 10.52.21.13 with SMTP id r13mr3474977vde.37.1360276339908; Thu, 07 Feb 2013 14:32:19 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:c49f:a7bf:baa4:c8ad? ([2001:1bc8:101:f101:c49f:a7bf:baa4:c8ad]) by mx.google.com with ESMTPS id a19sm40590776vdh.9.2013.02.07.14.32.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 14:32:19 -0800 (PST) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Fri, 8 Feb 2013 00:32:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3AC901AC-6BA8-401C-9E3B-C26948BD28AC@gmail.com> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com> To: Owen DeLong X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 22:32:21 -0000 On Feb 8, 2013, at 12:04 AM, Owen DeLong wrote: >=20 > On Feb 7, 2013, at 13:38 , Jouni Korhonen = wrote: >=20 >>=20 >> On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: >>=20 >>>=20 >>>>> Neither one addresses IPv4 exhaustion except to the extent that = IPv6 implementation >>>>> reduces dependence on IPv4. >>>>=20 >>>> 464xlat does as Operator does not need to assign an IPv4 address to = an end host. >>>=20 >>> The network operator doesn't assign an IPv4 address to the end host = today. What you >>> really mean is that the operator doesn't have to assign a globally = unique address to >>> the subscriber gateway WAN port, but that's equally addressed in = dual-stack with >>> the use of 100.0.0.0/10 space and CGN. >>=20 >> Ales speaks here about 3GPP networks and there the operator assigns = every >> end device (UE) with a private or global IPv4 address if a dual-stack = capable >> bearer is used (I'll leave now the deferred address allocation away = for a >> reason). 464XLAT really does help here in that sense.. in 3GPP = networks. >>=20 >=20 > I suppose that's one way to think of it. Personally, I think of every = mobile device > as a portable router (since mobile hotspot has become such a common > technology) and therefore don't really see it as different from the = home gateway > in the residential or SMB scenario. Just to point out that 3GPP operators here have no choice. The IPv4 = address assignment stuff is bolted in the system & link model.=20 - Jouni >=20 > Owen >=20 From marka@isc.org Thu Feb 7 14:34: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 11BB221F83EF for ; Thu, 7 Feb 2013 14:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDX2fdQiab3s for ; Thu, 7 Feb 2013 14:34:49 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1454221F8971 for ; Thu, 7 Feb 2013 14:34:49 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A4CF5C956D; Thu, 7 Feb 2013 22:34:36 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1360276485; bh=Sc+ypBWuboN97oE4etNzynUmcC+4LjSB0G9RX2IE+tA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=B+oBBLtRESQHqihriIkKzn08SYS552ZtUd4CK3S5va5lxT6yC6lXa97FiW3j/elgo IzAuMMfC+6jfl53cw+ExVUlyOFQwVJ6YrqXmwLAZiqglb6bFgSnBZ7/pS3eSG1W1rJ YKpL27CjGB64pkFhKZdjtjXdlI5scpo//2C3L3cY= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 7 Feb 2013 22:34:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c1:7c92:1e7d:1bd7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 19A3C216C43; Thu, 7 Feb 2013 22:34:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 044A12F27D8F; Fri, 8 Feb 2013 09:34:34 +1100 (EST) To: "Rajiv Asati (rajiva)" From: Mark Andrews References: In-reply-to: Your message of "Thu, 07 Feb 2013 22:08:46 -0000." Date: Fri, 08 Feb 2013 09:34:34 +1100 Message-Id: <20130207223434.044A12F27D8F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 22:34:50 -0000 In message , "R ajiv Asati (rajiva)" writes: > Mark, > > Yes, theoretically speaking. However, video optimizers, DPI, transparent > caching, URL filtering etc. all of that would break, if they were > subjected to tunneled traffic. > > Cheers, > Rajiv 464XLAT is tunneled as well as far as the IPv4 content is concerned. You save 20 bytes of tunnel overhead, you do *not* remove it. You still have to deal with PMTU issues. DS-lite does not preclude DPI, transparent caching, URL filtering. If you current DPI should be able to handle IP in IP already as it is used for vpns. If you don't have per customer configuration you can even do this. Internet - transparent cache/url filter - AFTR - CPE/handset If you do have per customer it is still easy to identify the taffic that need a header to be unwrapped if you are trying to avoid unwrapping vpn traffic as you know the address of the AFTR boxes. > -----Original Message----- > From: Mark Andrews > Date: Thursday, February 7, 2013 5:00 PM > To: Jouni Korhonen > Cc: "v6ops@ietf.org" > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of > Stateful andStateless Translation' to Best > CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) > > > > >In message <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.com>, Jouni > >Korhonen wri > >tes: > >>=20 > >> On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: > >>=20 > >> >=20 > >> >>> Neither one addresses IPv4 exhaustion except to the extent that > >>IPv6 impl > >> ementation > >> >>> reduces dependence on IPv4. > >> >>=20 > >> >> 464xlat does as Operator does not need to assign an IPv4 address to > >>an end > >> host. > >> >=20 > >> > The network operator doesn't assign an IPv4 address to the end host > >>today.=20 > >> What you > >> > really mean is that the operator doesn't have to assign a globally > >>unique a > >> ddress to > >> > the subscriber gateway WAN port, but that's equally addressed in > >>dual-stack > >> with > >> > the use of 100.0.0.0/10 space and CGN. > >>=20 > >> Ales speaks here about 3GPP networks and there the operator assigns > >>every > >> end device (UE) with a private or global IPv4 address if a dual-stack > >>capable > >> bearer is used (I'll leave now the deferred address allocation away for > >>a > >> reason). 464XLAT really does help here in that sense.. in 3GPP networks. > >>=20 > >> - Jouni > > > >And host based DS-lite also works. Both at designed to work with IPv6 > >only > >uplinks. With DS-lite you don't have to nat in the handset when tethering > >as the operator does the natting for you. There is a 20 byte penalty for > >DS-lite compared to 464XLAT. > >=20 > >> > 6 of one, half-dozen of the other. > >> >=20 > >> > Owen > >> >=20 > >> > _______________________________________________ > >> > v6ops mailing list > >> > v6ops@ietf.org > >> > https://www.ietf.org/mailman/listinfo/v6ops > >>=20 > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >--=20 > >Mark Andrews, ISC > >1 Seymour St., Dundas Valley, NSW 2117, Australia > >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ales.vizdal@t-mobile.cz Thu Feb 7 15:57: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 6D52521F89D5 for ; Thu, 7 Feb 2013 15:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYEltjFnYr7D for ; Thu, 7 Feb 2013 15:57:01 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id A54E221F858E for ; Thu, 7 Feb 2013 15:57:00 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 5030C285821; Fri, 8 Feb 2013 00:56:59 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Fri, 8 Feb 2013 00:56:59 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Owen DeLong Date: Fri, 8 Feb 2013 00:57:55 +0100 Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4FauzfwqgJthD7Q5qxdHT/vqYYrgAI1JwQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA87AFD@SRVHKE02.rdm.cz> References: <1808340F7EC362469DDFFB112B37E2FCC6CFA8775B@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA877D1@SRVHKE02.rdm.cz> <1808340F7EC362469DDFFB112B37E2FCC6CFA87AED@SRVHKE02.rdm.cz> <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@delong.com> In-Reply-To: <1B2AF464-4EBC-44A2-9635-4112E7CA31EF@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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 07 Feb 2013 23:57:01 -0000 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Thursday, February 07, 2013 8:36 PM > To: V=EDzdal Ale=B9 > Cc: IPv6 Operations > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful a= ndStateless > Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >=20 >=20 > On Feb 7, 2013, at 09:05 , V=EDzdal Ale=B9 wrot= e: >=20 > >>>> -----Original Message----- > >>>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > >>>> Sent: Wednesday, February 06, 2013 4:48 PM > >>>> To: V=EDzdal Ale=B9; Ole Troan; joel jaeggli > >>>> Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org > >>>> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of State= ful > >> andStateless > >>>> Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.tx= t) > >>>> > >>>> I agree with Ales to translation being better in mobile environment. > >>> > >>> Thanks, the industry needs a shipping solution soon as dual-stack is = not solving > >>> the ipv4 exhaustion problem (that's why I believe it's taking so much= time to > >> introduce > >>> it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze ip= v6 introduction. > >> > >> How does IPv4-over-IPv6 do anything that dual-stack doesn't accomplish= ? > > > > It's the other way around as dual-stack does not accomplish what ipv4-o= ver-ipv6 > > in some cases can. Dual-Stack still requires an IPv4 address to be assi= gned to an > end > > host and consumes an IPv4 address & IPv6 prefix per subscriber. I am lo= oking for > > an IPv6 only solution that does not require an IPv4 address to be assig= ned to an end > > host by the Operator. > > >=20 > 464xlat requires an IPv4 address on the end host as well. I don't see any= difference > between 464xlat vs. CGN other than having an IPv6 tunnel carrying the mid= dle > traffic instead of an IPv4 intermediary address range. It's still IPv4 th= rough two > layers of NAT. Who cares whether the middle layer is IPv6 or IPv4? I don'= t see > a meaningful difference. >=20 > >> Neither one addresses IPv4 exhaustion except to the extent that IPv6 > implementation > >> reduces dependence on IPv4. > > > > 464xlat does as Operator does not need to assign an IPv4 address to an = end host. >=20 > The network operator doesn't assign an IPv4 address to the end host today= . What you > really mean is that the operator doesn't have to assign a globally unique= address to > the subscriber gateway WAN port, but that's equally addressed in dual-sta= ck with > the use of 100.0.0.0/10 space and CGN. Not really as pointed out by others already. The 10/8 or 100.64/10 address spaces are not enough for some operators as some of them are facing the pri= vate ipv4 address exhaustion already. IPv4-over-IPv6 and IPv6 can help here if t= hey will not need to hand out an IPv4 address to every single subscriber. > 6 of one, half-dozen of the other. >=20 > Owen Ales From ales.vizdal@t-mobile.cz Thu Feb 7 16:03: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 8A05321F89C3 for ; Thu, 7 Feb 2013 16:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPjC1wABCkZi for ; Thu, 7 Feb 2013 16:03:55 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 035EE21F89B3 for ; Thu, 7 Feb 2013 16:03:54 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 7430E285819; Fri, 8 Feb 2013 01:03:53 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Fri, 8 Feb 2013 01:03:52 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "Rajiv Asati (rajiva)" , Jouni Korhonen , Owen DeLong Date: Fri, 8 Feb 2013 01:04:37 +0100 Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBX9dAkOLyNA2kUKL1S7dLiaMephvE5JQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA87AFE@SRVHKE02.rdm.cz> References: <4A34BD7A-11E8-4BD3-8D15-31832A3C0737@gmail.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 00:03:55 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Rajiv > Asati (rajiva) > Sent: Thursday, February 07, 2013 11:06 PM > To: Jouni Korhonen; Owen DeLong > Cc: IPv6 Operations > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful a= ndStateless > Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >=20 >=20 >=20 > Actually, 464XLAT could help to simplify the network design involving NAT > in a large scale 3GPP deployment. >=20 > If dual-stack were to be used on 3GPP interface, then using 100.64.0.0/12 > would mean using virtualized routing (e.g. L3VPNs) between one or more > PGWs and NAT device, since each PGW can easily exhaust 100.64/12 block. The Gi/SGi interface can be virtualised, but the impact is non-trivial i.e.= may=20 also need to virtualise all the nodes on the internet access path as these = might=20 be having issues with overlapping addressing, signalling could also be impl= acted. It will also be operationally more complex. > Of course, this is not an issue if NAT is done on the PGW (unless PGW > supports 1M+ subscribers with 4+ PDNs each, and in that case, we would be > back to needing virtualized NAT). >=20 > Cheers, > Rajiv Cheers, Ales From ales.vizdal@t-mobile.cz Thu Feb 7 16:11: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 CE4D821F89CB for ; Thu, 7 Feb 2013 16:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3np-U7DEZbBH for ; Thu, 7 Feb 2013 16:11:07 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1621F89CE for ; Thu, 7 Feb 2013 16:11:02 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id DD1D828581D; Fri, 8 Feb 2013 01:11:00 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Fri, 8 Feb 2013 01:11:00 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Mark Andrews , "Rajiv Asati (rajiva)" Date: Fri, 8 Feb 2013 01:12:06 +0100 Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: Ac4Fg2xAWyhisJqvTsKXUP3aHWx0bAADP0lg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFA87AFF@SRVHKE02.rdm.cz> References: <20130207223434.044A12F27D8F@drugs.dv.isc.org> In-Reply-To: <20130207223434.044A12F27D8F@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 00:11:11 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Mark > Andrews > Sent: Thursday, February 07, 2013 11:35 PM > To: Rajiv Asati (rajiva) > Cc: IPv6 Operations > Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful a= ndStateless > Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >=20 >=20 > In message x06.cisco.com>, "R > ajiv Asati (rajiva)" writes: > > Mark, > > > > Yes, theoretically speaking. However, video optimizers, DPI, transparen= t > > caching, URL filtering etc. all of that would break, if they were > > subjected to tunneled traffic. > > > > Cheers, > > Rajiv >=20 > 464XLAT is tunneled as well as far as the IPv4 content is concerned. > You save 20 bytes of tunnel overhead, you do *not* remove it. You still > have to deal with PMTU issues. 464xlat is not employing tunnelling or encapsulation (to my understanding) = as there=20 is only the IPv6 packet header, so the payload can be accessed by DPI, cach= ing, filtering if IPv6 aware. Cheers, Ales From rajiva@cisco.com Thu Feb 7 17:20: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 835E71F0D09 for ; Thu, 7 Feb 2013 17:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.42 X-Spam-Level: X-Spam-Status: No, score=-9.42 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0coYSkuOC1gO for ; Thu, 7 Feb 2013 17:20:54 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CFF221F0D07 for ; Thu, 7 Feb 2013 17:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2997; q=dns/txt; s=iport; t=1360286455; x=1361496055; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yuOd9aYsWY/9awv6NXhQfGiXTvLUB+8VWYoWHl1lIJw=; b=hUus21uh4cphWKu2+5tMHoVr7b/aG9rPdYJmWliiNQUjkybsO8uso6x+ S4LQtdNsx08zLIYlpCZ/VW+WgIZd3tHre1rAgn20l41SqsW6/OQlaEGs4 RvRa3QXEpra5nOU2RK0oERVVeCpl/Ge6I58/JGgWZ4uSUJiYHrUYMGRO2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFNRFFGtJXG9/2dsb2JhbABFwHIWc4IfAQEBAwEBAQE3NAsFBwQCAQgRAwECAR4FCyEGCx0IAgQOBYd/AwkGDLYpDYlSBIJNiUmEZWEDlEmBWIs/hRODAA X-IronPort-AV: E=Sophos;i="4.84,626,1355097600"; d="scan'208";a="174712692" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 08 Feb 2013 01:20:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r181Ksp5006176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 01:20:54 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 19:20:54 -0600 From: "Rajiv Asati (rajiva)" To: Owen DeLong Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBX9dAkOLyNA2kUKL1S7dLiaMephvWfEA///QI14= Date: Fri, 8 Feb 2013 01:20:53 +0000 Message-ID: <3FABB739-1784-4F9F-9B44-C360C85323B9@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 01:20:55 -0000 Yes, /10 is what I meant to type, not /12. :) Cheers, Rajiv Sent from my Phone On Feb 7, 2013, at 5:15 PM, "Owen DeLong" wrote: > It's a /10, not a /12, but point taken, you can trade some issues for oth= er issues > by using v6 as the middle-ground addressing instead of v4. >=20 > Interestingly, I believe your math below (1M+ subscribers @ 4+PDNs) is > correct for the /10, but that it would be 1/4 that for a /12. >=20 > Owen >=20 > On Feb 7, 2013, at 14:06 , "Rajiv Asati (rajiva)" wrot= e: >=20 >>=20 >>=20 >> Actually, 464XLAT could help to simplify the network design involving NA= T >> in a large scale 3GPP deployment. >>=20 >> If dual-stack were to be used on 3GPP interface, then using 100.64.0.0/1= 2 >> would mean using virtualized routing (e.g. L3VPNs) between one or more >> PGWs and NAT device, since each PGW can easily exhaust 100.64/12 block. >>=20 >> Of course, this is not an issue if NAT is done on the PGW (unless PGW >> supports 1M+ subscribers with 4+ PDNs each, and in that case, we would b= e >> back to needing virtualized NAT). >>=20 >> Cheers, >> Rajiv >>=20 >> -----Original Message----- >> From: Jouni Korhonen >> Date: Thursday, February 7, 2013 4:38 PM >> To: Owen DeLong >> Cc: "v6ops@ietf.org" >> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of >> Stateful andStateless Translation' to Best >> CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >>=20 >>>=20 >>> On Feb 7, 2013, at 9:35 PM, Owen DeLong wrote: >>>=20 >>>>=20 >>>>>> Neither one addresses IPv4 exhaustion except to the extent that IPv6 >>>>>> implementation >>>>>> reduces dependence on IPv4. >>>>>=20 >>>>> 464xlat does as Operator does not need to assign an IPv4 address to a= n >>>>> end host. >>>>=20 >>>> The network operator doesn't assign an IPv4 address to the end host >>>> today. What you >>>> really mean is that the operator doesn't have to assign a globally >>>> unique address to >>>> the subscriber gateway WAN port, but that's equally addressed in >>>> dual-stack with >>>> the use of 100.0.0.0/10 space and CGN. >>>=20 >>> Ales speaks here about 3GPP networks and there the operator assigns eve= ry >>> end device (UE) with a private or global IPv4 address if a dual-stack >>> capable >>> bearer is used (I'll leave now the deferred address allocation away for= a >>> reason). 464XLAT really does help here in that sense.. in 3GPP networks= . >>>=20 >>> - Jouni >>>=20 >>>>=20 >>>> 6 of one, half-dozen of the other. >>>>=20 >>>> Owen >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From rajiva@cisco.com Thu Feb 7 17:30: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 EB69711E809C for ; Thu, 7 Feb 2013 17:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.34 X-Spam-Level: X-Spam-Status: No, score=-10.34 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJm0DK-Y5HQb for ; Thu, 7 Feb 2013 17:30:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA6FC1F0D09 for ; Thu, 7 Feb 2013 17:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1447; q=dns/txt; s=iport; t=1360287053; x=1361496653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kKV5HB4Nt4en558sk4nJ27+b907BORGTfbcr4twhp64=; b=lfI/Z40kzte08zT2TWTt4u4D5WJke4DaeSyIKqgTzStBROzH+UXccw1o sZIUWkAiFHUlzLpHVvmvpze9DZFgEnL8YnJGVk+kLDJOVB/so+J+Weu5Z ia8w/iyrm8TguSZ5rnYZGP5+Ry6sY3QqZzPsr++DBL6+Mk22akK0lEKqm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABtUFFGtJV2d/2dsb2JhbABFwHIWc4IfAQEBBHkMBAIBCBEEAQEkBAcyFAkIAgQOBYgRwB+CTY4uYQOWIZBSgwA X-IronPort-AV: E=Sophos;i="4.84,626,1355097600"; d="scan'208";a="174714164" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 08 Feb 2013 01:30:52 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r181UqJa024563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 01:30:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 19:30:52 -0600 From: "Rajiv Asati (rajiva)" To: =?Windows-1252?Q?V=EDzdal_Ale=9A?= Thread-Topic: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBZDVe2diR/dP4kWP6SimmMzE4ZhvLLkn Date: Fri, 8 Feb 2013 01:30:51 +0000 Message-ID: References: <20130207223434.044A12F27D8F@drugs.dv.isc.org>, <1808340F7EC362469DDFFB112B37E2FCC6CFA87AFF@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA87AFF@SRVHKE02.rdm.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 01:30:55 -0000 Yup, no tunneling/encapsulation whatsoever. It is just an IPv6 traffic with= L4=3D UDP/TCP as usual to the network. Cheers, Rajiv Sent from my Phone On Feb 7, 2013, at 7:11 PM, "V=EDzdal Ale=9A" wro= te: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f Mark >> Andrews >> Sent: Thursday, February 07, 2013 11:35 PM >> To: Rajiv Asati (rajiva) >> Cc: IPv6 Operations >> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful = andStateless >> Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >>=20 >>=20 >> In message > x06.cisco.com>, "R >> ajiv Asati (rajiva)" writes: >>> Mark, >>>=20 >>> Yes, theoretically speaking. However, video optimizers, DPI, transparen= t >>> caching, URL filtering etc. all of that would break, if they were >>> subjected to tunneled traffic. >>>=20 >>> Cheers, >>> Rajiv >>=20 >> 464XLAT is tunneled as well as far as the IPv4 content is concerned. >> You save 20 bytes of tunnel overhead, you do *not* remove it. You still >> have to deal with PMTU issues. >=20 > 464xlat is not employing tunnelling or encapsulation (to my understanding= ) as there=20 > is only the IPv6 packet header, so the payload can be accessed by DPI, ca= ching, > filtering if IPv6 aware. >=20 > Cheers, > Ales From kawashimam@vx.jp.nec.com Thu Feb 7 18:22:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4122421F8481 for ; Thu, 7 Feb 2013 18:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZZp2H+4AyXu for ; Thu, 7 Feb 2013 18:22:04 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by ietfa.amsl.com (Postfix) with ESMTP id 816E521F8472 for ; Thu, 7 Feb 2013 18:22:04 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id r182Lp1S024771; Fri, 8 Feb 2013 11:21:51 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id r182LpS26431; Fri, 8 Feb 2013 11:21:51 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id r182LpdD024986; Fri, 8 Feb 2013 11:21:51 +0900 (JST) Received: from kaishu.jp.nec.com ([10.26.220.5] [10.26.220.5]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-1644256; Fri, 8 Feb 2013 11:19:42 +0900 Received: from siznecatg141003 ([10.3.141.3] [10.3.141.3]) by mail.jp.nec.com with ESMTP; Fri, 8 Feb 2013 11:19:41 +0900 To: Xing Li In-reply-to: <51132576.7000200@cernet.edu.cn> Message-Id: <20130208111940kawashimam@mail.jp.nec.com> References: <51132576.7000200@cernet.edu.cn> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.68 Step12] From: KAWASHIMA Masanobu Date: Fri, 8 Feb 2013 11:19:39 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: [v6ops] (FYI) Re: Protocol Action: '464XLAT: Combination of StatefulandStateless Translation' to Best CurrentPractice(draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 02:22:11 -0000 Hi, Xing and All, >FYI: The stateless double translation (one of the origins of MAP-T) is >introduced in Section 5.2 "Double IVI" of >http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is >published on June 13, 2009, earlier than June 26, 2009. Thank you for your information. Since some related applications(*) by China Mobile were applied on June 3, 2009, it is better to refer Section 5.2 "IVI NAT464" of draft-xli-behave-ivi-01, which is published on February 9, 2009. :-) * http://worldwide.espacenet.com/publicationDetails/inpadocPatentFamily?CC=CN&NR=101931658A&KC=A&FT=D&ND=3&date=20101229&DB=worldwide.espacenet.com&locale=en_EP Just for your reference, I would like to share the facts. - The patent CN200910085887(second on the list) was granted on December 26, 2012. However, it applies only to China. If you want to use 464XLAT in China, you may have to think over whether the patent is valid or not. - Other related applications are still in the SIPO's examination process. In other words, these applications are invalid as of now. Moreover, scope of the application is only China and USA. So it does not apply to other countries, that is to say, draft-ietf-v6ops-464xlat has no IPR except China and USA. Regards, Masanobu >Hi, Vizdal and All, > >Vizdal Ales $BifRk!s(B: >> Rajiv, Guys, >> >> >> >> >>> Also, let's not forget that there is MAP-T as well - all about >>> translation. :-) The challenge in all of this is that the UE needs to be >>> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE >>> dependency. >>> >> >> btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IPR'd by >> ChinaMobile as well claiming the same patent as for 464xlat. Given that >> MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat >> are equal from this point of view, but 464xlat is more advanced as there >> is a running code available (at lest for android) and this is something that >> should really matter to the IETF. >> >> >FYI: The stateless double translation (one of the origins of MAP-T) is >introduced in Section 5.2 "Double IVI" of >http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is >published on June 13, 2009, earlier than June 26, 2009. > >Regards, > >xing > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ==================================== NEC AccessTechnica, Ltd. Marketing Promotion Department and Product Development Department KAWASHIMA Masanobu kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ==================================== From fibrib@gmail.com Thu Feb 7 19:16: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 899C921E8043 for ; Thu, 7 Feb 2013 19:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ays21YumL2fc for ; Thu, 7 Feb 2013 19:16:33 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id D328E21E8034 for ; Thu, 7 Feb 2013 19:16:32 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so3653834oag.11 for ; Thu, 07 Feb 2013 19:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Zwcy6WI8nHz77tyGVfB3Z0DWHA+E41VA0yMT8qanNWE=; b=FTQ0W1/5wwO0iiGHKHfaZt36cY8xMB0vS/GePYERRIw8eqmM13DuTukDJPiCujHfSx FtpQbQVNa5wUQrzTYE1iB9AexglTqub13fN97rW732BHPedYCiZv+wFCRVFqZ7ji95TM UCwE2pqurA3T3ltFAdSQzoIBVR/9or53oC8QMguYfqkl7J07nxyhU+Yz9e0bLhmyWwmV zaROS6KQyhOLOvvA+fMq/TY2OW82kX1xIdIhV5KzAPwwik1GHkB+EXc00sJt8Z2uiqHb VYqFHDWTxM8u4XVJpCZXGVnaJvCjV2MBxj6SQDsotz8lJ9iUn18mPdffKcfQsV55DMZj hpcQ== MIME-Version: 1.0 X-Received: by 10.60.169.229 with SMTP id ah5mr3058866oec.66.1360293392370; Thu, 07 Feb 2013 19:16:32 -0800 (PST) Received: by 10.76.154.8 with HTTP; Thu, 7 Feb 2013 19:16:32 -0800 (PST) In-Reply-To: <20130208111940kawashimam@mail.jp.nec.com> References: <51132576.7000200@cernet.edu.cn> <20130208111940kawashimam@mail.jp.nec.com> Date: Fri, 8 Feb 2013 12:16:32 +0900 Message-ID: From: Maoke To: KAWASHIMA Masanobu Content-Type: multipart/alternative; boundary=bcaec54ee076714c6804d52dfc9d Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] (FYI) Re: Protocol Action: '464XLAT: Combination of StatefulandStateless Translation' to Best CurrentPractice(draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 03:16:36 -0000 --bcaec54ee076714c6804d52dfc9d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi Masanobu-san and all, thanks a lot for sharing the information. i have some add-ons for the community as well. 2013/2/8 KAWASHIMA Masanobu > > Hi, Xing and All, > > >FYI: The stateless double translation (one of the origins of MAP-T) is > >introduced in Section 5.2 "Double IVI" of > >http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is > >published on June 13, 2009, earlier than June 26, 2009. > > Thank you for your information. > > Since some related applications(*) by China Mobile were applied > on June 3, 2009, it is better to refer Section 5.2 "IVI NAT464" of > draft-xli-behave-ivi-01, which is published on February 9, 2009. :-) > > * > http://worldwide.espacenet.com/publicationDetails/inpadocPatentFamily?CC= =3DCN&NR=3D101931658A&KC=3DA&FT=3DD&ND=3D3&date=3D20101229&DB=3Dworldwide.e= spacenet.com&locale=3Den_EP > > > Just for your reference, I would like to share the facts. > > - The patent CN200910085887(second on the list) was granted > on December 26, 2012. However, it applies only to China. > If you want to use 464XLAT in China, you may have to think over > whether the patent is valid or not. > yes. the patent CN200910085887 was granted last December. however, to my best knowledge, there were at least one early publication describing the DNS-translation and NAT functionality for the IPv4-IPv6 NAT. [1] Marc E. Fiuczynski , Vincent K. Lam , Brian N. Bershad , Marc E. Fiuczynski , Vincent K. Lam , Brian N. Bershad, "The design and implementation of an ipv6/ipv4 network address and protocol translator", in Proceedings of USENIX Annual Technical Conference 1998, New Orleans, June 15-19 1998 we, as potentially using 464xlat in China, gently suppose the patent holder doesn't incline to claim that their right solicitation includes the DNS-translation and NAT64 functionality. if this is not true, we don't like to but have to preserve the possibility of sending objections to SIPO, asking for revoking the patent grant as it is claiming right over already published knowledge. > - Other related applications are still in the SIPO's examination > process. In other words, these applications are invalid as of now. > Moreover, scope of the application is only China and USA. > So it does not apply to other countries, that is to say, > draft-ietf-v6ops-464xlat has no IPR except China and USA. > again, also including the case regarding MAP-T, except the above publication and the IETF docs listed by Masanobu and prof. Xing Li, we also have the following early publications, already including the major innovations of the work later becoming IVI, dIVI, and then MAP-T. [2] Maoke Chen, Xing Li, Ang Li and Yong Cui, "Forwarding IPv4 Traffic in Pure IPv6 Backbone with Stateless Address Mapping," in Proceedings of 10th IEEE/IFIP Network Operations and Management Symposium (NOMS 2006), Vancouver, Canada, Apr. 3 - 7, 2006 [3] Yuncheng Zhu, Maoke Chen, Hong Zhang, Xing Li, =A1=B0Stateless Mapping = and Multiplexing of IPv4 Addresses in Migration to IPv6 Internet,=A1=B1. in Proceedings of IEEE GLOBECOM 2008, p.2248-2252, New Orleans, LA, USA, 30 November - 4 December 2008 for the same reason, we, the authors of the above publications, gently suppose the patent applicant doesn't incline to claim their inventions containing the right over the contents already published prior their submission of the applications. if this is true, we expect the patent applicant revoke their IPR claim in the IETF data-track. if this is not true, we expect the patent applicant explain which part in the current 464xlat or in MAP-T, not covered by the above publications, but covered by the patent applicant's applications or granted patent(s). best regards, maoke > Regards, > Masanobu > > > >Hi, Vizdal and All, > > > >Vizdal Ales =CA=F1=BE=CC=A3=A5: > >> Rajiv, Guys, > >> > >> > >> > >> > >>> Also, let's not forget that there is MAP-T as well - all about > >>> translation. :-) The challenge in all of this is that the UE needs to > be > >>> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE > >>> dependency. > >>> > >> > >> btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is > IPR'd by > >> ChinaMobile as well claiming the same patent as for 464xlat. Given tha= t > >> MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat > >> are equal from this point of view, but 464xlat is more advanced as the= re > >> is a running code available (at lest for android) and this is somethin= g > that > >> should really matter to the IETF. > >> > >> > >FYI: The stateless double translation (one of the origins of MAP-T) is > >introduced in Section 5.2 "Double IVI" of > >http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is > >published on June 13, 2009, earlier than June 26, 2009. > > > >Regards, > > > >xing > > > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. > Marketing Promotion Department and > Product Development Department > KAWASHIMA Masanobu > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ > =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 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec54ee076714c6804d52dfc9d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
hi Masanobu-san and all, 

thanks a l= ot for sharing the information. i have some add-ons for the community as we= ll. 

2013/2/8 KAWASHIMA Masanobu <= span dir=3D"ltr"><kawashimam@vx.jp.nec.com>

Hi, Xing and All,

>FYI: The stateless double translation (one of the origins of MAP-T) is<= br> >introduced in Section 5.2 "Double IVI" of
>http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , whic= h is
>published on June 13, 2009, earlier than June 26, 2009.

Thank you for your information.

Since some related applications(*) by China Mobile were applied
on June 3, 2009, it is better to refer Section 5.2 "IVI NAT464" o= f
draft-xli-behave-ivi-01, which is published on February 9, 2009. :-)

* http://worldwide.espacenet.com/publicationDetails/inpadocPatent= Family?CC=3DCN&NR=3D101931658A&KC=3DA&FT=3DD&ND=3D3&dat= e=3D20101229&DB=3Dworldwide.espacenet.com&locale=3Den_EP


Just for your reference, I would like to share the facts.

- The patent CN200910085887(second on the list) was granted
  on December 26, 2012. However, it applies only to China.
  If you want to use 464XLAT in China, you may have to think over
  whether the patent is valid or not.

<= div>yes. the patent CN200910085887 was granted last December. however, to m= y best knowledge, there were at least one early publication describing the = DNS-translation and NAT functionality for the IPv4-IPv6 NAT.  

[1] Marc E. Fiuczynski , Vincent K. Lam , Brian N. Bers= had , Marc E. Fiuczynski , Vincent K. Lam , Brian N. Bershad, "The des= ign and implementation of an ipv6/ipv4 network address and protocol transla= tor", in Proceedings of USENIX Annual Technical Conference 1998, New O= rleans, June 15-19 1998

we, as potentially using 464xlat in China, gently suppo= se the patent holder doesn't incline to claim that their right solicita= tion includes the DNS-translation and NAT64 functionality. if this is not t= rue, we don't like to but have to preserve the possibility of sending o= bjections to SIPO, asking for revoking the patent grant as it is claiming r= ight over already published knowledge. 


- Other related applications are still in the SIPO's examination
  process. In other words, these applications are invalid as of now.   Moreover, scope of the application is only China and USA.
  So it does not apply to other countries, that is to say,
  draft-ietf-v6ops-464xlat has no IPR except China and USA.

again, also including the case regarding MAP-T, e= xcept the above publication and the IETF docs listed by Masanobu and prof. = Xing Li, we also have the following early publications, already including t= he major innovations of the work later becoming IVI, dIVI, and then MAP-T.&= nbsp;

[2]  Maoke Chen, Xing Li, Ang Li and Yong Cui, "Forwarding IPv4 Traffic in Pure I= Pv6 Backbone with Stateless Address Mapping," in Proceedings of 10th IEEE/= IFIP Network Operations and Management Symposium (NOMS 2006), Vancouver, Canada, Apr. 3 - 7, 2006
[3]=20 Yuncheng Zhu, Maoke Chen, Hong Zhang, Xing Li, “Stateless Mapping and Multiple= xing of IPv4 Addresses in Migration to IPv6 Internet,”. in Proceedings of IEE= E GLOBECOM 2008,  p.2248-2252, New Orleans, LA, USA, 30 November - 4 December 2008  

for the same reason, we, the authors of the= above publications, gently suppose the patent applicant doesn't inclin= e to claim their inventions containing the right over the contents already = published prior their submission of the applications. if this is true, we e= xpect the patent applicant revoke their IPR claim in the IETF data-track. i= f this is not true, we expect the patent applicant explain which part in th= e current 464xlat or in MAP-T, not covered by the above publications, but c= overed by the patent applicant's applications or granted patent(s).&nbs= p;

best regards,
maoke


Regards,
Masanobu


>Hi, Vizdal and All,
>
>Vizdal Ales =CA=F1=BE=CC=A3=A5:
>> Rajiv, Guys,
>>
>> <my_mobile_hat=3D"on">
>>
>>
>>> Also, let's not forget that there is MAP-T as well - all a= bout
>>> translation. :-) The challenge in all of this is that the UE n= eeds to be
>>> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's= a HUGE
>>> dependency.
>>>
>>
>> btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IP= R'd by
>> ChinaMobile as well claiming the same patent as for 464xlat. Given= that
>> MAP-E does not fit (due to encapsulation overhead), MAP-T and 464x= lat
>> are equal from this point of view, but 464xlat is more advanced as= there
>> is a running code available (at lest for android) and this is some= thing that
>> should really matter to the IETF.
>>
>>
>FYI: The stateless double translation (one of the origins of MAP-T) is<= br> >introduced in Section 5.2 "Double IVI" of
>http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , whic= h is
>published on June 13, 2009, earlier than June 26, 2009.
>
>Regards,
>
>xing
>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 NEC AccessTechnica, Ltd.
 Marketing Promotion Department and
 Product Development Department
 KAWASHIMA Masanobu
 kawashimam@vx.jp.nec.com<= /a>
 http://www.neca= t.co.jp/
=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

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

--bcaec54ee076714c6804d52dfc9d-- From kawashimam@vx.jp.nec.com Thu Feb 7 19:39: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 1436C1F0D08 for ; Thu, 7 Feb 2013 19:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7G90kOb1uGK for ; Thu, 7 Feb 2013 19:39:16 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA851F0D05 for ; Thu, 7 Feb 2013 19:39:16 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id r183d3ZH019245; Fri, 8 Feb 2013 12:39:03 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id r183d3o00627; Fri, 8 Feb 2013 12:39:03 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id r183d31m022761; Fri, 8 Feb 2013 12:39:03 +0900 (JST) Received: from zuizan.jp.nec.com ([10.26.220.9] [10.26.220.9]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-1736400; Fri, 8 Feb 2013 12:38:35 +0900 Received: from siznecatg141003 ([10.3.141.3] [10.3.141.3]) by mail.jp.nec.com with ESMTPA id BT-MMP-27743; Fri, 8 Feb 2013 12:38:35 +0900 To: Maoke In-reply-to: Message-Id: <20130208123835kawashimam@mail.jp.nec.com> References: Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.68 Step12] From: KAWASHIMA Masanobu Date: Fri, 8 Feb 2013 12:38:34 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] (FYI) Re: Protocol Action: '464XLAT: Combination ofStatefulandStateless Translation' to Best CurrentPractice(draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 03:39:18 -0000 Hi Maoke-san, Thank you for your additional information. I fully agree with you. There is no doubt. Regards, Masanobu >hi Masanobu-san and all, > >thanks a lot for sharing the information. i have some add-ons for the >community as well. > >2013/2/8 KAWASHIMA Masanobu > >> >> Hi, Xing and All, >> >> >FYI: The stateless double translation (one of the origins of MAP-T) is >> >introduced in Section 5.2 "Double IVI" of >> >http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is >> >published on June 13, 2009, earlier than June 26, 2009. >> >> Thank you for your information. >> >> Since some related applications(*) by China Mobile were applied >> on June 3, 2009, it is better to refer Section 5.2 "IVI NAT464" of >> draft-xli-behave-ivi-01, which is published on February 9, 2009. :-) >> >> * >> http://worldwide.espacenet.com/publicationDetails/inpadocPatentFamily?CC=CN&NR=101931658A&KC=A&FT=D&ND=3&date=20101229&DB=worldwide.espacenet.com&locale=en_EP >> >> >> Just for your reference, I would like to share the facts. >> >> - The patent CN200910085887(second on the list) was granted >> on December 26, 2012. However, it applies only to China. >> If you want to use 464XLAT in China, you may have to think over >> whether the patent is valid or not. >> > >yes. the patent CN200910085887 was granted last December. however, to my >best knowledge, there were at least one early publication describing the >DNS-translation and NAT functionality for the IPv4-IPv6 NAT. > >[1] Marc E. Fiuczynski , Vincent K. Lam , Brian N. Bershad , Marc E. >Fiuczynski , Vincent K. Lam , Brian N. Bershad, "The design and >implementation of an ipv6/ipv4 network address and protocol translator", in >Proceedings of USENIX Annual Technical Conference 1998, New Orleans, June >15-19 1998 > >we, as potentially using 464xlat in China, gently suppose the patent holder >doesn't incline to claim that their right solicitation includes the >DNS-translation and NAT64 functionality. if this is not true, we don't like >to but have to preserve the possibility of sending objections to SIPO, >asking for revoking the patent grant as it is claiming right over already >published knowledge. > > >> - Other related applications are still in the SIPO's examination >> process. In other words, these applications are invalid as of now. >> Moreover, scope of the application is only China and USA. >> So it does not apply to other countries, that is to say, >> draft-ietf-v6ops-464xlat has no IPR except China and USA. >> > >again, also including the case regarding MAP-T, except the above >publication and the IETF docs listed by Masanobu and prof. Xing Li, we also >have the following early publications, already including the major >innovations of the work later becoming IVI, dIVI, and then MAP-T. > >[2] Maoke Chen, Xing Li, Ang Li and Yong Cui, "Forwarding IPv4 Traffic in >Pure IPv6 Backbone with Stateless Address Mapping," in Proceedings of 10th >IEEE/IFIP Network Operations and Management Symposium (NOMS 2006), >Vancouver, Canada, Apr. 3 - 7, 2006 >[3] Yuncheng Zhu, Maoke Chen, Hong Zhang, Xing Li, $B!#!<(BStateless Mapping and >Multiplexing of IPv4 Addresses in Migration to IPv6 Internet,$B!#%"(B. in >Proceedings of IEEE GLOBECOM 2008, p.2248-2252, New Orleans, LA, USA, 30 >November - 4 December 2008 > >for the same reason, we, the authors of the above publications, gently >suppose the patent applicant doesn't incline to claim their inventions >containing the right over the contents already published prior their >submission of the applications. if this is true, we expect the patent >applicant revoke their IPR claim in the IETF data-track. if this is not >true, we expect the patent applicant explain which part in the current >464xlat or in MAP-T, not covered by the above publications, but covered by >the patent applicant's applications or granted patent(s). > >best regards, >maoke > > >> Regards, >> Masanobu >> >> >> >Hi, Vizdal and All, >> > >> >Vizdal Ales $B%O‚@%U!W!&(B: >> >> Rajiv, Guys, >> >> >> >> >> >> >> >> >> >>> Also, let's not forget that there is MAP-T as well - all about >> >>> translation. :-) The challenge in all of this is that the UE needs to >> be >> >>> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE >> >>> dependency. >> >>> >> >> >> >> btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is >> IPR'd by >> >> ChinaMobile as well claiming the same patent as for 464xlat. Given that >> >> MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat >> >> are equal from this point of view, but 464xlat is more advanced as there >> >> is a running code available (at lest for android) and this is something >> that >> >> should really matter to the IETF. >> >> >> >> >> >FYI: The stateless double translation (one of the origins of MAP-T) is >> >introduced in Section 5.2 "Double IVI" of >> >http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is >> >published on June 13, 2009, earlier than June 26, 2009. >> > >> >Regards, >> > >> >xing >> > >> > >> >_______________________________________________ >> >v6ops mailing list >> >v6ops@ietf.org >> >https://www.ietf.org/mailman/listinfo/v6ops >> >> ==================================== >> NEC AccessTechnica, Ltd. >> Marketing Promotion Department and >> Product Development Department >> KAWASHIMA Masanobu >> kawashimam@vx.jp.nec.com >> http://www.necat.co.jp/ >> ==================================== >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > ==================================== NEC AccessTechnica, Ltd. Marketing Promotion Department and Product Development Department KAWASHIMA Masanobu kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ==================================== From rajiva@cisco.com Fri Feb 8 07:55: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 E940C21F8AB6 for ; Fri, 8 Feb 2013 07:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4FuZVhyXiee for ; Fri, 8 Feb 2013 07:55:12 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4C721F8AA3 for ; Fri, 8 Feb 2013 07:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4310; q=dns/txt; s=iport; t=1360338912; x=1361548512; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vHJj9ihjYePwwi+QpkNzh+3mHnRRccwP6YqL8Cuiyno=; b=fV5RSCWzJexn2kLcqcuHDAtT7Fy2ufK/FbTxKrROfj0l9HfWiQcz5lN0 zDXRldUQgcpR2xiyv+7hiNHXfZuNi6VYp9e/CkBvsc0f37/EIBxKd5jpO zQJUBQLDC7fp5mOwWtA7oAbUbjEoJgTlVfunnAIdqecbmnkfKGtBHr9yY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAUfFVGtJXHA/2dsb2JhbABFwRMWc4IfAQEBAwF5BQcGAQgOAwMBAgsZLBEXAQUIAgQOBQgBEodkAwkGDLYNDYlWgk2JSX4QDYNKYQOUS4J2iiKFE4MAgWgHFx4 X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; d="scan'208";a="174961127" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 08 Feb 2013 15:55:12 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r18FtCFn000827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 15:55:12 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 09:55:11 -0600 From: "Rajiv Asati (rajiva)" To: Cameron Byrne Thread-Topic: More ranting on mobile ... Was Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) Thread-Index: AQHOBI2SX/YWdl7AJUKXy4eNNoelh5hwMPwA Date: Fri, 8 Feb 2013 15:55:10 +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.0.121105 x-originating-ip: [10.82.220.17] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <542845BC0CE4434686B55952C063A0C6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops-chairs@tools.ietf.org" , IPv6 Operations Subject: Re: [v6ops] More ranting on mobile ... Was Re: Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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: Fri, 08 Feb 2013 15:55:14 -0000 Cameron, > Ack, it is a HUGE dependency. And, it has been a huge surprise to me > that changing the host is easier than changing the app. But, that The dependency really is about having to rely on millions of individuals upgrading the device the OS to a version that is capable of supporting XYZ. I was quite surprised, when I found that: Few of my friends hadn't upgraded iOS since 5.x. One of my friends still ran iOS 4.x. The reality is expected to far-spread, I suspect. And this is what we worry about when rely on the end-host to make a fundamental change. We have to wait until the refresh cycle kicks in (like in case of Windows XP..). > Skype, a top 10 android app for peer to peer multimedia communication, > would adamantly and openly oppose supporting IPv6 in 2013 [1]. We should take [1] as an individual opinion, not his employer's official stance. A lot of what he described in his email apply to most big organizations as far as development/processes are concerned. > But, if you are looking for beauty contest.... No, I am not. :) > We need more practical solutions, or *A* solution, and less vaporware > beauty contest. As a network operator, i look for solutions that are > ready to ship. I agree. No doubt about it. Cheers, Rajiv -----Original Message----- From: Cameron Byrne Date: Wednesday, February 6, 2013 12:15 PM To: Rajiv Asati Cc: V=EDzdal Ale=B9 , Ole Troan , Joel jaeggli , "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: More ranting on mobile ... Was Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) >Rajiv, > >On Wed, Feb 6, 2013 at 7:48 AM, Rajiv Asati (rajiva) >wrote: >> >> I agree with Ales to translation being better in mobile environment. >> >> Overall, I do think that if 464XLAT were to be "informational", then we >> would be better off. >> >> Also, let's not forget that there is MAP-T as well - all about >> translation. :-) The challenge in all of this is that the UE needs to be >> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE >> dependency. >> > >Ack, it is a HUGE dependency. And, it has been a huge surprise to me >that changing the host is easier than changing the app. But, that >seems to be an axiom now. Roll with it. Who in 2001 thought that >Skype, a top 10 android app for peer to peer multimedia communication, >would adamantly and openly oppose supporting IPv6 in 2013 [1]. > >But, if you are looking for beauty contest.... > >The relevant data point is that there is open source code available >for 464XLAT. And, a working integration with a mobile network. There >is also a known multi-vendor inter-op documented by an amateur [2] > >The open source code has be merged into a relevant mobile operating >systems https://android-review.googlesource.com/#/c/34490/ > >Look for it on a phone near you RSN :) > >Hearkening back to this mail >http://www.ietf.org/mail-archive/web/v6ops/current/msg15116.html > >We need more practical solutions, or *A* solution, and less vaporware >beauty contest. As a network operator, i look for solutions that are >ready to ship. > >For mobile networks, here is a run down of the solutions: > >1. Dual-stack IPv4v6 PDP in 3GPP remains a bridge too far, MAJOR >network gear providers don't support it on NEW gear (which also blows >my mind, THIS IS NOT A LEGACY PROBLEM, YMMV) > >2. IPv6-only + NAT64/DNS64, works but it is only a a 90% solution >because Skype and Neflix don't work > >3. MAP-T / MAP-E, show it working on a mobile. > >4. 464XLAT let me show you it working on mobile, or do it yourself [3] > >5. NAT44, this is the vastly most common choice for all GSM / UMTS/ >LTE networks. Why? Because 1 - 4 aren't shipping yet. 464XLAT is >close. > >CB > >[1] http://mailman.nanog.org/pipermail/nanog/2012-December/053918.html >[2] https://sites.google.com/site/tmoipv6/464xlat (have not looked at >this in a year) >[3] http://dan.drown.org/android/clat/ From fred@cisco.com Fri Feb 8 12:30: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 5766921F8BBA for ; Fri, 8 Feb 2013 12:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.042 X-Spam-Level: X-Spam-Status: No, score=-110.042 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoKz7iLugksl for ; Fri, 8 Feb 2013 12:30:05 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EFD5A21F8BB7 for ; Fri, 8 Feb 2013 12:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2601; q=dns/txt; s=iport; t=1360355405; x=1361565005; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=409wNALztSEH8MkDtzZ4SVdjqkGqXjL0occ6SvVelfo=; b=FKg4rdYH9KVbhiAbMMzMZ0Oxgu8By3tJozsgF3seyCf7NYaSfWGxfLs0 zcdyeUf8bM9JmC/sD2neHSRrFwQp1DAdfOA+pmoQE7BRVL/nx3jIzMTD7 NUgNZyQ7CLi4eHmot6cLBNpbJTI+0AH9qzB16kIulcNhsEjc4G9i+xHwX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO9fFVGtJXHA/2dsb2JhbABFwQsWc4IfAQEBAwFxDQsCASokMhsKAgQbE4dwBr9CjQmDcmEDpneDAIIk X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; d="scan'208";a="175054427" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 08 Feb 2013 20:30:04 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r18KU4b7005503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Feb 2013 20:30:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 14:30:04 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org list" Thread-Topic: IETF v6ops doc review Thread-Index: AQHOBjsTCnebUm9xe0+Nsn8RTdNBpg== Date: Fri, 8 Feb 2013 20:30:03 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B772FB4@xmb-rcd-x09.cisco.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <9AA00E2B45667D429C9B85E843093E51@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Fwd: IETF v6ops doc review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Feb 2013 20:30:06 -0000 Comments from Cisco IT on the two documents in question On Dec 11, 2012, at 3:41 AM, Jon Woolwine (jwoolwin) wrote: > Sorry for the delay in getting back on this. I reviewed the 2 docs > below: >=20 > draft-ietf-v6ops-enterprise-incremental-ipv6 > draft-matthews-v6ops-design-guidelines >=20 >=20 > I agree with your assessment about the first being much more useful. I > focused my feedback below on the first: >=20 >=20 > IPv4-only Considerations > * Section talks about rogue RA problem, but what about security risk of > auto-tunneling? >=20 > Reasons for Phased Approach > * Most large enterprises have extensive extranet environments for > connectivity to partners. Extranets should also be considered in this > section. Parity in security capabilities is a major factor for IPv6 > deployment in Extranets. > * "Internet facing servers cannot be managed over IPv6 unless the > management systems are IPv6 capable". Enterprises can take an > incremental > approach here. For some aspects of service assurance you do need an > IPv6 > transport (availability and performance monitoring using synthetic > transactions). But for other aspects of network management, NMS just > needs to deal with IPv6 as data in payload of network management > traffic. > * Consider external providers for things like CDN, monitoring (e.g. > gomez), goelocation services, cloud providers (SaaS/PaaS/Iaas), etc. >=20 > Preparation and Assessment Phase > Inventory Phase > * Need to consider security capabilities there > * No talk about service providers (ISP, CDN, avail/perf monitoring, > cloud > providers (SaaS/PaaS/IaaS), ASP's, geolocation, etc) >=20 > Section 4.1 - Connectivity > * Scenario where MPLS VPN provider doesn't provide IPv6 service=A9tunnel > yourself. Guidance and best practices on tunnel solutions. >=20 > Section 5.1 - Network infrastructure > * Sometimes access switches do QoS classification based on packet > attributes; so, just because its a layer 2 switch doesn't mean its not > doing L3 operations > * FHRP - Global IP address as HSRP VIP >=20 >=20 > DDoS mitigation >=20 > Remote access VPN's - IPv6 on inside header vs outside header >=20 > Prefix filtering by ISP's >=20 > Extranets are another potential use case where NAT66 is needed; many > enterprises don't like carrying prefixes of all their partners on their > internal routing tables >=20 > For ISP and WAN circuits, be prepared to swing circuits to different > infra > on the SP side to get dual stack support. >=20 >=20 >=20 >=20 >=20 > -jon From internet-drafts@ietf.org Fri Feb 8 16:31:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772F221F8C3B; Fri, 8 Feb 2013 16:31:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBvV5FhpZlcj; Fri, 8 Feb 2013 16:31:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CAB21F8C4C; Fri, 8 Feb 2013 16:31:38 -0800 (PST) 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.37 Message-ID: <20130209003138.24373.66541.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2013 16:31:38 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.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: Sat, 09 Feb 2013 00:31:38 -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 : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interfac= e to a LAN Author(s) : Cameron Byrne Dan Drown Filename : draft-ietf-v6ops-64share-02.txt Pages : 8 Date : 2013-02-08 Abstract: This document describes three methods for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fred@cisco.com Sun Feb 10 11:00: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 7B5F021F878F for ; Sun, 10 Feb 2013 11:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.381 X-Spam-Level: X-Spam-Status: No, score=-110.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLpIb4Hw8qAC for ; Sun, 10 Feb 2013 11:00:04 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C34D721F877B for ; Sun, 10 Feb 2013 11:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=130; q=dns/txt; s=iport; t=1360522803; x=1361732403; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Alxn2js21EB6uafKl3iA+/0pOYMK0zDeAzSgOh2Y5K4=; b=GasEs7aFGs28Bqdc1BR1O3y/LST28US9CG5TZsQbF56ti8135Y2/77aJ XvEF1S1BaOGMs4tjEgTbsHE9jExwF3Etl5l011ta3rrQ6lxb5AUALDkCx TighAcLT4jcYRdDDy9rtQABe9xumYkrUUcb2UY5V+DqmPvHZUa/bD5Z7j Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAALtF1GtJV2b/2dsb2JhbABFwRIWc4IhAQQdHT8SASoUQicEDg2ICr8YkSlhA6Z3gwaCJA X-IronPort-AV: E=Sophos;i="4.84,639,1355097600"; d="scan'208";a="175528940" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 10 Feb 2013 19:00:03 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1AJ02fA003880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Feb 2013 19:00:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0328.009; Sun, 10 Feb 2013 13:00:02 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-nat64-experience WGLC Thread-Index: AQHOB8DUAibh+lCEVkyYToALQqi9WA== Date: Sun, 10 Feb 2013 19:00:02 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B780083@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.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <97B7CEEE87D7DB4D9FFB8357611D58B6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ron Bonica Subject: [v6ops] draft-ietf-v6ops-nat64-experience 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, 10 Feb 2013 19:00:04 -0000 The working group last call for this draft announced last week continues fo= r another week. Please feel free to comment on it. From holger.metschulat@telekom.de Mon Feb 11 04:55: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 1F21921F883E for ; Mon, 11 Feb 2013 04:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC9Xqvo-ZpHf for ; Mon, 11 Feb 2013 04:55:27 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1695521F8837 for ; Mon, 11 Feb 2013 04:55:25 -0800 (PST) From: Received: from he111493.emea1.cds.t-internal.com ([10.206.92.96]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 11 Feb 2013 13:55:17 +0100 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111493.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 11 Feb 2013 13:55:16 +0100 To: Date: Mon, 11 Feb 2013 13:55:16 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.txt Thread-Index: Ac4GXOAfsBaoTrscQ1yc3jtsmzaUqAB9yHgQ Message-ID: References: <20130209003138.24373.66541.idtracker@ietfa.amsl.com> In-Reply-To: <20130209003138.24373.66541.idtracker@ietfa.amsl.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.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: Mon, 11 Feb 2013 12:55:28 -0000 -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = internet-drafts@ietf.org Gesendet: Samstag, 9. Februar 2013 01:32 An: i-d-announce@ietf.org Cc: v6ops@ietf.org Betreff: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the IET= F. > > Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interfa= ce to a LAN Hi all, could the following be considered: - The UE in this case will have to behave like a router, meaning, at least = two independent link-local addresses, no propagation of ND packets from WAN= to (W)LAN and vice versa, etc. - What happens when the WAN link drops, gets reestablished, and thus a new = global prefix is assigned to the WAN link? Should the old prefix be adverti= sed with a "zero" preferred lifetime together with the new prefix? Otherwis= e, the connected devices may not put the "old" prefix into the deprecated s= tate. - Should it be added how to convey the DNS resolver addresses to the attach= ed hosts? On the 3GPP radio interface, they are retrieved from the PCO-IEs = in the 3GPP signalling, but on the LAN, usually stateless DHCPv6 (RFC3646) = or RA extensions (RFC6106) are being used. Regards, Holger From alexandru.petrescu@gmail.com Mon Feb 11 05:37: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 58A0A21F8611 for ; Mon, 11 Feb 2013 05:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.914 X-Spam-Level: X-Spam-Status: No, score=-9.914 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG1TAIwxtQt0 for ; Mon, 11 Feb 2013 05:37:49 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3621F8605 for ; Mon, 11 Feb 2013 05:37:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1BDblCf016850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Feb 2013 14:37:48 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1BDblVi012122 for ; Mon, 11 Feb 2013 14:37:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1BDbdmK010720 for ; Mon, 11 Feb 2013 14:37:47 +0100 Message-ID: <5118F423.9000809@gmail.com> Date: Mon, 11 Feb 2013 14:37:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130209003138.24373.66541.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.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: Mon, 11 Feb 2013 13:37:50 -0000 Le 11/02/2013 13:55, holger.metschulat@telekom.de a écrit : > -----Ursprüngliche Nachricht----- Von: v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] Im Auftrag von > internet-drafts@ietf.org Gesendet: Samstag, 9. Februar 2013 01:32 An: > i-d-announce@ietf.org Cc: v6ops@ietf.org Betreff: [v6ops] I-D Action: > draft-ietf-v6ops-64share-02.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Operations >> Working Group of the IETF. >> >> Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile >> Interface to a LAN > > Hi all, > > could the following be considered: > > - The UE in this case will have to behave like a router, meaning, at > least two independent link-local addresses, no propagation of ND > packets from WAN to (W)LAN and vice versa, etc. I agree. The UE will act like a router. And there will be at least two independent ll addresses. And ND packets must not be propagated. In addition, this could be a place where it should be mentioned that if the Gateway performs a NS for an address prefixed by the assigned /64, the method described in this document (extend the /64 to the LAN) will not work. (otherwise mention it elsewhere). In section 2, ND Proxy is mentioned. > - What happens when the WAN link drops, gets reestablished, and thus > a new global prefix is assigned to the WAN link? Should the old > prefix be advertised with a "zero" preferred lifetime together with > the new prefix? Otherwise, the connected devices may not put the > "old" prefix into the deprecated state. I agree, when the WAN link drops, the UE should gracefully notify its Clients that that prefix is no longer valid. I guess it should be 'zero' preferred lifetime, with the old prefix, but not the new prefix. No? > - Should it be added how to convey the DNS resolver addresses to the > attached hosts? On the 3GPP radio interface, they are retrieved from > the PCO-IEs in the 3GPP signalling, but on the LAN, usually > stateless DHCPv6 (RFC3646) or RA extensions (RFC6106) are being > used. I agree there is a need to offer the DNS resolver from UE to the Clients on LAN. And that could be done with stateless DHCPv6, full DHCPv6, or RA extensions - any of these 3 means. I think there is not a fourth. There may even be possibility that UE runs DHCP Relay and the Clients on LAN obtain the address of the DNS resolver straight from the DNS Server in the infrastructure. (this may exist). Alex > > Regards, Holger > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From cb.list6@gmail.com Mon Feb 11 09:44:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61321F8651 for ; Mon, 11 Feb 2013 09:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTQMHiOSWuNV for ; Mon, 11 Feb 2013 09:44:13 -0800 (PST) Received: from mail-ye0-f171.google.com (mail-ye0-f171.google.com [209.85.213.171]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9821F84F9 for ; Mon, 11 Feb 2013 09:44:13 -0800 (PST) Received: by mail-ye0-f171.google.com with SMTP id m8so1292246yen.2 for ; Mon, 11 Feb 2013 09:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=jv5feCEeIbS/yWAUo1I5Yk31u1pnghe2vgir5iECx/0=; b=eGhx8RRaVCcWlVPvQw7TsUQkElx+3LCRX2e/SUpsoxLG5RybOpI8nsGwBfR1plOuW6 rYwQrVOc3CEMfX8HiXTlxtNgqW8pxBWDUWmI/mFJhlbq/N1CZD21pfN/zui0g+geWxKY Gy0kkvTerA/7MXzV7sZ2X2x601PFgTNiSTiVWKPfCwJLOlbJzEn7VpV26luWJf1C4f8w vxIjU5lUjE+AzOrTdQwJy/7DYlcjPTCe2fEdffxMWG5owCL5oBO9ZcnQh6nqeJOCHIMy wN/xDUcDXZBqjptbw7QEN47rS1OmqyNicfjHSOLEiWDRssP3VD3bOz/JI+Amu3YNTGMX 94rQ== MIME-Version: 1.0 X-Received: by 10.236.172.164 with SMTP id t24mr18910622yhl.1.1360604652744; Mon, 11 Feb 2013 09:44:12 -0800 (PST) Received: by 10.236.82.44 with HTTP; Mon, 11 Feb 2013 09:44:12 -0800 (PST) In-Reply-To: References: <20130209003138.24373.66541.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 09:44:12 -0800 Message-ID: From: Cameron Byrne To: holger.metschulat@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.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: Mon, 11 Feb 2013 17:44:14 -0000 Holger, On Mon, Feb 11, 2013 at 4:55 AM, wrote: > -----Urspr=FCngliche Nachricht----- > Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag vo= n internet-drafts@ietf.org > Gesendet: Samstag, 9. Februar 2013 01:32 > An: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Betreff: [v6ops] I-D Action: draft-ietf-v6ops-64share-02.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the IPv6 Operations Working Group of the IE= TF. >> >> Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile = Interface to a LAN > > Hi all, > > could the following be considered: > > - The UE in this case will have to behave like a router, meaning, at leas= t two independent link-local addresses, no propagation of ND packets from W= AN to (W)LAN and vice versa, etc. Yes, i believe the existing text makes that clear. Do you believe that is not clear? > - What happens when the WAN link drops, gets reestablished, and thus a ne= w global prefix is assigned to the WAN link? Should the old prefix be adver= tised with a "zero" preferred lifetime together with the new prefix? Otherw= ise, the connected devices may not put the "old" prefix into the deprecated= state. http://tools.ietf.org/html/draft-ietf-v6ops-64share-02#section-3.0 The existing text states "The LAN interface RA configuration must be tightl= y coupled with the 3GPP interface state. If the 3GPP interface goes down or changes the IPv6 prefix, that state should be reflected in the LAN IPv6 configuration. " I believe this covers what you are talking about without going into the mechanics of how it is achieved. For this informational document, i would like to avoid details that are so specific. > - Should it be added how to convey the DNS resolver addresses to the atta= ched hosts? On the 3GPP radio interface, they are retrieved from the PCO-IE= s in the 3GPP signalling, but on the LAN, usually stateless DHCPv6 (RFC3646= ) or RA extensions (RFC6106) are being used. > I would also like to avoid this detail. This topic is not germane to how to share a prefix. Including this detail makes it start to look too much like a CPE specification. CB > Regards, > Holger > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Mon Feb 11 12:20: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 8D34D21F8971 for ; Mon, 11 Feb 2013 12:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxWcmALzz73l for ; Mon, 11 Feb 2013 12:20:06 -0800 (PST) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with SMTP id 2871721F8837 for ; Mon, 11 Feb 2013 12:20:06 -0800 (PST) Received: from [98.139.212.151] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2013 20:20:05 -0000 Received: from [98.139.212.246] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2013 20:20:05 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 11 Feb 2013 20:20:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 641417.38211.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 99494 invoked by uid 60001); 11 Feb 2013 20:20:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360614005; bh=i+fLekkHeHDu0EkhVA6dcr5o2BIOjFFX053kT0KD5vk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=41jaLAQAMyyMPuZqnpD66GDuCiwVBLcyDqjLKKPRtSt66UUyIJeKj2DSyhq5rJEmfnMdyzdQLeEtd6ts5l5b8tY0HB81s/k0o9KXy2l01faYJKIdPzdbR8IohJ1GE9yFlmxN4tWRGUQA1c5gRldlk4cjoz2KOeqgJlxT9RpaoQc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=F4AzKS4UvziZdTH+bVUZq5+TMYT3VK91lVUrokh8tBmf27gnNR6QydB3T2NYc40YmjK1OdjM9N9pSvbJ9CFIfMCsRm4rCTu8/idSCwZ6TgJ+PtQ5gsNs+jpGRc8h/l8+dhQfZoU0zNjBc2amhhusfel+wXT73ZkJv6UH0gihBYY=; X-YMail-OSG: qoujemkVM1mOr4yHW7jBePLzpQkZ_nQifoydnJz4dwpfpuS JWWPFSg0O179mfN51knheqYyj5CV21dXXBGc30p7ZSS1IhZw3U_mcKJL5_VD l5EEFa_WfG2eb._t3aoeZFNR_ZMgM9S44IqUy8cDFDVMsmbdP_WtfOtQu.6H .4SF2kDiJaIPdm2wzUq_guMTA1Wb4jo1UuITAPwPDgAYpxCnIesx8cmMeTwo ZfZNGya0AfWg3DYeenONKv5BV_ZNn5U8lPrLQscJUbwS5tqnTmh4ZEnOyvZk 2o6olC7TxknZyUurENbb.r1RjaJ5jHGEBosrMJ.1wtEOGHZsWi9VZGEnLV76 s0tLd8OCdCz90eCCTz9rMLHz1qVsEiKBkMK7jbmBkpq5Y_z_fSslz3rJnzMt w3cR2_.gIVxAMzqM09O8Ee6DVk0cExnUvhuKxwcrsVZ4_sAcoool45k0BQvi hMO_VDvvhhGnZk6PaGkRGJHuVIDI.RFJJV4Ca5AXoU4arikaGvP.tjWnydoY yhlhsa_oOE5hWzRv2r5AttHw- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Mon, 11 Feb 2013 12:20:05 PST X-Rocket-MIMEInfo: 001.001, SGksCgpIZXJlIGlzIGEgbmV3IHZlcnNpb24gb2YgbXkgSVB2NiBsYXJnZXIgbG9vcGJhY2sgcHJlZml4IGRyYWZ0LiBDaGFuZ2VzIHNpbmNlIHRoZSBwcmV2aW91cyB2ZXJzaW9uOgoKbyDCoGRlZmF1bHQgYWRkcmVzcyBzZWxlY3Rpb24gcHJlY2VkZW5jZSBhbmQgbGFiZWwgdmFsdWVzCm8gwqBjb21tZW50IGFib3V0IG90aGVyIElQdjQgaW4gSVB2NiBhZGRyZXNzIGZvcm1zCgpvIMKgbW9yZSBjbGFyaWZpY2F0aW9ucwoKbyDCoGdyYW1tYXIgY29ycmVjdGlvbnMKCgpNeSB0aGFua3MgdG8gQmlsbCBBdHdvb2QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> Message-ID: <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 11 Feb 2013 12:20:05 -0800 (PST) From: Mark Smith To: v6ops v6ops WG In-Reply-To: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 20:20:08 -0000 Hi,=0A=0AHere is a new version of my IPv6 larger loopback prefix draft. Cha= nges since the previous version:=0A=0Ao =A0default address selection preced= ence and label values=0Ao =A0comment about other IPv4 in IPv6 address forms= =0A=0Ao =A0more clarifications=0A=0Ao =A0grammar corrections=0A=0A=0AMy tha= nks to Bill Atwood, Matts=A0Kallioniemi and=A0Tina Tsou for their review an= d comments on this revision.=0A=0AFurther review and comments would be most= appreciated.=0A=0AThanks,=0AMark.=A0=0A=0A=0A=0A----- Forwarded Message --= ---=0A> From: "internet-drafts@ietf.org" =0A> To:= markzzzsmith@yahoo.com.au=0A> Cc: =0A> Sent: Tuesday, 12 February 2013 7:1= 2 AM=0A> Subject: New Version Notification for draft-smith-v6ops-larger-ipv= 6-loopback-prefix-03.txt=0A> =0A> =0A> A new version of I-D, draft-smith-v6= ops-larger-ipv6-loopback-prefix-03.txt=0A> has been successfully submitted = by Mark Smith and posted to the=0A> IETF repository.=0A> =0A> Filename:=A0= =A0=A0 draft-smith-v6ops-larger-ipv6-loopback-prefix=0A> Revision:=A0=A0= =A0 03=0A> Title:=A0=A0=A0 =A0=A0=A0 A Larger Loopback Prefix for IPv6=0A= > Creation date:=A0=A0=A0 2013-02-11=0A> WG ID:=A0=A0=A0 =A0=A0=A0 Indivi= dual Submission=0A> Number of pages: 12=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A= > http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopbac= k-prefix-03.txt=0A> Status:=A0 =A0 =A0 =A0 =A0 =0A> http://datatracker.ietf= .org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix=0A> Htmlized:=A0 =A0= =A0 =A0 =0A> http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loop= back-prefix-03=0A> Diff:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/rf= cdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback-prefix-03=0A> =0A> Abst= ract:=0A> =A0 During the development and testing of a network application,= it can=0A> =A0 be useful to run multiple instances of the application usi= ng the same=0A> =A0 transport layer protocol port on the same development = host, while=0A> =A0 also having network access to the application instance= s limited to=0A> =A0 the local host.=A0 Under IPv4, this has been possible= by using=0A> =A0 different loopback addresses within 127/8.=A0 It is not = possible under=0A> =A0 IPv6, as the loopback prefix of ::1/128 only provid= es a single=0A> =A0 loopback address.=A0 This memo proposes a new larger l= oopback prefix=0A> =A0 that will provide many IPv6 loopback addresses.=0A>= =0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =0A> =A0 =0A> =0A> =0A> The IETF Secretariat=0A> From owen@delong.com Mon Feb 11 12:29: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 8285521F892F for ; Mon, 11 Feb 2013 12:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efoEif4Rnf-R for ; Mon, 11 Feb 2013 12:29:42 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id CC55A21F8923 for ; Mon, 11 Feb 2013 12:29:42 -0800 (PST) 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 r1BKSMBY010604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Feb 2013 12:28:23 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1BKSMBY010604 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360614503; bh=vQYiG+XY9bptqw5upmQJvxa8F48=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=m8ECliRYhn/2ma0YdhdISKQ1JF4Vftta/MyFE3XTKzU+Rpb7+ZxOgkeSBWpssENSx 7WG9gYGpWdXu0nULF69hihixYZOuY9XcLh+vHOlCAZrzHaQ/ncqNgWuNhuaGmvkj8F Z2R36V8WE+oCfbZUebHv4CITb2xzwPL5qORJ2llw= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 11 Feb 2013 12:28:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 11 Feb 2013 12:28:23 -0800 (PST) Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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: Mon, 11 Feb 2013 20:29:43 -0000 Perhaps I'm not very bright, but is there any reason ULA couldn't be = used on the LO interface to satisfy this corner case? Owen On Feb 11, 2013, at 12:20 , Mark Smith = wrote: > Hi, >=20 > Here is a new version of my IPv6 larger loopback prefix draft. Changes = since the previous version: >=20 > o default address selection precedence and label values > o comment about other IPv4 in IPv6 address forms >=20 > o more clarifications >=20 > o grammar corrections >=20 >=20 > My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou for their = review and comments on this revision. >=20 > Further review and comments would be most appreciated. >=20 > Thanks, > Mark.=20 >=20 >=20 >=20 > ----- Forwarded Message ----- >> From: "internet-drafts@ietf.org" >> To: markzzzsmith@yahoo.com.au >> Cc:=20 >> Sent: Tuesday, 12 February 2013 7:12 AM >> Subject: New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>=20 >>=20 >> A new version of I-D, = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >> has been successfully submitted by Mark Smith and posted to the >> IETF repository. >>=20 >> Filename: draft-smith-v6ops-larger-ipv6-loopback-prefix >> Revision: 03 >> Title: A Larger Loopback Prefix for IPv6 >> Creation date: 2013-02-11 >> WG ID: Individual Submission >> Number of pages: 12 >> URL: =20 >> = http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback= -prefix-03.txt >> Status: =20 >> = http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-pre= fix >> Htmlized: =20 >> = http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-0= 3 >> Diff: =20 >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback-= prefix-03 >>=20 >> Abstract: >> During the development and testing of a network application, it = can >> be useful to run multiple instances of the application using the = same >> transport layer protocol port on the same development host, while >> also having network access to the application instances limited to >> the local host. Under IPv4, this has been possible by using >> different loopback addresses within 127/8. It is not possible = under >> IPv6, as the loopback prefix of ::1/128 only provides a single >> loopback address. This memo proposes a new larger loopback prefix >> that will provide many IPv6 loopback addresses. >>=20 >> = =20 >> =20 >>=20 >>=20 >> The IETF Secretariat >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Mon Feb 11 12:48:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDABF21F8A6F for ; Mon, 11 Feb 2013 12:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.63 X-Spam-Level: X-Spam-Status: No, score=-0.63 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, SARE_URI_REPLICA=1.634] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnZqcGLDKsqQ for ; Mon, 11 Feb 2013 12:48:05 -0800 (PST) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with SMTP id CE8C721F8797 for ; Mon, 11 Feb 2013 12:48:04 -0800 (PST) Received: from [98.139.212.151] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2013 20:48:03 -0000 Received: from [98.139.212.237] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2013 20:48:03 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 11 Feb 2013 20:48:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 831038.96627.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 61021 invoked by uid 60001); 11 Feb 2013 20:48:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360615683; bh=6fs9igCziGl7jxmr/Gj7ZoF+xsLERK06tJ2+nHqL8pA=; 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=DTgEudtVceCv0DMJck8cXMAfrneJqWl6lg5QL7zHZnE+5dLzWwlUwDg2o7A/b2DvdNLS9ToloxvXTBBIjJxA4AvI29KQUIVIedaoZKFXnzPxrMNU0unfiz9OSQ4D5HkFKY2SJpU/JRqCpkwaXSA/oeOhBrHFrkG+RtZQ+iCI2HQ= 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=K+0W/O18H10+1sGh3YrYWGKHbPU6hDp0d1rBp1ZzchqrUlUDPcExFo0hC5fkbaidPckJCDip7KCRcIzxbPBoW5tHqZSDYqUASgmafXGcTypKHplPIWV9vFt8Wa8aC975LBgqfPQ9euL6ByrMghppDikEnNODbsgvisPnLkiWgrs=; X-YMail-OSG: y8YVFVQVM1mJtXRwd0jBvlgddJruZKE0uyrD15J.uehFp5k 2KYHnEc1zUwqsOM7HYD44nN7DF3ZL.7sBMTSHEYgpef4f231e1ErOGUBWBM9 KvKJ.svQDOSxTTOgRajxaLxOgvfwQEUagnEtrff1hTLme2KRdbMq.drcOWoZ 3p8tYqbWiWSxeh1nPFZhPYYpIQMMQ_cn90Xf0Mmmy5_lRBUygi2wuHZndELb 79s1a2Z5ogysCwWdBkwl_awNcwEewne8jBFgHxYYrCtZXUkLAvC2OWZ3n6A1 DV6AU90FZLO6F12X.O4fe1onTQZA4_nzvZ1DugOgRp8rj0EO81lyAPdyFP64 a7PJJ47kQE_fnHqGiTu.zyR_y6NydzZdpSPUyqzlMJhXJcb.VSiUWXr0671X x.JrKkbaH5bTI4yRd0vyYD7O3ESCuXicvqU6WRyWXWj8Y.4HtSXZMgFHRc.I OadhZJU8DzjiWssXXyEtHdxFsoDRl_pDQqXfw.zwZaioUwcJkEvCn4.aUs4K XeuI095FM2A2WwkQJ8QB7HS6UUxy_bq64sV0.qgFW75fMT9_utnfLJPbdPvb e3X25CqxM54Yw0uT11W03CvtMfcrPWtUDclLX9EGjstGSZLCqv6uwC32IrnN OAA-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Mon, 11 Feb 2013 12:48:03 PST X-Rocket-MIMEInfo: 001.001, RnJvbSB0aGUgSW50cm86CgoiQSBVbmlxdWUgTG9jYWwgSVB2NiBVbmljYXN0IEFkZHJlc3MgKFVMQSkgcHJlZml4IFtSRkM0MTkzXSBjb3VsZCBiZSB1c2VkIHRvIGluY3JlYXNlIHRoZSBudW1iZXIgb2YgYWRkcmVzc2VzIGF2YWlsYWJsZSBvbiB0aGUgbG9jYWwgaG9zdC4gSG93ZXZlciB0aGlzIHByZWZpeCB3b3VsZCBuZWVkIHRvIGJlIG1hbnVhbGx5IGdlbmVyYXRlZCBhbmQgY29uZmlndXJlZCBhdCBsZWFzdCBvbmNlIGJ5IGEgc3lzdGVtIGFkbWluaXN0cmF0b3Igb3Igb3BlcmF0b3IuIFdpdGhvdXQgYWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> Message-ID: <1360615683.60384.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Mon, 11 Feb 2013 12:48:03 -0800 (PST) From: Mark Smith To: Owen DeLong In-Reply-To: <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 20:48:07 -0000 >From the Intro:=0A=0A"A Unique Local IPv6 Unicast Address (ULA) prefix [RFC= 4193] could be used to increase the number of addresses available on the lo= cal host. However this prefix would need to be manually generated and confi= gured at least once by a system administrator or operator. Without additona= l configuration, traffic towards addresses not assigned to the local host w= ould not be prevented from leaving the host, and access may not be limited = to the local host. A ULA prefix would not be well known, and would not be = convenient to remember and type without violating the randomness requiremen= ts of the Global ID component of a ULA prefix."=0A=0AFor reference, the "ca= ndidate" existing unicast addresses that are either covered in the draft or= people have raised with my off-list (and I don't think are necessary to co= ver in the draft) are=0A- ULA=0A- link local prefix on loopback=0A- 100.64/= 10=0A- 100::/64=0AIn all cases, they would not be user friendly enough (I u= sed a ULA for this purpose during development of http://developer.berlios.d= e/projects/replicast/), would need operator intervention to enable rather t= han always being available, or would be overloading the existing purpose of= the prefix and therefore the prefix's use would have to be respecified.=0A= The fundamental problem is that ::1/128 contains only one address, the fund= amental solution is to preserve the loopback prefix functionality, utility = and ubiquity but make it bigger. =0A=0A=0A=0A----- Original Message -----= =0A> From: Owen DeLong =0A> To: Mark Smith =0A> Cc: v6ops v6ops WG =0A> Sent: Tuesday, 12 = February 2013 7:28 AM=0A> Subject: Re: [v6ops] Fw: New Version Notification= for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A> =0A> Perhaps = I'm not very bright, but is there any reason ULA couldn't be =0A> used on t= he LO interface to=0A> satisfy this corner case?=0A> =0A> Owen=0A> =0A> On = Feb 11, 2013, at 12:20 , Mark Smith wrote:=0A> = =0A>> Hi,=0A>> =0A>> Here is a new version of my IPv6 larger loopback pre= fix draft. Changes =0A> since the previous version:=0A>> =0A>> o=A0 defaul= t address selection precedence and label values=0A>> o=A0 comment about ot= her IPv4 in IPv6 address forms=0A>> =0A>> o=A0 more clarifications=0A>> = =0A>> o=A0 grammar corrections=0A>> =0A>> =0A>> My thanks to Bill Atwood,= Matts Kallioniemi and Tina Tsou for their review =0A> and comments on this= revision.=0A>> =0A>> Further review and comments would be most appreciate= d.=0A>> =0A>> Thanks,=0A>> Mark. =0A>> =0A>> =0A>> =0A>> ----- Forwarded= Message -----=0A>>> From: "internet-drafts@ietf.org" =0A> =0A>>> To: markzzzsmith@yahoo.com.au=0A>>> Cc: =0A>>> Sent: T= uesday, 12 February 2013 7:12 AM=0A>>> Subject: New Version Notification f= or =0A> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A>>> =0A>>> = =0A>>> A new version of I-D, =0A> draft-smith-v6ops-larger-ipv6-loopback-p= refix-03.txt=0A>>> has been successfully submitted by Mark Smith and poste= d to the=0A>>> IETF repository.=0A>>> =0A>>> Filename:=A0 =A0 draft-smit= h-v6ops-larger-ipv6-loopback-prefix=0A>>> Revision:=A0 =A0 03=0A>>> Titl= e:=A0 =A0 =A0 =A0 A Larger Loopback Prefix for IPv6=0A>>> Creation date:= =A0 =A0 2013-02-11=0A>>> WG ID:=A0 =A0 =A0 =A0 Individual Submission=0A>= >> Number of pages: 12=0A>>> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A>>> =0A> http= ://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback-pref= ix-03.txt=0A>>> Status:=A0 =A0 =A0 =A0 =A0 =0A>>> =0A> http://datatracker.= ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix=0A>>> Htmlized:= =A0 =A0 =A0 =A0 =0A>>> =0A> http://tools.ietf.org/html/draft-smith-v6ops-la= rger-ipv6-loopback-prefix-03=0A>>> Diff:=A0 =A0 =A0 =A0 =A0 =A0 =0A>>> =0A= > http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback= -prefix-03=0A>>> =0A>>> Abstract:=0A>>> =A0 =A0 During the development and= testing of a network application, it can=0A>>> =A0 =A0 be useful to run mu= ltiple instances of the application using the =0A> same=0A>>> =A0 =A0 trans= port layer protocol port on the same development host, while=0A>>> =A0 =A0 = also having network access to the application instances limited to=0A>>> = =A0 =A0 the local host.=A0 Under IPv4, this has been possible by using=0A>>= > =A0 =A0 different loopback addresses within 127/8.=A0 It is not possible = under=0A>>> =A0 =A0 IPv6, as the loopback prefix of ::1/128 only provides a= single=0A>>> =A0 =A0 loopback address.=A0 This memo proposes a new larger = loopback prefix=0A>>> =A0 =A0 that will provide many IPv6 loopback addresse= s.=0A>>> =0A>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =0A> =A0 =A0 =A0 =A0 =0A>>> =A0 =0A>>> =0A>>> =0A>>> The IETF = Secretariat=0A>>> =0A>> _______________________________________________=0A= >> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/mail= man/listinfo/v6ops=0A> From otroan@employees.org Mon Feb 11 13:32: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 DF81521F8758 for ; Mon, 11 Feb 2013 13:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=-2.117, BAYES_50=0.001, SARE_URI_REPLICA=1.634] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwCQIN3Zzq9r for ; Mon, 11 Feb 2013 13:32:54 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 4154021F879B for ; Mon, 11 Feb 2013 13:32:54 -0800 (PST) Received: from otroan-mac.getinternet.no (cm-84.209.200.28.getinternet.no [84.209.200.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 0AD5F5ED6; Mon, 11 Feb 2013 13:32:52 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <1360615683.60384.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Mon, 11 Feb 2013 22:32:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <1360615683.60384.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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: Mon, 11 Feb 2013 21:32:55 -0000 > "A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be = used to increase the number of addresses available on the local host. = However this prefix would need to be manually generated and configured = at least once by a system administrator or operator. Without additonal = configuration, traffic towards addresses not assigned to the local host = would not be prevented from leaving the host, and access may not be = limited to the local host. A ULA prefix would not be well known, and = would not be convenient to remember and type without violating the = randomness requirements of the Global ID component of a ULA prefix." >=20 > For reference, the "candidate" existing unicast addresses that are = either covered in the draft or people have raised with my off-list (and = I don't think are necessary to cover in the draft) are > - ULA > - link local prefix on loopback > - 100.64/10 > - 100::/64 > In all cases, they would not be user friendly enough (I used a ULA for = this purpose during development of = http://developer.berlios.de/projects/replicast/), would need operator = intervention to enable rather than always being available, or would be = overloading the existing purpose of the prefix and therefore the = prefix's use would have to be respecified. > The fundamental problem is that ::1/128 contains only one address, the = fundamental solution is to preserve the loopback prefix functionality, = utility and ubiquity but make it bigger.=20 ::/96 ? cheers, Ole From farmer@umn.edu Mon Feb 11 13:37: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 006A321F8855 for ; Mon, 11 Feb 2013 13:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfAZ-tfhwiIX for ; Mon, 11 Feb 2013 13:37:16 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5B86521F87C5 for ; Mon, 11 Feb 2013 13:37:16 -0800 (PST) Received: from mail-ob0-f197.google.com (mail-ob0-f197.google.com [209.85.214.197]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 11 Feb 2013 15:37:05 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f197.google.com [209.85.214.197] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f197.google.com with SMTP id ta14so31432515obb.4 for ; Mon, 11 Feb 2013 13:37:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=mCvfSPjEBhMdPoKOnTSnlSYWK48aWT/ELLKJYvgsWqM=; b=G8DjCoAt6pNd1BzfYmsH+XcjNuoUhrDir91plYoQuOqCENxsWEtDP2b+FOaGN3vPSP vWBTtLLmFbmvoHThNGYsgLYCH9TviaOjr7awJ/h3CRk8pHVojulCBLheI4SmY9nLjOdV 0vguQRI31d1M1IjzgstykUB6f5wdfoQBjAO+BLa2alK5Cutq9T9xVxDBEea2pGMzRaqI K+ZF6+xpXvTtY+66h2WxMYih6jHbqh28ypM/TMmNbvmxzlOWb1KkVZd/Rk1GafLGf0sA y4Ld6r4v4CHeq+RYF/Xsi9Qaezhar7cRnJR/ZUkkQpls2F6KNWC9hddd0Ia5mouVOjKL m+2w== X-Received: by 10.50.170.66 with SMTP id ak2mr14674176igc.38.1360618625336; Mon, 11 Feb 2013 13:37:05 -0800 (PST) X-Received: by 10.50.170.66 with SMTP id ak2mr14674081igc.38.1360618624119; Mon, 11 Feb 2013 13:37:04 -0800 (PST) Received: from infotech-plr-02.nhs.umn.edu ([2607:ea00:101:2001:a5b5:c5d0:1ded:f3f6]) by mx.google.com with ESMTPS id nh1sm10196300igc.4.2013.02.11.13.37.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 13:37:03 -0800 (PST) Message-ID: <51196486.9030007@umn.edu> Date: Mon, 11 Feb 2013 15:37:10 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Owen DeLong References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> In-Reply-To: <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn8R0w24XiMAMRHLB3p6ZsP7j9CjMLMDeEmWIfViTLTlKWbe+O6duCP4Vs3vNYu9AKJG/UeqI6MY9WjRpFYo4zjYRFZzAJFVMuYFTUWvg4+ft+x7ph1BwyeDNZ1EsrAqvs/k2Kd Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt 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: Mon, 11 Feb 2013 21:37:17 -0000 On 2/11/13 14:28 , Owen DeLong wrote: > Perhaps I'm not very bright, but is there any reason ULA couldn't be used on the LO interface to > satisfy this corner case? The Draft does cover why ULA is thought to not be a sufficient solution, do you disagree with the reasoning in the draft? from Section 1; A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be used to increase the number of addresses available on the local host. However this prefix would need to be manually generated and configured at least once by a system administrator or operator. Without additonal configuration, traffic towards addresses not assigned to the local host would not be prevented from leaving the host, and access may not be limited to the local host. A ULA prefix would not be well known, and would not be convenient to remember and type without violating the randomness requirements of the Global ID component of a ULA prefix. > Owen > > On Feb 11, 2013, at 12:20 , Mark Smith wrote: > >> Hi, >> >> Here is a new version of my IPv6 larger loopback prefix draft. Changes since the previous version: >> >> o default address selection precedence and label values >> o comment about other IPv4 in IPv6 address forms >> >> o more clarifications >> >> o grammar corrections >> >> >> My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou for their review and comments on this revision. >> >> Further review and comments would be most appreciated. >> >> Thanks, >> Mark. -- ================================================ 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 dougb@dougbarton.us Mon Feb 11 14:46: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 A731921F8820 for ; Mon, 11 Feb 2013 14:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoAojo-nAvIs for ; Mon, 11 Feb 2013 14:46:23 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 01F4621F880F for ; Mon, 11 Feb 2013 14:46:23 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:ec87:cb59:be5e:1770] (unknown [IPv6:2001:470:d:5e7:ec87:cb59:be5e:1770]) by dougbarton.us (Postfix) with ESMTPSA id 9537922B1C for ; Mon, 11 Feb 2013 22:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1360622782; bh=8yJ8orRJ/P3qgpgB0cMTPtZjOABR1+94m7WBgmaoxUg=; h=Date:From:To:Subject:References:In-Reply-To; b=uFXuT6l24ciWxRHgtmtijjVdcaFSPKwnZHx8qmx8XblYvrgGtBGIrBZ7MheGnzvfk Vx5HQ0jUkDUBNmJZ04J3Vu9s3AXMjvSTx76BLZzWA5C7IU4UyyiX8jlF82/Ku7181I GvpcHqikUY2Fxnyc9uD7Dj8eD0szLLYK6hFD1wpg= Message-ID: <511974BE.80001@dougbarton.us> Date: Mon, 11 Feb 2013 14:46:22 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> In-Reply-To: <51196486.9030007@umn.edu> X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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: Mon, 11 Feb 2013 22:46:23 -0000 The draft does cover that, yes. The question is not, "Is ULA harder?" the question is, "Is the extra work required by the draft for EVERY IMPLEMENTATION worth it to handle the corner case described in the draft?" Note, I don't know the answer, but I'm leaning heavily towards, "no." Primarily because we're asking people to deploy this protocol for real-world scenarios, and we already have a pretty wide divergence in the latest state of the standards vs. the oldest working deployed base. Widening that gap should only be done for truly critical changes, and I'm not sure you've made your case sufficiently. Put more simply, at some point we have to stop tinkering with the plane while it's in the air. Doug On 02/11/2013 01:37 PM, David Farmer wrote: > On 2/11/13 14:28 , Owen DeLong wrote: >> Perhaps I'm not very bright, but is there any reason ULA couldn't be >> used on the LO interface to >> satisfy this corner case? > > The Draft does cover why ULA is thought to not be a sufficient solution, > do you disagree with the reasoning in the draft? > > from Section 1; > > A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be > used to increase the number of addresses available on the local host. > However this prefix would need to be manually generated and > configured at least once by a system administrator or operator. > Without additonal configuration, traffic towards addresses not > assigned to the local host would not be prevented from leaving the > host, and access may not be limited to the local host. A ULA prefix > would not be well known, and would not be convenient to remember and > type without violating the randomness requirements of the Global ID > component of a ULA prefix. > >> Owen >> >> On Feb 11, 2013, at 12:20 , Mark Smith wrote: >> >>> Hi, >>> >>> Here is a new version of my IPv6 larger loopback prefix draft. >>> Changes since the previous version: >>> >>> o default address selection precedence and label values >>> o comment about other IPv4 in IPv6 address forms >>> >>> o more clarifications >>> >>> o grammar corrections >>> >>> >>> My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou for their >>> review and comments on this revision. >>> >>> Further review and comments would be most appreciated. >>> >>> Thanks, >>> Mark. > > > From owen@delong.com Mon Feb 11 16:14: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 CA3AD21F8A66 for ; Mon, 11 Feb 2013 16:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-66eYLSWyns for ; Mon, 11 Feb 2013 16:14:53 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D348821F8A61 for ; Mon, 11 Feb 2013 16:14:53 -0800 (PST) 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 r1C0BGac014781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Feb 2013 16:11:16 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1C0BGac014781 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360627877; bh=WUfyThCRcBgumutj7boUaKuuxvA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ey33QWWbZar0mz+nR5eg41k81nBTTPe4QE6PBVctwSRwX/McbKKH40Lgp5B269qBm TE83LEMExX7vANE233sDeaL3btTWfV1jMx6nSXjmqCQ4K83DvB6JcXszO0xqewokVt lIPOfAqztCsf3AA0Nk6voX60ZKwY78obkHpr30nM= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 11 Feb 2013 16:11:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0F667127-95DC-4A2F-800E-4FEE9734E831@delong.com> References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 11 Feb 2013 16:11:17 -0800 (PST) Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 00:14:54 -0000 My reading of the draft leads me to believe that there is no gain in = creating an expanded loopback prefix instead of a simple recommendation that people faced with the challenge of wanting = more addresses on a loopback interface simply configure ULA addresses onto that interface. Admittedly, I haven't tested this exhaustively, but on Linux and MacOS, = I get good results: [root@owen ~]# ifconfig lo lo Link encap:Local Loopback =20 inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:45357270 errors:0 dropped:0 overruns:0 frame:0 TX packets:45357270 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0=20 RX bytes:460117602 (438.8 MiB) TX bytes:460117602 (438.8 MiB) [root@owen ~]# ifconfig lo add fd00:0db8::1/64 [root@owen ~]# ifconfig lo lo Link encap:Local Loopback =20 inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: fd00:0db8::1/64 Scope:Global inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:45357276 errors:0 dropped:0 overruns:0 frame:0 TX packets:45357276 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0=20 RX bytes:460118944 (438.8 MiB) TX bytes:460118944 (438.8 MiB) As such, I would rather document that a loopback interface "should" = support additional addresses like any other interface and let people use ULA, GUA, etc. for that purpose than create = yet another special-case prefix with the attendant requirement that everyone modify their code. It seems to me that the existence of a valid solution which does not = require tinkering with the plane at all (at least in many cases) is preferable to one that requires tinkering with all of = the airplanes in flight (which is my understanding of the current draft). If I have misread something, I apologize. Owen On Feb 11, 2013, at 12:20 , Mark Smith = wrote: > Hi, >=20 > Here is a new version of my IPv6 larger loopback prefix draft. Changes = since the previous version: >=20 > o default address selection precedence and label values > o comment about other IPv4 in IPv6 address forms >=20 > o more clarifications >=20 > o grammar corrections >=20 >=20 > My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou for their = review and comments on this revision. >=20 > Further review and comments would be most appreciated. >=20 > Thanks, > Mark.=20 >=20 >=20 >=20 > ----- Forwarded Message ----- >> From: "internet-drafts@ietf.org" >> To: markzzzsmith@yahoo.com.au >> Cc:=20 >> Sent: Tuesday, 12 February 2013 7:12 AM >> Subject: New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>=20 >>=20 >> A new version of I-D, = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >> has been successfully submitted by Mark Smith and posted to the >> IETF repository. >>=20 >> Filename: draft-smith-v6ops-larger-ipv6-loopback-prefix >> Revision: 03 >> Title: A Larger Loopback Prefix for IPv6 >> Creation date: 2013-02-11 >> WG ID: Individual Submission >> Number of pages: 12 >> URL: =20 >> = http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback= -prefix-03.txt >> Status: =20 >> = http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-pre= fix >> Htmlized: =20 >> = http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-0= 3 >> Diff: =20 >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback-= prefix-03 >>=20 >> Abstract: >> During the development and testing of a network application, it = can >> be useful to run multiple instances of the application using the = same >> transport layer protocol port on the same development host, while >> also having network access to the application instances limited to >> the local host. Under IPv4, this has been possible by using >> different loopback addresses within 127/8. It is not possible = under >> IPv6, as the loopback prefix of ::1/128 only provides a single >> loopback address. This memo proposes a new larger loopback prefix >> that will provide many IPv6 loopback addresses. >>=20 >> = =20 >> =20 >>=20 >>=20 >> The IETF Secretariat >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Mon Feb 11 19:12: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 82F2221F88B4 for ; Mon, 11 Feb 2013 19:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-6lQaPKNRR4 for ; Mon, 11 Feb 2013 19:12:13 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2048821F8849 for ; Mon, 11 Feb 2013 19:12:13 -0800 (PST) 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 r1C3CA3M086909 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 12 Feb 2013 03:12:12 GMT (envelope-from joelja@bogus.com) Message-ID: <5119B305.9000404@bogus.com> Date: Mon, 11 Feb 2013 19:12:05 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs , Ronald Bonica References: <51100E9D.6050803@bogus.com> In-Reply-To: <51100E9D.6050803@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 12 Feb 2013 03:12:12 +0000 (UTC) Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 03:12:13 -0000 This call is closed, Fred and I will theoretically be able to close the loop on the input by sometime tomorrow. Thank you all for weighing in on this important topic. joel On 2/4/13 11:40 AM, joel jaeggli wrote: > To emphasize Fred's request, please share you opinion on whether this > document should be published intact (as a BCP), with with a lower > state (informational), or not at all, given the IPR disclosure > associated with it. > > The document can be reviewed here: > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 > > the known IPR disclosure is here: > > https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-v6ops-464xlat > > > if you have registered your opinion on this subject already you will > be counted. > > The deadline for commentary is Monday Feb 11th 2012. > From markzzzsmith@yahoo.com.au Mon Feb 11 23: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 93B1521F8C72 for ; Mon, 11 Feb 2013 23:06:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTNgCkW+M5dk for ; Mon, 11 Feb 2013 23:06:02 -0800 (PST) Received: from nm26.bullet.mail.bf1.yahoo.com (nm26.bullet.mail.bf1.yahoo.com [98.139.212.185]) by ietfa.amsl.com (Postfix) with ESMTP id 762FF21F8C6F for ; Mon, 11 Feb 2013 23:06:02 -0800 (PST) Received: from [98.139.212.151] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 07:06:01 -0000 Received: from [98.139.215.253] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 07:06:01 -0000 Received: from [127.0.0.1] by omp1066.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 07:06:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 949072.90497.bm@omp1066.mail.bf1.yahoo.com Received: (qmail 58870 invoked by uid 60001); 12 Feb 2013 07:06:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360652761; bh=sCn+A6liqCcq5XNboneluxM7yqEld61yxriWRpBX23w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n96dKW9IWcOOnIUPyE1C8/hjS7vw8MepNJrlEcuwUlBk64qFP3yeS9usZSsWqr98DQsmHNvl3BP8e2AukNfT0RJeyLKRE+UCUmTpL7Fz4vo8WCCIE7yXNsJkozVoEO6izSgjdxhiA3kKlIVcS9syJZ4fo2r/xosNWzzPRqLCi/Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GOfizazIj9wOwXkMUJada8DSIzRzOFug1JueR8VNlAub/i8tHu2z78jVe17dY2SN7PBtV5qYX6rt/EUy2jviIf9E6T4BoVCgxStrrZLoqIrjimPW4c6iWTTlA2gU6ZHUofi6Zo4HnVeoBvvYwu/Rja0S52hOF0JT65gBuedIv/I=; X-YMail-OSG: lwkul.QVM1kEo3UQCzwOPd5OE20kxz7vyKAnfGGWbJt9TuH k3xtUreX8FAv6kUHxziddPEqRHS_fxB_LUhC5mXesciFzOjsn_T6G1.oLnRf WKG1GB3ZisKgf15SaksnVQtgirHtuBnbh59ziRjCW8D4hw20ddWOm.GJS1O2 OvFX5ZiSvN2wJETNPTt0hJY_Jk7szCyzjq1d5FsTZOhZpErSDlObseEwsMNK NFgYj1C58i4WanzyyohNgoU1eMtXD013NWMWs9AB0Lgf10TWUG.LC7gEZPU1 veK1KYxERKbUnqU_WoF2aXHwKraVE5Y6aPVKBW_GxQ3u1YPx5qzOfrYPdQ9w cRZ2k70HbeJzOqP.l9IN1vDefAtcgEkWc4sCMA2Fx9gkRZHR.30tL_oZ_7x0 X1yJZCMSXBSnNeY_zD3PP1dUWwwhEOlZlPO2xIiVnFcg3aIyq_LFipJum32V oViSocVRlh42sAylIyS4yipPzNMniEVD53_GD3dda_xVREpsB9GKTYhZoMTm 7acaA5TSZ.OG5DB7hezzXKFcv64MGoKnR9Ovn2X23FBGiA7ITKB9RHCd5d3f DcqkxjU0HCmoLdt4- Received: from [121.200.231.211] by web142504.mail.bf1.yahoo.com via HTTP; Mon, 11 Feb 2013 23:06:01 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBEb3VnIEJhcnRvbiA8ZG91Z2JAZG91Z2JhcnRvbi51cz4KPiBUbzogdjZvcHNAaWV0Zi5vcmcKPiBDYzogCj4gU2VudDogVHVlc2RheSwgMTIgRmVicnVhcnkgMjAxMyA5OjQ2IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc21pdGgtdjZvcHMtbGFyZ2VyLWlwdjYtbG9vcGJhY2stcHJlZml4LTAzLnR4dAo.IAo.VCBoZSBkcmFmdCBkb2VzIGNvdmVyIHRoYXQsIHllcy4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> Message-ID: <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Mon, 11 Feb 2013 23:06:01 -0800 (PST) From: Mark Smith To: Doug Barton , "v6ops@ietf.org" In-Reply-To: <511974BE.80001@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 07:06:03 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Doug Barton =0A> To: v6ops@ietf.org=0A> Cc: =0A> Sent: Tuesday, 12 February 20= 13 9:46 AM=0A> Subject: Re: [v6ops] Fw: New Version Notification for draft-= smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A> =0A>T he draft does cove= r that, yes. The question is not, "Is ULA harder?" =0A> the question is, "I= s the extra work required by the draft for EVERY =0A> IMPLEMENTATION worth = it to handle the corner case described in the draft?"=0A>=A0=0A=0A127.0.0.1= /8 has proven to be useful, despite it being a solution to "a corner case".= There was an opportunity to drop it being a ubiquitous feature of IPv6 whe= n IPv6 was being designed, yet the idea was retained, and now all IPv6 impl= ementations have a special purpose ::1/128 address created by default.=0A= =0AI think anything that can make development of IPv6 applications easier a= nd more convenient should be considered. Time application developers spend = on setting up their development environments is time taken away from develo= ping the applications themselves. While developing the application I did, I= found using a ULA prefix to gain more host local addresses cumbersome, and= would have much rather had an autoconfigured, and easy to remember and typ= e loopback IPv6 prefix that had more than one address.=0A=0AThis proposal a= lso takes the opportunity to introduce IPv4-like handling of loopback IPv6 = packets so that future functions similar to the use in RFC4379 have a nativ= e IPv6 address space to use, rather than using 127/8 within an IPv6 prefix.= =0A=0A> Note, I don't know the answer, but I'm leaning heavily towards, =0A= > "no."=0A> =0A> Primarily because we're asking people to deploy this proto= col for =0A> real-world scenarios, and we already have a pretty wide diverg= ence in =0A> the latest state of the standards vs. the oldest working deplo= yed base. =0A> Widening that gap should only be done for truly critical cha= nges, and =0A> I'm not sure you've made your case sufficiently.=0A> =0A> Pu= t more simply, at some point we have to stop tinkering with the plane =0A> = while it's in the air.=0A>=A0=0A=0ASo I think the implication of that analo= gy is that deploying this enhancement will somehow interrupt the existing o= peration of IPv6 implementations ("the plane") causing them to fail ("fall = out of the sky"). I don't see how that will be the case. Deploying a new lo= opback prefix would leverage many of the existing address configuration and= loopback related functions of existing IPv6 implementations. It is not muc= h more than a larger version of ::1/128.=0A=A0=0A=0ARegards,=0AMark.=0A=0A= =0A> Doug=0A> =0A> =0A> On 02/11/2013 01:37 PM, David Farmer wrote:=0A>> O= n 2/11/13 14:28 , Owen DeLong wrote:=0A>>> Perhaps I'm not very bright, bu= t is there any reason ULA =0A> couldn't be=0A>>> used on the LO interface = to=0A>>> satisfy this corner case?=0A>> =0A>> The Draft does cover why UL= A is thought to not be a sufficient solution,=0A>> do you disagree with th= e reasoning in the draft?=0A>> =0A>> from Section 1;=0A>> =0A>> =A0 =A0 A= Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be=0A>> =A0= =A0 used to increase the number of addresses available on the local host.= =0A>> =A0 =A0 However this prefix would need to be manually generated and= =0A>> =A0 =A0 configured at least once by a system administrator or operat= or.=0A>> =A0 =A0 Without additonal configuration, traffic towards addresse= s not=0A>> =A0 =A0 assigned to the local host would not be prevented from = leaving the=0A>> =A0 =A0 host, and access may not be limited to the local = host.=A0 A ULA prefix=0A>> =A0 =A0 would not be well known, and would not = be convenient to remember and=0A>> =A0 =A0 type without violating the rand= omness requirements of the Global ID=0A>> =A0 =A0 component of a ULA prefi= x.=0A>> =0A>>> Owen=0A>>> =0A>>> On Feb 11, 2013, at 12:20 , Mark Smith = =0A> wrote:=0A>>> =0A>>>> Hi,=0A>>>> =0A>>>> = Here is a new version of my IPv6 larger loopback prefix draft.=0A>>>> Chan= ges since the previous version:=0A>>>> =0A>>>> o=A0 default address select= ion precedence and label values=0A>>>> o=A0 comment about other IPv4 in IP= v6 address forms=0A>>>> =0A>>>> o=A0 more clarifications=0A>>>> =0A>>>> o= =A0 grammar corrections=0A>>>> =0A>>>> =0A>>>> My thanks to Bill Atwood, M= atts Kallioniemi and Tina Tsou for their=0A>>>> review and comments on thi= s revision.=0A>>>> =0A>>>> Further review and comments would be most appre= ciated.=0A>>>> =0A>>>> Thanks,=0A>>>> Mark.=0A>> =0A>> =0A>> =0A> =0A> __= _____________________________________________=0A> v6ops mailing list=0A> v6= ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Mon Feb 11 23:14: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 E428121F8C3C for ; Mon, 11 Feb 2013 23:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.468 X-Spam-Level: X-Spam-Status: No, score=0.468 tagged_above=-999 required=5 tests=[AWL=-2.267, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, SARE_URI_REPLICA=1.634] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcSw+L6czRWM for ; Mon, 11 Feb 2013 23:14:50 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id AEF1821F8C2B for ; Mon, 11 Feb 2013 23:14:49 -0800 (PST) Received: from [98.139.215.142] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 07:14:49 -0000 Received: from [98.139.212.198] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 07:14:49 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 07:14:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 53294.236.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 93548 invoked by uid 60001); 12 Feb 2013 07:14:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360653288; bh=w1So1n7ia2HHOnzXMPVbSvD44kfB0tb2S/C4PhpgZ3E=; 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=1u89t+7QgfhxDHK6be4h2+0AAIbSiR41FDplxuGoFYcZ2iDSW8Dr0/S5ijOqsJoF0mus5+TRTlmnvYYG1f9izwdu2r3ydh9TDzEtLFATNJ7N+nUhAKnFOnT5y05urqmhgyuRC/W1d85oPYTQK/EbkRH1bT+GV5FfQPlaVQ0FiV0= 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=XD8AWJmsfaR0vFpAryEPdCvwz5BkgiXB6t2tIOTm+GlzEGA3yXk+uNhO+VUX6ylX22XnsPr7q9dg6mRx0tAilUFiJG3nR2nxnipVV9pXtgcYmzNqw+hzmtK+cj7GfQYXEpf4/vDAwaBMcSQS0mOFRinxRLecu4xK7DohjPdpsZI=; X-YMail-OSG: NYqJDRcVM1k2eYEHhfq2HKaQ5SXtzjp3fI6KGA84T0_l4Qt 4pOZEqf4_QH5Tic3Yldd.5ZARkSOf.VGmsQ77nCP9CLQuxJ2dD60QhjN_ee2 bPT2reZfylkDYQBwnW0KYVzneAw5iQ5eI2VgABluIcTlFOaXkIjBfUwIMNCw qheg0UHAMNv0CmsKVlYiZM9fZmy5ogbTVTML5MiqckUYAThM.b7WnjcLhbHt uv8KP8zsssqyAUMjpjs6zt5luKIT8OfJgGhTz9WboupFAG7jK7yWnvZgV7Bh HB20pNBI.bXIq8AQQWf1GHYnCsqdeRVgiHbAn_6FJWznJcGCDtZ.s0rpSC_O sGg3a1EQjWc5vLt07RKq7Wpe.R_IJxeFE9M7brxuo8iCtKcrUk_X7c_ge_77 IHJ3xZ5U28of0K._iK6Wxc3krcGjzLvreQxbOhrVvRSWEkBQ4cDHaDtXQ2on YmXR2Rd5JAplUpAzaTpjrwiaSkCT2MF0Jn2bthr.tyR8rDAffDXJEx2demkw rq4FIXSaOLWgPbv3FX_2uhhLmHPNWnbYK2t94Yhur6RHBNFdvSwkIJEqagEP K9npcI58zZ5x578fgrd55vvyido8B5OQR_T5NYlPBu1BX0arPkt_OcxF10Pu jgyS2Bw-- Received: from [121.200.231.211] by web142501.mail.bf1.yahoo.com via HTTP; Mon, 11 Feb 2013 23:14:48 PST X-Rocket-MIMEInfo: 001.001, SGkgT2xlLAoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPgo.IFRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPjsgdjZvcHMgdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFR1ZXNkYXksIDEyIEZlYnJ1YXJ5IDIwMTMgODozMiBBTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <1360615683.60384.YahooMailNeo@web142505.mail.bf1.yahoo.com> Message-ID: <1360653288.81227.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 11 Feb 2013 23:14:48 -0800 (PST) From: Mark Smith To: Ole Troan In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 07:14:51 -0000 Hi Ole,=0A=0A=0A----- Original Message -----=0A> From: Ole Troan =0A> To: Mark Smith =0A> Cc: Owen De= Long ; v6ops v6ops WG =0A> Sent: Tuesday, = 12 February 2013 8:32 AM=0A> Subject: Re: [v6ops] New Version Notification = for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A> =0A>> "A Uniq= ue Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be =0A> used to = increase the number of addresses available on the local host. However =0A> = this prefix would need to be manually generated and configured at least onc= e by =0A> a system administrator or operator. Without additonal configurati= on, traffic =0A> towards addresses not assigned to the local host would not= be prevented from =0A> leaving the host, and access may not be limited to = the local host.=A0 A ULA prefix =0A> would not be well known, and would not= be convenient to remember and type =0A> without violating the randomness r= equirements of the Global ID component of a =0A> ULA prefix."=0A>> =0A>> F= or reference, the "candidate" existing unicast addresses that =0A> are eith= er covered in the draft or people have raised with my off-list (and I =0A> = don't think are necessary to cover in the draft) are=0A>> - ULA=0A>> - li= nk local prefix on loopback=0A>> - 100.64/10=0A>> - 100::/64=0A>> In all= cases, they would not be user friendly enough (I used a ULA for this =0A> = purpose during development of http://developer.berlios.de/projects/replicas= t/), =0A> would need operator intervention to enable rather than always bei= ng available, =0A> or would be overloading the existing purpose of the pref= ix and therefore the =0A> prefix's use would have to be respecified.=0A>> = The fundamental problem is that ::1/128 contains only one address, the =0A>= fundamental solution is to preserve the loopback prefix functionality, uti= lity =0A> and ubiquity but make it bigger. =0A> =0A> ::/96 ?=0A>=A0=0A=0AI = figure that it'd be better to make a new larger loopback prefix resemble co= mmon, native IPv6 addressing, so I think it'd be better to have a prefix le= ngth of at least /64 to support 64 bit IIDs. Then, to generally make it mos= t useful, provide many /64s instead of just one. The original proposal was = a /48, however since within 0000::/8, there are 16 million /32s, so a /32 w= ould be cheap for this purpose. Exceeding the number of /64s in a /48 is un= likely but perhaps conceivable (perhaps something related to virtualisation= ?), where as exceeding the /64s in a /32 would seem to me to be both unlike= ly and inconceivable (but hey, there are 256 /16s inside 0000::/8, so 1::/1= 6 as a larger loopback prefix is feasible if somebody can think of a reason= it might be useful!) =A0=0A=0ARegards,=0AMark.=0A From sander@steffann.nl Tue Feb 12 05:52: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 DB65321F8DE5 for ; Tue, 12 Feb 2013 05:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZIc4VEwcWy8 for ; Tue, 12 Feb 2013 05:52:34 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22B21F8D3C for ; Tue, 12 Feb 2013 05:52:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 34CCF202A for ; Tue, 12 Feb 2013 14:52:26 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIEXnbt6ttej for ; Tue, 12 Feb 2013 14:52:21 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id BA6E22025 for ; Tue, 12 Feb 2013 14:52:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann Resent-From: Sander Steffann Date: Mon, 11 Feb 2013 18:23:49 +0100 Content-Transfer-Encoding: quoted-printable Resent-Date: Tue, 12 Feb 2013 14:52:19 +0100 Resent-To: "v6ops@ietf.org list" Message-Id: <6EBC0E51-51B2-4749-AD05-BCF4CAC8213B@steffann.nl> To: Leo Baltus X-Mailer: Apple Mail (2.1499) Resent-Message-Id: <20130212135221.BA6E22025@mail.sintact.nl> Subject: [v6ops] Source address selection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Feb 2013 13:52:35 -0000 Hi, This is a long message. It comes down to "is there a good way to make a = box always use a specific default source address?" The longer version is below to give you some more background information = :-) I am talking to a customer who has the following situation: They have multiple dual stack networks. I'm only looking at the IPv6 = part here. The servers (Linux boxes) all have multiple IPv6 addresses. = Every box has its own address (iron address) and each service has a = separate address (service address) so that it can be moved to a = different box if necessary (unexpected high number of visitors etc). For = some of the addresses load balancers are used to distribute the load. All of the load balancing is done using Direct-Routing (one box responds = to NDP for that address and then forwards the packet to the right = back-end server by leaving the layer-3 addresses in place and using the = layer-2 address of the chosen back-end server, the back-end server has = the address on its loopback interface, accepts the packet and sends the = reply directly to the original layer-3 source address) with VRRP between = load balancers for redundancy. Now the incoming requests are no problem at all. The problem is with the = source address selection when the boxes initiate a connection. We want = outgoing connections to always use the iron address as default source = address. Using one of the service addresses is undesirable for several = reasons: - If the address is load balanced then initiating outbound connections = from that address will break as return traffic might be load balanced to = one of the other boxes - If the application running service A creates an outbound connection = using service B's address, then moving service B to another box will = break application A's established connections - Determining which machine sent which packet is harder - Firewall policies are much harder to write if connections are = initiated from an unpredictable source address With IPv6 this is much harder to accomplish than I ever expected. = Putting the addresses in a configuration file is not an option because = the services can be migrated to another box (=3D another iron address). When looking at the source address selection mechanism in RFC 6724 I see = a few possibilities to adjust the algorithm: Rule 1: Prefer same address - N/A here: Localhost traffic isn't important here Rule 2: Prefer appropriate scope - All addresses involved have global scope Rule 3: Avoid deprecated addresses - Making all service addresses deprecated prevents them from being used = as a source address by default, so this accomplishes what we want, but = it feels like a hack... Rule 4: Prefer home addresses. - N/A here: Mobile IPv6 not in use Rule 5: Prefer outgoing interface. - Lots of addresses on the same interface (does work for addresses on = the loopback interface) Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. - N/A: Possible source addresses are in the same prefix Rule 6: Prefer matching label. - Giving all service addresses a different label from the iron addresses = seemed a good choice. We considered renumbering all services to use = addresses in a specific part of the /64 and then configure Linux to use = a separate label for that prefix (i.e. `ip addrlabel add prefix = 2001:db8:123:abc:1000::/68 label 1000`). This works for connections to = the outside world, but if one service connects to another service then = it still would choose a service address as source address. Giving every = service address its own label would solve that, but with the potentially = hundreds of addresses on each box (yes, this is a big server farm) this = becomes unmanageable. Rule 7: Prefer temporary addresses. - N/A: temporary addresses are disabled on the boxes Rule 8: Use longest matching prefix. - When connecting to external services all addresses on the LAN have the = same match-length (all shorter than a /64). When connecting to other = services on the same LAN it becomes unpredictable again (depends on the = other service addresses on the same box) Based on this it seems that making all service addresses deprecated = immediately and leaving the iron address as the only preferred address = would be the only way to solve this. It does feel like a hack though. = RFC 4862 says that "an address becomes "deprecated" in anticipation that = its current interface binding will become invalid". These addresses are = not anticipated to become invalid for a very long time (=3D indefinite). = I can already imagine a kernel deciding to free up some resources by = dropping addresses that are marked as deprecated for example. So: does anybody have any advice on this? Is it safe/future-proof/etc to = mark addresses as deprecated to avoid them being used as default source = addresses? Do we need some other way to steer the default source address = selection procedure? Or is the only 'official' way to give each and = every /128 its own label (so that rule 6 becomes equal to rule 1 for = service addresses)? Cheers, Sander From owen@delong.com Tue Feb 12 10:49: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 C634121F9085 for ; Tue, 12 Feb 2013 10:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCrF+Rkjq9T0 for ; Tue, 12 Feb 2013 10:49:51 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2120221F907D for ; Tue, 12 Feb 2013 10:49:50 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1CIkxRp004004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Feb 2013 10:46:59 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1CIkxRp004004 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360694820; bh=jwYvC3FJkSrlDCKdWdcGegDetf0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qrx5bQf/by6QzLgHJqDScTwmHJC8WDlVu6+eFe6FJjvfwjpcFrlDXKliv2Fp4FtKP BMTbBwRUVCwZ2xq2eghZwBTK3aJ127YlUJx/1xh+9CQiY+EbmtoGicsZlraQTRs6td iPwYYyBErkR2635Hbv4iJG0lOJvBa0PLw7sAVLn8= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Tue, 12 Feb 2013 10:46:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 12 Feb 2013 10:47:00 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:49:55 -0000 On Feb 11, 2013, at 11:06 PM, Mark Smith = wrote: >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Doug Barton >> To: v6ops@ietf.org >> Cc:=20 >> Sent: Tuesday, 12 February 2013 9:46 AM >> Subject: Re: [v6ops] Fw: New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>=20 >> T he draft does cover that, yes. The question is not, "Is ULA = harder?"=20 >> the question is, "Is the extra work required by the draft for EVERY=20= >> IMPLEMENTATION worth it to handle the corner case described in the = draft?" >> =20 >=20 > 127.0.0.1/8 has proven to be useful, despite it being a solution to "a = corner case". There was an opportunity to drop it being a ubiquitous = feature of IPv6 when IPv6 was being designed, yet the idea was retained, = and now all IPv6 implementations have a special purpose ::1/128 address = created by default. >=20 > I think anything that can make development of IPv6 applications easier = and more convenient should be considered. Time application developers = spend on setting up their development environments is time taken away = from developing the applications themselves. While developing the = application I did, I found using a ULA prefix to gain more host local = addresses cumbersome, and would have much rather had an auto configured, = and easy to remember and type loopback IPv6 prefix that had more than = one address. ?? I don't see how it gets easier to remember than fd00::/8 and you can = use anything you want inside of that to provide a /64 for your = development purpose. What's more cumbersome about picking something (even fd00::/64, if you = want) for development than having some other prefix you have to = configure assigned by the IETF. Sorry, but I just don't get it. >=20 > This proposal also takes the opportunity to introduce IPv4-like = handling of loopback IPv6 packets so that future functions similar to = the use in RFC4379 have a native IPv6 address space to use, rather than = using 127/8 within an IPv6 prefix. In my (admittedly limited) testing, putting a /64 of ULA on the loopback = interface did just that, so I'm not sure what it is that you feel is = missing. >=20 >> Note, I don't know the answer, but I'm leaning heavily towards,=20 >> "no." >>=20 >> Primarily because we're asking people to deploy this protocol for=20 >> real-world scenarios, and we already have a pretty wide divergence in=20= >> the latest state of the standards vs. the oldest working deployed = base.=20 >> Widening that gap should only be done for truly critical changes, and=20= >> I'm not sure you've made your case sufficiently. >>=20 >> Put more simply, at some point we have to stop tinkering with the = plane=20 >> while it's in the air. >> =20 >=20 > So I think the implication of that analogy is that deploying this = enhancement will somehow interrupt the existing operation of IPv6 = implementations ("the plane") causing them to fail ("fall out of the = sky"). I don't see how that will be the case. Deploying a new loopback = prefix would leverage many of the existing address configuration and = loopback related functions of existing IPv6 implementations. It is not = much more than a larger version of ::1/128. The implication is that you are requesting to once again obsolete all = existing implementations in favor of requiring deploying another = fundamentally changed IPv6 stack. The question is whether there is = enough value in the change to justify such a decision and IMHO, at this = point, just to make it "less cumbersome" than putting (a) ULA = address(es) on the loopback interface strikes me as not having much = value. Owen > =20 >=20 > Regards, > Mark. >=20 >=20 >> Doug >>=20 >>=20 >> On 02/11/2013 01:37 PM, David Farmer wrote: >>> On 2/11/13 14:28 , Owen DeLong wrote: >>>> Perhaps I'm not very bright, but is there any reason ULA=20 >> couldn't be >>>> used on the LO interface to >>>> satisfy this corner case? >>>=20 >>> The Draft does cover why ULA is thought to not be a sufficient = solution, >>> do you disagree with the reasoning in the draft? >>>=20 >>> from Section 1; >>>=20 >>> A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] = could be >>> used to increase the number of addresses available on the local = host. >>> However this prefix would need to be manually generated and >>> configured at least once by a system administrator or operator. >>> Without additonal configuration, traffic towards addresses not >>> assigned to the local host would not be prevented from leaving = the >>> host, and access may not be limited to the local host. A ULA = prefix >>> would not be well known, and would not be convenient to = remember and >>> type without violating the randomness requirements of the = Global ID >>> component of a ULA prefix. >>>=20 >>>> Owen >>>>=20 >>>> On Feb 11, 2013, at 12:20 , Mark Smith=20 >> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> Here is a new version of my IPv6 larger loopback prefix draft. >>>>> Changes since the previous version: >>>>>=20 >>>>> o default address selection precedence and label values >>>>> o comment about other IPv4 in IPv6 address forms >>>>>=20 >>>>> o more clarifications >>>>>=20 >>>>> o grammar corrections >>>>>=20 >>>>>=20 >>>>> My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou for = their >>>>> review and comments on this revision. >>>>>=20 >>>>> Further review and comments would be most appreciated. >>>>>=20 >>>>> Thanks, >>>>> Mark. >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Tue Feb 12 11:43: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 58EFA21F8D32 for ; Tue, 12 Feb 2013 11:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-1.201, BAYES_50=0.001, 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 BRMDuR-HQwqQ for ; Tue, 12 Feb 2013 11:43:46 -0800 (PST) Received: from nm21-vm0.bullet.mail.bf1.yahoo.com (nm21-vm0.bullet.mail.bf1.yahoo.com [98.139.213.137]) by ietfa.amsl.com (Postfix) with ESMTP id EB75621F8D2B for ; Tue, 12 Feb 2013 11:43:42 -0800 (PST) Received: from [98.139.212.151] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 19:43:36 -0000 Received: from [98.139.212.199] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 19:43:36 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 19:43:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 570153.53985.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 13853 invoked by uid 60001); 12 Feb 2013 19:43:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360698216; bh=xVYaMsXGSejkZUVfHqoi9N0Z32Z7cUiMNKCrpJ7vE9Y=; 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=Yn3vlYPu/XeX5iSFNsp+1ZZDBAb/AW9YlFmim36ZZ3D2UxcEjQR0g9rGuTwTdG9nh2pmwGe6zZjTzjWzkWXR1QqZMB7GHobx8LOy8zfferYLCCLWYT3AklWthNtZxOkbOo+euvUoqPq9NtF627X5xtsnPZjsfSc2qdKdhTjFGck= 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=taILvD0RabU1kFH73Q4oMbxP0+Ohjaw8PiIabmC4odrXk3OE8VOY8W5iKUS20dl1waW1kolcUbVRF0wjmXHnbZjdVAta07WONSJEnySTlYbc2TsJ9ZCK+r8kJPXD/o72VR9TUZY8u1aNDEg1hQIYrr2fTR9m7G6U77M6QBoKjtc=; X-YMail-OSG: 0DIZHA8VM1kUVxlJlK.1mzsVOCHPOxKhfFIor.juEdHvr2D 4cJa8MnTBpDMg_KhxqR7C Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 12 Feb 2013 11:43:35 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBEb3VnIEJhcnRvbiA8ZG91Z2JAZG91Z2JhcnRvbi51cz47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFdlZG5lc2RheSwgMTMgRmVicnVhcnkgMjAxMyA1OjQ2IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 12 Feb 2013 11:43:35 -0800 (PST) From: Mark 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] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 19:43:47 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: Mark Smith =0A> Cc: Doug Barton ; "v6ops@ietf.org" =0A> Sent: Wednesday,= 13 February 2013 5:46 AM=0A> Subject: Re: [v6ops] New Version Notification= for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A> =0A> =0A> On = Feb 11, 2013, at 11:06 PM, Mark Smith =0A> wrot= e:=0A> =0A>> =0A>> =0A>> =0A>> =0A>> ----- Original Message -----=0A>>> F= rom: Doug Barton =0A>>> To: v6ops@ietf.org=0A>>> Cc:= =0A>>> Sent: Tuesday, 12 February 2013 9:46 AM=0A>>> Subject: Re: [v6ops= ] Fw: New Version Notification for =0A> draft-smith-v6ops-larger-ipv6-loopb= ack-prefix-03.txt=0A>>> =0A>>> T he draft does cover that, yes. The questi= on is not, "Is ULA =0A> harder?" =0A>>> the question is, "Is the extra wor= k required by the draft for =0A> EVERY =0A>>> IMPLEMENTATION worth it to h= andle the corner case described in the =0A> draft?"=0A>>> =A0 =0A>> =0A>> = 127.0.0.1/8 has proven to be useful, despite it being a solution to "a =0A>= corner case". There was an opportunity to drop it being a ubiquitous =0A> = feature of IPv6 when IPv6 was being designed, yet the idea was retained, an= d now =0A> all IPv6 implementations have a special purpose ::1/128 address = created by =0A> default.=0A>> =0A>> I think anything that can make develop= ment of IPv6 applications easier and =0A> more convenient should be conside= red. Time application developers spend on =0A> setting up their development= environments is time taken away from developing the =0A> applications them= selves. While developing the application I did, I found using a =0A> ULA pr= efix to gain more host local addresses cumbersome, and would have much =0A>= rather had an auto configured, and easy to remember and type loopback IPv6= =0A> prefix that had more than one address.=0A> =0A> ?? I don't see how it= gets easier to remember than fd00::/8=0A=0AThe random bit is the hard bit = to remember and type. I don't think you're thinking enough about how it is = to use, you're only thinking about how hard it is to configure. The time an= d effort to configure something is usually minimal compared to the amount o= f time and effort spent while it is being used.=0A=0A> and you can use=A0= =0A=0A> anything you want inside of that to provide a /64 for your developm= ent purpose.=0A> =0A> What's more cumbersome about picking something (even = fd00::/64, if you want)=A0=0A=0ANo, that's bad, as it is a ULA prefix which= doesn't have a random component. Add the random component (if you aren't l= azy), and it then becomes hard to remember and type.=0A=0A> for development= than having some other prefix you have to configure assigned by=A0=0A=0A> = the IETF.=0A=0AI'm starting to wonder if you've actually read the draft. Th= e intention is that it is that the larger loopback prefix automatically con= figured at system initialisation, as ::1/128 and 127/8 currently are. There= is a whole section on automatic address assignment and configuration.=0A= =0A> =0A> Sorry, but I just don't get it.=0A> =0A>> =0A> =0A>> This propos= al also takes the opportunity to introduce IPv4-like handling of =0A> loopb= ack IPv6 packets so that future functions similar to the use in RFC4379 =0A= > have a native IPv6 address space to use, rather than using 127/8 within a= n IPv6 =0A> prefix.=0A> =0A> In my (admittedly limited) testing, putting a = /64 of ULA on the loopback =0A> interface did just that, so I'm not sure wh= at it is that you feel is =0A> missing.=0A>=A0=0A=0AAll addresses within 12= 7/8 are valid and available on the host, where as with your ULA, only 1 is.= =0A=0Ae.g.=0A=0A=0A[root@opy mark]# ip addr show dev lo=0A1: lo: mtu 65536 qdisc noqueue state UNKNOWN=A0=0A=A0 =A0 link/loopba= ck 00:00:00:00:00:00 brd 00:00:00:00:00:00=0A=A0 =A0 inet 127.0.0.1/8 scope= host lo=0A=A0 =A0 inet6 fd00:db8::1/64 scope global=A0=0A=A0 =A0 =A0 =A0va= lid_lft forever preferred_lft forever=0A=A0 =A0 inet6 1::1/64 scope global= =A0=0A=A0 =A0 =A0 =A0valid_lft forever preferred_lft forever=0A=A0 =A0 inet= 6 ::1/128 scope host=A0=0A=A0 =A0 =A0 =A0valid_lft forever preferred_lft fo= rever=0A=0A[root@opy mark]# ping -c 1 127.1.2.3=0APING 127.1.2.3 (127.1.2.3= ) 56(84) bytes of data.=0A64 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 ti= me=3D0.053 ms=0A=0A--- 127.1.2.3 ping statistics ---=0A1 packets transmitte= d, 1 received, 0% packet loss, time 0ms=0Artt min/avg/max/mdev =3D 0.053/0.= 053/0.053/0.000 ms=0A[root@opy mark]#=A0=0A=0A[root@opy mark]# ping6 -c 1 f= d00:db8::2=0A=0Aconnect: Network is unreachable=0A[root@opy mark]#=0A=0A[ma= rk@opy ~]$ ssh 127.1.2.3=0AThe authenticity of host '127.1.2.3 (127.1.2.3)'= can't be established.=0A=0A[mark@opy ~]$ ssh -6 fd00:db8::2=0Assh: connect= to host fd00:db8::2 port 22: Network is unreachable=0A[mark@opy ~]$=0A=0AA= nother test you should do to measure the usefulness of this proposal is see= how long it takes and your opinion afterwards of how hard or easy it is to= type or cut and paste "fd00:db8::1" vs "1::1" a reasonable number of times= e.g. 6 times.=0A=0A=0AUsing a ULA doesn't really work at all. It only adds= another address to the host, rather than many. A properly formed ULA is ha= rd to type and remember. It's far less user friendly than the short larger = loopback prefix I'm proposing. This is based on my experience, as I've used= a ULA for the purpose of trying to increase the number of loopback IPv6 ad= dresses.=0A=0A>>=A0=0A=0A>>> Note, I don't know the answer, but I'm leanin= g heavily towards, =0A> =0A>>> "no."=0A>>> =0A>>> Primarily because we're= asking people to deploy this protocol for =0A>>> real-world scenarios, an= d we already have a pretty wide divergence in =0A>>> the latest state of t= he standards vs. the oldest working deployed base. =0A> =0A>>> Widening th= at gap should only be done for truly critical changes, and =0A>>> I'm not = sure you've made your case sufficiently.=0A>>> =0A>>> Put more simply, at = some point we have to stop tinkering with the plane =0A> =0A>>> while it's= in the air.=0A>>> =A0 =0A>> =0A>> So I think the implication of that anal= ogy is that deploying this =0A> enhancement will somehow interrupt the exis= ting operation of IPv6 =0A> implementations ("the plane") causing them to f= ail ("fall out of =0A> the sky"). I don't see how that will be the case. De= ploying a new =0A> loopback prefix would leverage many of the existing addr= ess configuration and =0A> loopback related functions of existing IPv6 impl= ementations. It is not much more =0A> than a larger version of ::1/128.=0A>= =0A> The implication is that you are requesting to once again obsolete all= existing =0A> implementations in favor of requiring deploying another fund= amentally changed =0A> IPv6 stack.=0A=0ACan you define the threshold of "fu= ndamentally changed" for me?=0A=0AI don't consider this to be a fundamental= change. It is adding another loopback prefix, which operates the same as t= he existing one, just with a shorter prefix length. It is adding values to = the source and destination address selection policy, which is already possi= ble to do because it's been designed that way. I'm quite confident that it = is going to be no more than 10 lines, and probably closer to 5 additional l= ines of code in a stack for a host implementation that only supports a sing= le loopback interface. That's code change size closer to the size of bug fi= xes than additional functionality.=0A=0AMy definition of a fundamental chan= ge would be to do something like change the change the size of the IPv6 add= ress, or reorder the fields in the IPv6 header.=0A=0A> The question is whet= her there is enough value in the change to =0A> justify such a decision and= IMHO, at this point, just to make it "less =0A> cumbersome" than putting (= a) ULA address(es) on the loopback interface =0A> strikes me as not having = much value.=0A> =0A> Owen=0A> =0A>> =A0 =0A>> =0A>> Regards,=0A>> Mark.= =0A>> =0A>> =0A>>> Doug=0A>>> =0A>>> =0A>>> On 02/11/2013 01:37 PM, David= Farmer wrote:=0A>>>> On 2/11/13 14:28 , Owen DeLong wrote:=0A>>>>> Perha= ps I'm not very bright, but is there any reason ULA =0A>>> couldn't be=0A>= >>>> used on the LO interface to=0A>>>>> satisfy this corner case?=0A>>>>= =0A>>>> The Draft does cover why ULA is thought to not be a sufficient = =0A> solution,=0A>>>> do you disagree with the reasoning in the draft?=0A>= >>> =0A>>>> from Section 1;=0A>>>> =0A>>>> =A0 =A0 =A0 A Unique Local IPv6= Unicast Address (ULA) prefix [RFC4193] =0A> could be=0A>>>> =A0 =A0 =A0 us= ed to increase the number of addresses available on the =0A> local host.=0A= >>>> =A0 =A0 =A0 However this prefix would need to be manually generated an= d=0A>>>> =A0 =A0 =A0 configured at least once by a system administrator or = =0A> operator.=0A>>>> =A0 =A0 =A0 Without additonal configuration, traffic = towards addresses not=0A>>>> =A0 =A0 =A0 assigned to the local host would n= ot be prevented from leaving =0A> the=0A>>>> =A0 =A0 =A0 host, and access m= ay not be limited to the local host.=A0 A ULA =0A> prefix=0A>>>> =A0 =A0 = =A0 would not be well known, and would not be convenient to =0A> remember a= nd=0A>>>> =A0 =A0 =A0 type without violating the randomness requirements of= the =0A> Global ID=0A>>>> =A0 =A0 =A0 component of a ULA prefix.=0A>>>> = =0A>>>>> Owen=0A>>>>> =0A>>>>> On Feb 11, 2013, at 12:20 , Mark Smith =0A= >>> wrote:=0A>>>>> =0A>>>>>> Hi,=0A>>>>>> =0A= >>>>>> Here is a new version of my IPv6 larger loopback prefix =0A> draft.= =0A>>>>>> Changes since the previous version:=0A>>>>>> =0A>>>>>> o=A0 def= ault address selection precedence and label values=0A>>>>>> o=A0 comment a= bout other IPv4 in IPv6 address forms=0A>>>>>> =0A>>>>>> o=A0 more clarifi= cations=0A>>>>>> =0A>>>>>> o=A0 grammar corrections=0A>>>>>> =0A>>>>>> =0A= >>>>>> My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou =0A> for = their=0A>>>>>> review and comments on this revision.=0A>>>>>> =0A>>>>>> F= urther review and comments would be most appreciated.=0A>>>>>> =0A>>>>>> T= hanks,=0A>>>>>> Mark.=0A>>>> =0A>>>> =0A>>>> =0A>>> =0A>>> ______________= _________________________________=0A>>> v6ops mailing list=0A>>> v6ops@ie= tf.org=0A>>> https://www.ietf.org/mailman/listinfo/v6ops=0A>>> =0A>> ____= ___________________________________________=0A>> v6ops mailing list=0A>> = v6ops@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/v6ops=0A> From owen@delong.com Tue Feb 12 12: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 8A47E21F8E32 for ; Tue, 12 Feb 2013 12:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-1.807, BAYES_40=-0.185, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=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 cPRCwFPkJJ3C for ; Tue, 12 Feb 2013 12:00:13 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 62D6F21F8D94 for ; Tue, 12 Feb 2013 12:00:10 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1CJxBfG005745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Feb 2013 11:59:11 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1CJxBfG005745 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360699152; bh=6BA7Vq4IgyuHYPAc8ZAdbwgQuoI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iS1BWXeCFnE+RGc+6LDlkYBLBZMFKFRU5HhV5ClM+v2d8xcTALCG1DFogNK10+fbm hFjOxhcibDbD5JCeUfvnFc3OrEnt0EfKfpNgzdKC9NE45MNoh3CRNCEuZAdD6YqeyX ys5sRE6zyJmxxD3uBX2DHeAKi51ZjiYyyqdGUt9E= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 12 Feb 2013 11:59:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 12 Feb 2013 11:59:12 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:00:14 -0000 >>=20 >> ?? I don't see how it gets easier to remember than fd00::/8 >=20 > The random bit is the hard bit to remember and type. I don't think = you're thinking enough about how it is to use, you're only thinking = about how hard it is to configure. The time and effort to configure = something is usually minimal compared to the amount of time and effort = spent while it is being used. >=20 Nothing requires you to use random for this purpose. Use fd00::/64 for = all anyone cares. >> and you can use=20 >=20 >> anything you want inside of that to provide a /64 for your = development purpose. >>=20 >> What's more cumbersome about picking something (even fd00::/64, if = you want)=20 >=20 > No, that's bad, as it is a ULA prefix which doesn't have a random = component. Add the random component (if you aren't lazy), and it then = becomes hard to remember and type. >=20 Why is it bad that it doesn't have a random component? If it's in a = development test lab, it's not like it's at risk of corporate merger = conflicts, etc. >> for development than having some other prefix you have to configure = assigned by=20 >=20 >> the IETF. >=20 > I'm starting to wonder if you've actually read the draft. The = intention is that it is that the larger loopback prefix automatically = configured at system initialisation, as ::1/128 and 127/8 currently are. = There is a whole section on automatic address assignment and = configuration. 127/8 isn't auto-assigned. 127.0.0.1/8 is. >=20 >>=20 >> Sorry, but I just don't get it. >>=20 >>>=20 >>=20 >>> This proposal also takes the opportunity to introduce IPv4-like = handling of=20 >> loopback IPv6 packets so that future functions similar to the use in = RFC4379=20 >> have a native IPv6 address space to use, rather than using 127/8 = within an IPv6=20 >> prefix. >>=20 >> In my (admittedly limited) testing, putting a /64 of ULA on the = loopback=20 >> interface did just that, so I'm not sure what it is that you feel is=20= >> missing. >> =20 >=20 > All addresses within 127/8 are valid and available on the host, where = as with your ULA, only 1 is. >=20 > e.g. >=20 >=20 > [root@opy mark]# ip addr show dev lo > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN=20 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 fd00:db8::1/64 scope global=20 > valid_lft forever preferred_lft forever > inet6 1::1/64 scope global=20 > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host=20 > valid_lft forever preferred_lft forever >=20 > [root@opy mark]# ping -c 1 127.1.2.3 > PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. > 64 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 ms >=20 > --- 127.1.2.3 ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev =3D 0.053/0.053/0.053/0.000 ms > [root@opy mark]#=20 >=20 Interesting=85 I get this behavior on MacOS. [tc01-dhcp153:~] owen% ifconfig lo0 lo0: flags=3D8049 mtu 16384 options=3D3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 inet 127.0.0.1 netmask 0xff000000=20 inet6 ::1 prefixlen 128=20 [tc01-dhcp153:~] owen% ping 127.1.2.3 PING 127.1.2.3 (127.1.2.3): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 ^C --- 127.1.2.3 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss Admittedly, Linux does this: owen.delong.com:owen /home4/owen (22) % ifconfig lo lo Link encap:Local Loopback =20 inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:45816328 errors:0 dropped:0 overruns:0 frame:0 TX packets:45816328 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0=20 RX bytes:578712867 (551.9 MiB) TX bytes:578712867 (551.9 MiB) owen.delong.com:owen /home4/owen (23) % ping 127.1.2.3 PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. 64 bytes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 time=3D0.043 ms 64 bytes from 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0.032 ms 64 bytes from 127.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 ms ^C --- 127.1.2.3 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 ms owen.delong.com:owen /home4/owen (24) %=20 > [root@opy mark]# ping6 -c 1 fd00:db8::2 >=20 > connect: Network is unreachable > [root@opy mark]# >=20 > [mark@opy ~]$ ssh 127.1.2.3 > The authenticity of host '127.1.2.3 (127.1.2.3)' can't be established. >=20 > [mark@opy ~]$ ssh -6 fd00:db8::2 > ssh: connect to host fd00:db8::2 port 22: Network is unreachable > [mark@opy ~]$ >=20 =46rom what I can see, this seems to depend on a pathology not = universally available even in IPv4. > Another test you should do to measure the usefulness of this proposal = is see how long it takes and your opinion afterwards of how hard or easy = it is to type or cut and paste "fd00:db8::1" vs "1::1" a reasonable = number of times e.g. 6 times. >=20 I'm fine with it. If you're doing it more than 6 times, that's what DNS = is for. >=20 > Using a ULA doesn't really work at all. It only adds another address = to the host, rather than many. A properly formed ULA is hard to type and = remember. It's far less user friendly than the short larger loopback = prefix I'm proposing. This is based on my experience, as I've used a ULA = for the purpose of trying to increase the number of loopback IPv6 = addresses. >=20 The same is true with loopback except on Linux as near as I can tell. >>> =20 >=20 >>>> Note, I don't know the answer, but I'm leaning heavily towards,=20 >>=20 >>>> "no." >>>>=20 >>>> Primarily because we're asking people to deploy this protocol for=20= >>>> real-world scenarios, and we already have a pretty wide divergence = in=20 >>>> the latest state of the standards vs. the oldest working deployed = base.=20 >>=20 >>>> Widening that gap should only be done for truly critical changes, = and=20 >>>> I'm not sure you've made your case sufficiently. >>>>=20 >>>> Put more simply, at some point we have to stop tinkering with the = plane=20 >>=20 >>>> while it's in the air. >>>> =20 >>>=20 >>> So I think the implication of that analogy is that deploying this=20 >> enhancement will somehow interrupt the existing operation of IPv6=20 >> implementations ("the plane") causing them to fail ("fall out of=20 >> the sky"). I don't see how that will be the case. Deploying a new=20 >> loopback prefix would leverage many of the existing address = configuration and=20 >> loopback related functions of existing IPv6 implementations. It is = not much more=20 >> than a larger version of ::1/128. >>=20 >> The implication is that you are requesting to once again obsolete all = existing=20 >> implementations in favor of requiring deploying another fundamentally = changed=20 >> IPv6 stack. >=20 > Can you define the threshold of "fundamentally changed" for me? >=20 Requiring a modification to every existing IPv6 stack in the wild which = could be incorporated into software dependencies which would render existing = stacks unexpectedly obsolete. > I don't consider this to be a fundamental change. It is adding another = loopback prefix, which operates the same as the existing one, just with = a shorter prefix length. It is adding values to the source and = destination address selection policy, which is already possible to do = because it's been designed that way. I'm quite confident that it is = going to be no more than 10 lines, and probably closer to 5 additional = lines of code in a stack for a host implementation that only supports a = single loopback interface. That's code change size closer to the size of = bug fixes than additional functionality. >=20 So you want to force everyone to update their IPv6 stack on every host, = router, switch, etc. just so you can save some typing? You're doing a very good job cementing my opposition here. > My definition of a fundamental change would be to do something like = change the change the size of the IPv6 address, or reorder the fields in = the IPv6 header. >=20 That would be a drastic change, indeed. This is less drastic, but it = would make current IPv6 stacks incompatible with the protocol = definition. >> The question is whether there is enough value in the change to=20 >> justify such a decision and IMHO, at this point, just to make it = "less=20 >> cumbersome" than putting (a) ULA address(es) on the loopback = interface=20 >> strikes me as not having much value. >>=20 >> Owen >>=20 >>> =20 >>>=20 >>> Regards, >>> Mark. >>>=20 >>>=20 >>>> Doug >>>>=20 >>>>=20 >>>> On 02/11/2013 01:37 PM, David Farmer wrote: >>>>> On 2/11/13 14:28 , Owen DeLong wrote: >>>>>> Perhaps I'm not very bright, but is there any reason ULA=20 >>>> couldn't be >>>>>> used on the LO interface to >>>>>> satisfy this corner case? >>>>>=20 >>>>> The Draft does cover why ULA is thought to not be a sufficient=20 >> solution, >>>>> do you disagree with the reasoning in the draft? >>>>>=20 >>>>> from Section 1; >>>>>=20 >>>>> A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193]=20= >> could be >>>>> used to increase the number of addresses available on the=20 >> local host. >>>>> However this prefix would need to be manually generated and >>>>> configured at least once by a system administrator or=20 >> operator. >>>>> Without additonal configuration, traffic towards addresses = not >>>>> assigned to the local host would not be prevented from = leaving=20 >> the >>>>> host, and access may not be limited to the local host. A = ULA=20 >> prefix >>>>> would not be well known, and would not be convenient to=20 >> remember and >>>>> type without violating the randomness requirements of the=20 >> Global ID >>>>> component of a ULA prefix. >>>>>=20 >>>>>> Owen >>>>>>=20 >>>>>> On Feb 11, 2013, at 12:20 , Mark Smith=20 >>>> wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> Here is a new version of my IPv6 larger loopback prefix=20 >> draft. >>>>>>> Changes since the previous version: >>>>>>>=20 >>>>>>> o default address selection precedence and label values >>>>>>> o comment about other IPv4 in IPv6 address forms >>>>>>>=20 >>>>>>> o more clarifications >>>>>>>=20 >>>>>>> o grammar corrections >>>>>>>=20 >>>>>>>=20 >>>>>>> My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou=20 >> for their >>>>>>> review and comments on this revision. >>>>>>>=20 >>>>>>> Further review and comments would be most appreciated. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Mark. >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From markzzzsmith@yahoo.com.au Tue Feb 12 12: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 A3B1F21F8AC1 for ; Tue, 12 Feb 2013 12:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.571 X-Spam-Level: X-Spam-Status: No, score=0.571 tagged_above=-999 required=5 tests=[AWL=-1.730, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=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 phlnJDM-zP26 for ; Tue, 12 Feb 2013 12:34:02 -0800 (PST) Received: from nm37-vm5.bullet.mail.bf1.yahoo.com (nm37-vm5.bullet.mail.bf1.yahoo.com [72.30.238.205]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1B21F8AC2 for ; Tue, 12 Feb 2013 12:34:01 -0800 (PST) Received: from [98.139.212.149] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 20:34:00 -0000 Received: from [98.139.212.222] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 20:34:00 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 20:34:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 160450.50371.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 61991 invoked by uid 60001); 12 Feb 2013 20:34:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360701239; bh=Tsivqc6rZ00pG+/HxtE4QB7pJhJFqz3t37DW60kZsYQ=; 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=GT8/+mPkI8MaDKXFICBmH58l0oZHfcOdBPwEcwOi+/NLc58kZkLNfUp2qvDJz1UEy4NdaL8YmUGGeSpogiLt+O9PbIOqgZAbpUOakPlcGYtzK/fs7hd2S/Ns4dT6CsoYxdRvxQRedXRuLmb1b7ZE8bimeR3U/Cc23kWVWPO/TtM= 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=pJR/WTcWcEqv9n5kUIyik4h1ltGThWMCWq8FwTkENIQgYj0/tr0SC/fFzqvXNDk5cJXS7bfbOQozAFgDoKKZ1MWjRjUEWEoeKYB3barmThmPDoTBW/5LD3Qtwasbp44T6Jv+CrPVjMiy+sjLPpoF8XgTsxhd7QzF92pr2sVHymE=; X-YMail-OSG: fiML4mkVM1nFtd6GLMc44yp7cJeGnLCXq3Uvru9EppadlFR OnJoD.lnYiWyRLR_2oJx06UvDccx8oG_qL0tonPQMzALQuxA6Gt1IeXiYj.U 2dmkl2z7mOkJSriqZDw.UqsGSZbSI5uXKMqhdrzNfvXb1MjkcPW7gGYMzgRv PrNHlmu_XgHTC1qX7GoyBwKVa9rKIyFo50XZtiFmHONWsDnA4I3FtraQeGfk KemXx3svWcKhoZJQEIrN7EsUro8wB75Ng8FNm4jwM88y2Q_rflZcKOIId9JY UzlcC_tGNO8Lpqvwosb0ABEImjH1gpSya9sd_8jkfxxmI9ghLF2dfoSZ._aW tCIkj8sEf5ZOlBNVkoTDFWkVr4PCUTkiP4TROrebIZjKoMGHr7OrFlpWzCzW 6jjGt12.YpdcvOfIoSY4vActsh0z4YkgPp_QwlXQVqVSNUXzrJLSeUNcnEBn nkEh7Dr6eTUvZmHjQvu_Ae4QBZtXQ2gHzo8xYb79vbgYxumH_s43NupbZHDO Rb0IJ2OWzxr_HMj_w8rE7156Iv8Aco5BjmfnU2L7SQTOljnQfhxAhUj9KKf6 .3BOsRhasazS6e9T.tYUjOCWOoF67bnlPJyyuGSG1qQotCOoeGf55EFfe.ak ZZ.e.LcQ8GPudr8o2O0vxOv3Ya3PphKx1nEwPdMzyYHxXGB5.7wNusa5ltor XWLvSZiu8 Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Tue, 12 Feb 2013 12:33:59 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBEb3VnIEJhcnRvbiA8ZG91Z2JAZG91Z2JhcnRvbi51cz47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFdlZG5lc2RheSwgMTMgRmVicnVhcnkgMjAxMyA2OjU5IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> Message-ID: <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Tue, 12 Feb 2013 12:33:59 -0800 (PST) From: Mark Smith To: Owen DeLong In-Reply-To: <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:34:03 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: Mark Smith =0A> Cc: Doug Barton ; "v6ops@ietf.org" =0A> Sent: Wednesday,= 13 February 2013 6:59 AM=0A> Subject: Re: [v6ops] New Version Notification= for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A> =0A>>> =0A>>>= ?? I don't see how it gets easier to remember than fd00::/8=0A>> =0A>> T= he random bit is the hard bit to remember and type. I don't think =0A> you'= re thinking enough about how it is to use, you're only thinking =0A> about = how hard it is to configure. The time and effort to configure something is = =0A> usually minimal compared to the amount of time and effort spent while = it is =0A> being used.=0A>> =0A> =0A> Nothing requires you to use random fo= r this purpose. Use fd00::/64 for all =0A> anyone cares.=0A>=C2=A0=0A=0ARFC= 4193 does. It's not a ULA if it doesn't, it's been made a site-local. See R= FC3879 for the problems with them and your non-random ULA.=0A=0A=0A>>> and= you can use =0A>> =0A>>> anything you want inside of that to provide a /6= 4 for your development =0A> purpose.=0A>>> =0A>>> What's more cumbersome a= bout picking something (even fd00::/64, if =0A> you want) =0A>> =0A>> No, = that's bad, as it is a ULA prefix which doesn't have a random =0A> componen= t. Add the random component (if you aren't lazy), and it then =0A> becomes = hard to remember and type.=0A>> =0A> =0A> Why is it bad that it doesn't hav= e a random component? If it's in a =0A> development test lab, it's not like= it's at risk of corporate merger =0A> conflicts, etc.=0A>=C2=A0=0A=0ASee s= lide 26.=0A=0Ahttp://www.users.on.net/~markachy/resi_ipv6_cpe.pdf=0A=0A=0A>= >> for development than having some other prefix you have to configure =0A= > assigned by =0A>> =0A>>> the IETF.=0A>> =0A>> I'm starting to wonder if= you've actually read the draft. The =0A> intention is that it is that the = larger loopback prefix automatically configured =0A> at system initialisati= on, as ::1/128 and 127/8 currently are. There is a whole =0A> section on au= tomatic address assignment and configuration.=0A> =0A> 127/8 isn't auto-ass= igned. 127.0.0.1/8 is.=0A>=C2=A0=0A=0AThat's incorrect.=0A=0A=C2=A0RFC1122,= "Requirements for Internet Hosts -- Communication Layers", specifically th= e in=0A=0A"(g) { 127, }=0AInternal host loopback address. Addr= esses of this form MUST NOT appear outside a host."=0A=0A>>=C2=A0=0A=0A>>> = =0A>>> Sorry, but I just don't get it.=0A>>> =0A>>>> =0A>>> =0A>>>> This = proposal also takes the opportunity to introduce IPv4-like =0A> handling of= =0A>>> loopback IPv6 packets so that future functions similar to the use = in =0A> RFC4379 =0A>>> have a native IPv6 address space to use, rather tha= n using 127/8 within =0A> an IPv6 =0A>>> prefix.=0A>>> =0A>>> In my (admi= ttedly limited) testing, putting a /64 of ULA on the =0A> loopback =0A>>> = interface did just that, so I'm not sure what it is that you feel =0A> is = =0A>>> missing.=0A>>> =C2=A0 =0A>> =0A>> All addresses within 127/8 are v= alid and available on the host, where as =0A> with your ULA, only 1 is.=0A>= > =0A>> e.g.=0A>> =0A>> =0A>> [root@opy mark]# ip addr show dev lo=0A>> = 1: lo: mtu 65536 qdisc noqueue state UNKNOWN =0A>> = =C2=A0 =C2=A0 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00=0A>> = =C2=A0 =C2=A0 inet 127.0.0.1/8 scope host lo=0A>> =C2=A0 =C2=A0 inet6 fd0= 0:db8::1/64 scope global =0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid_lft foreve= r preferred_lft forever=0A>> =C2=A0 =C2=A0 inet6 1::1/64 scope global =0A>= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid_lft forever preferred_lft forever=0A>> = =C2=A0 =C2=A0 inet6 ::1/128 scope host =0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 v= alid_lft forever preferred_lft forever=0A>> =0A>> [root@opy mark]# ping -c= 1 127.1.2.3=0A>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.=0A>> 6= 4 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 ms=0A>> =0A>> -= -- 127.1.2.3 ping statistics ---=0A>> 1 packets transmitted, 1 received, 0= % packet loss, time 0ms=0A>> rtt min/avg/max/mdev =3D 0.053/0.053/0.053/0.= 000 ms=0A>> [root@opy mark]# =0A>> =0A> =0A> Interesting=E2=80=A6 I get th= is behavior on MacOS.=0A> =0A> [tc01-dhcp153:~] owen% ifconfig lo0=0A> lo0:= flags=3D8049 mtu 16384=0A> =C2=A0=C2=A0=C2= =A0 options=3D3=0A> =C2=A0=C2=A0=C2=A0 inet6 fe80::1%lo0 pre= fixlen 64 scopeid 0x1 =0A> =C2=A0=C2=A0=C2=A0 inet 127.0.0.1 netmask 0xff00= 0000 =0A> =C2=A0=C2=A0=C2=A0 inet6 ::1 prefixlen 128 =0A> =0A> [tc01-dhcp15= 3:~] owen% ping 127.1.2.3=0A> PING 127.1.2.3 (127.1.2.3): 56 data bytes=0A>= Request timeout for icmp_seq 0=0A> Request timeout for icmp_seq 1=0A> Requ= est timeout for icmp_seq 2=0A> Request timeout for icmp_seq 3=0A> ^C=0A> --= - 127.1.2.3 ping statistics ---=0A> 5 packets transmitted, 0 packets receiv= ed, 100.0% packet loss=0A>=C2=A0=0A=0ASo MacOS isn't compliant with RFC1122= .=0A=0A=0A> Admittedly, Linux does this:=0A> =0A> owen.delong.com:owen /hom= e4/owen (22) % ifconfig lo=0A> lo=C2=A0 =C2=A0 =C2=A0 =C2=A0 Link encap:Loc= al Loopback=C2=A0 =0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet addr:127.0.0= .1=C2=A0 Mask:255.0.0.0=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 addr: = ::1/128 Scope:Host=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP LOOPBACK RUNNI= NG=C2=A0 MTU:16436=C2=A0 Metric:1=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX= packets:45816328 errors:0 dropped:0 overruns:0 frame:0=0A> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 TX packets:45816328 errors:0 dropped:0 overruns:0 carr= ier:0=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 txqueuelen:0 =0A>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:578712867 (551.9 MiB)=C2=A0 TX= bytes:578712867 (551.9 MiB)=0A> =0A> owen.delong.com:owen /home4/owen (23)= % ping 127.1.2.3=0A> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.=0A> = 64 bytes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 time=3D0.043 ms=0A> 64 bytes= from 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0.032 ms=0A> 64 bytes from 12= 7.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 ms=0A> ^C=0A> --- 127.1.2.3 pin= g statistics ---=0A> 3 packets transmitted, 3 received, 0% packet loss, tim= e 2000ms=0A> rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 ms=0A> owen.d= elong.com:owen /home4/owen (24) % =0A> =0A> =0A> =0A>> [root@opy mark]# pi= ng6 -c 1 fd00:db8::2=0A>> =0A>> connect: Network is unreachable=0A>> [roo= t@opy mark]#=0A>> =0A>> [mark@opy ~]$ ssh 127.1.2.3=0A>> The authenticity= of host '127.1.2.3 (127.1.2.3)' can't be =0A> established.=0A>> =0A>> [ma= rk@opy ~]$ ssh -6 fd00:db8::2=0A>> ssh: connect to host fd00:db8::2 port 2= 2: Network is unreachable=0A>> [mark@opy ~]$=0A>> =0A> =0A> From what I ca= n see, this seems to depend on a pathology not universally =0A> available e= ven in IPv4.=0A> =0A>> Another test you should do to measure the usefulnes= s of this proposal is =0A> see how long it takes and your opinion afterward= s of how hard or easy it is to =0A> type or cut and paste "fd00:db8::1" vs = "1::1" a reasonable =0A> number of times e.g. 6 times.=0A>> =0A> =0A> I'm f= ine with it. If you're doing it more than 6 times, that's what =0A> DNS is = for.=0A>=C2=A0=0A=0AThat's an option, for applications that use DNS to reso= lve addresses. There are applications that need to deal with addresses dire= ctly, such as mine, due to their nature and purpose.=0A=0A>> =0A>> Using a= ULA doesn't really work at all. It only adds another address to =0A> the h= ost, rather than many. A properly formed ULA is hard to type and remember. = =0A> It's far less user friendly than the short larger loopback prefix I'm = =0A> proposing. This is based on my experience, as I've used a ULA for the = =0A> purpose of trying to increase the number of loopback IPv6 addresses.= =0A>> =0A> =0A> The same is true with loopback except on Linux as near as I= can tell.=0A>=C2=A0=0A=0AWindows 7 also behaves this way, as it complies w= ith RFC1122.=0A=0A>>>> =C2=A0 =0A>> =0A>>>>> Note, I don't know the answer= , but I'm leaning heavily =0A> towards, =0A>>> =0A>>>>> "no."=0A>>>>> =0A>= >>>> Primarily because we're asking people to deploy this =0A> protocol fo= r =0A>>>>> real-world scenarios, and we already have a pretty wide =0A> di= vergence in =0A>>>>> the latest state of the standards vs. the oldest work= ing =0A> deployed base. =0A>>> =0A>>>>> Widening that gap should only be d= one for truly critical =0A> changes, and =0A>>>>> I'm not sure you've made= your case sufficiently.=0A>>>>> =0A>>>>> Put more simply, at some point w= e have to stop tinkering with =0A> the plane =0A>>> =0A>>>>> while it's in= the air.=0A>>>>> =C2=A0 =0A>>>> =0A>>>> So I think the implication of tha= t analogy is that deploying this =0A>>> enhancement will somehow interrupt= the existing operation of IPv6 =0A>>> implementations ("the plane") causi= ng them to fail =0A> ("fall out of =0A>>> the sky"). I don't see how that = will be the case. Deploying a =0A> new =0A>>> loopback prefix would levera= ge many of the existing address =0A> configuration and =0A>>> loopback rel= ated functions of existing IPv6 implementations. It is not =0A> much more = =0A>>> than a larger version of ::1/128.=0A>>> =0A>>> The implication is = that you are requesting to once again obsolete all =0A> existing =0A>>> im= plementations in favor of requiring deploying another fundamentally =0A> ch= anged =0A>>> IPv6 stack.=0A>> =0A>> Can you define the threshold of "fund= amentally changed" for me?=0A>> =0A> =0A> Requiring a modification to every= existing IPv6 stack in the wild which could be=0A> incorporated into softw= are dependencies which would render existing stacks =0A> unexpectedly=0A> o= bsolete.=0A> =0A>> I don't consider this to be a fundamental change. It is= adding another =0A> loopback prefix, which operates the same as the existi= ng one, just with a =0A> shorter prefix length. It is adding values to the = source and destination address =0A> selection policy, which is already poss= ible to do because it's been designed =0A> that way. I'm quite confident th= at it is going to be no more than 10 lines, =0A> and probably closer to 5 a= dditional lines of code in a stack for a host =0A> implementation that only= supports a single loopback interface. That's code =0A> change size closer = to the size of bug fixes than additional functionality.=0A>> =0A> =0A> So y= ou want to force everyone to update their IPv6 stack on every host, router,= =0A> switch, etc. just so you can save some typing?=0A>=C2=A0=0A=0AThe IET= F (and I) can't force anything. If it's useful, it'll be implemented.=0A=0A= > You're doing a very good job cementing my opposition here.=0A>=C2=A0=0A= =0AYou seem to like doing things the hard way. My view is computers should = do things automatically for people so that people can get on with more valu= able things. Developers should be cutting code instead of setting up develo= pment environments, or waiting for system administrators to set up the deve= lopment environment for them.=0A=0A>> My definition of a fundamental chang= e would be to do something like change =0A> the change the size of the IPv6= address, or reorder the fields in the IPv6 =0A> header.=0A>> =0A> =0A> Tha= t would be a drastic change, indeed. This is less drastic, but it would mak= e =0A> current IPv6 stacks incompatible with the protocol definition.=0A>= =C2=A0=0A=0AI don't get this. 1::/32 is not currently used for anything, so= using it is not going to make it incompatible with anything. Using other p= refixes for purposes that they weren't designed for, such as a ULA as a loo= pback, has far greater risk of creating incompatibility.=C2=A0=0A=0A>>> Th= e question is whether there is enough value in the change to =0A>>> justif= y such a decision and IMHO, at this point, just to make it =0A> "less =0A>>= > cumbersome" than putting (a) ULA address(es) on the loopback =0A> interf= ace =0A>>> strikes me as not having much value.=0A>>>=C2=A0=0A=0AYou don't= seem to be placing any value convenience. Does your car have an automatic = transmission? Do you have a dishwasher? Do you go to restaurants? All of th= ose things only exist because humans place value on the convenience of not = manually changing gears, not manually washing dishes, and not cooking at ho= me when we could. Why have to do something manually when a computer could d= o it automatically for you?=0A=C2=A0 =0A>>> Owen=0A>>> =0A>>>> =C2=A0 =0A>= >>> =0A>>>> Regards,=0A>>>> Mark.=0A>>>> =0A>>>> =0A>>>>> Doug=0A>>>>> = =0A>>>>> =0A>>>>> On 02/11/2013 01:37 PM, David Farmer wrote:=0A>>>>>> On= 2/11/13 14:28 , Owen DeLong wrote:=0A>>>>>>> Perhaps I'm not very bright,= but is there any =0A> reason ULA =0A>>>>> couldn't be=0A>>>>>>> used on = the LO interface to=0A>>>>>>> satisfy this corner case?=0A>>>>>> =0A>>>>>>= The Draft does cover why ULA is thought to not be a =0A> sufficient =0A>>= > solution,=0A>>>>>> do you disagree with the reasoning in the draft?=0A>= >>>>> =0A>>>>>> from Section 1;=0A>>>>>> =0A>>>>>> =C2=A0 =C2=A0 =C2=A0 A= Unique Local IPv6 Unicast Address (ULA) prefix =0A> [RFC4193] =0A>>> coul= d be=0A>>>>>> =C2=A0 =C2=A0 =C2=A0 used to increase the number of addresse= s available on =0A> the =0A>>> local host.=0A>>>>>> =C2=A0 =C2=A0 =C2=A0 = However this prefix would need to be manually =0A> generated and=0A>>>>>> = =C2=A0 =C2=A0 =C2=A0 configured at least once by a system administrator or= =0A> =0A>>> operator.=0A>>>>>> =C2=A0 =C2=A0 =C2=A0 Without additonal co= nfiguration, traffic towards =0A> addresses not=0A>>>>>> =C2=A0 =C2=A0 =C2= =A0 assigned to the local host would not be prevented =0A> from leaving = =0A>>> the=0A>>>>>> =C2=A0 =C2=A0 =C2=A0 host, and access may not be limi= ted to the local =0A> host.=C2=A0 A ULA =0A>>> prefix=0A>>>>>> =C2=A0 =C2= =A0 =C2=A0 would not be well known, and would not be convenient =0A> to = =0A>>> remember and=0A>>>>>> =C2=A0 =C2=A0 =C2=A0 type without violating = the randomness requirements of =0A> the =0A>>> Global ID=0A>>>>>> =C2=A0 = =C2=A0 =C2=A0 component of a ULA prefix.=0A>>>>>> =0A>>>>>>> Owen=0A>>>>>= >> =0A>>>>>>> On Feb 11, 2013, at 12:20 , Mark Smith =0A>>>>> wrote:=0A>>>>>>> =0A>>>>>>>> Hi,=0A>>>>>>>> =0A>>>>>>>> = Here is a new version of my IPv6 larger loopback =0A> prefix =0A>>> draft.= =0A>>>>>>>> Changes since the previous version:=0A>>>>>>>> =0A>>>>>>>> o= =C2=A0 default address selection precedence and label =0A> values=0A>>>>>>>= > o=C2=A0 comment about other IPv4 in IPv6 address forms=0A>>>>>>>> =0A>>>= >>>>> o=C2=A0 more clarifications=0A>>>>>>>> =0A>>>>>>>> o=C2=A0 grammar = corrections=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> My thanks to Bill Atwood, M= atts Kallioniemi and =0A> Tina Tsou =0A>>> for their=0A>>>>>>>> review an= d comments on this revision.=0A>>>>>>>> =0A>>>>>>>> Further review and com= ments would be most =0A> appreciated.=0A>>>>>>>> =0A>>>>>>>> Thanks,=0A>>>= >>>>> Mark.=0A>>>>>> =0A>>>>>> =0A>>>>>> =0A>>>>> =0A>>>>> ______________= _________________________________=0A>>>>> v6ops mailing list=0A>>>>> v6op= s@ietf.org=0A>>>>> https://www.ietf.org/mailman/listinfo/v6ops=0A>>>>> =0A= >>>> _______________________________________________=0A>>>> v6ops mailing= list=0A>>>> v6ops@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/= v6ops=0A>>> =0A> From owen@delong.com Tue Feb 12 16:19: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 3B45921F8718 for ; Tue, 12 Feb 2013 16:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=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 zmsWyN7y1WLb for ; Tue, 12 Feb 2013 16:19:50 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBFA21F8715 for ; Tue, 12 Feb 2013 16:19:49 -0800 (PST) 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 r1D0IJcM011678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Feb 2013 16:18:20 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1D0IJcM011678 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360714700; bh=PB8mLrV1Hq0wfgDN2B9fDdSSjpQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UxYKAoDT6sXNwW/6Sy2tc8I7aK+LolWmxwUEXyYjqNHg/7thhNok7vmdluzM3QH6e 7otDFCz2gflqdkZ8qd44/72z12vFA3Euhkv69ad/VlBIjP4xw/29Lw7QtF7zs7bLJs WtHWyDc7Li4k06hkI0lKyw3SQw5B9ChGMn0jmvRU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Tue, 12 Feb 2013 16:18:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 12 Feb 2013 16:18:20 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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, 13 Feb 2013 00:19:52 -0000 On Feb 12, 2013, at 12:33 PM, Mark Smith = wrote: >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Owen DeLong >> To: Mark Smith >> Cc: Doug Barton ; "v6ops@ietf.org" = >> Sent: Wednesday, 13 February 2013 6:59 AM >> Subject: Re: [v6ops] New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>=20 >>>>=20 >>>> ?? I don't see how it gets easier to remember than fd00::/8 >>>=20 >>> The random bit is the hard bit to remember and type. I don't think=20= >> you're thinking enough about how it is to use, you're only thinking=20= >> about how hard it is to configure. The time and effort to configure = something is=20 >> usually minimal compared to the amount of time and effort spent while = it is=20 >> being used. >>>=20 >>=20 >> Nothing requires you to use random for this purpose. Use fd00::/64 = for all=20 >> anyone cares. >> =20 >=20 > RFC4193 does. It's not a ULA if it doesn't, it's been made a = site-local. See RFC3879 for the problems with them and your non-random = ULA. >=20 Which is irrelevant to the loopback scenario you have described=85 >=20 >>>> and you can use=20 >>>=20 >>>> anything you want inside of that to provide a /64 for your = development=20 >> purpose. >>>>=20 >>>> What's more cumbersome about picking something (even fd00::/64, if=20= >> you want)=20 >>>=20 >>> No, that's bad, as it is a ULA prefix which doesn't have a random=20 >> component. Add the random component (if you aren't lazy), and it then=20= >> becomes hard to remember and type. >>>=20 >>=20 >> Why is it bad that it doesn't have a random component? If it's in a=20= >> development test lab, it's not like it's at risk of corporate merger=20= >> conflicts, etc. >> =20 >=20 > See slide 26. >=20 > http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf >=20 Which does not apply to use on a loopback interface. >=20 >>>> for development than having some other prefix you have to configure=20= >> assigned by=20 >>>=20 >>>> the IETF. >>>=20 >>> I'm starting to wonder if you've actually read the draft. The=20 >> intention is that it is that the larger loopback prefix automatically = configured=20 >> at system initialisation, as ::1/128 and 127/8 currently are. There = is a whole=20 >> section on automatic address assignment and configuration. >>=20 >> 127/8 isn't auto-assigned. 127.0.0.1/8 is. >> =20 >=20 > That's incorrect. >=20 > RFC1122, "Requirements for Internet Hosts -- Communication Layers", = specifically the in >=20 > "(g) { 127, } > Internal host loopback address. Addresses of this form MUST NOT = appear outside a host." >=20 Yes, it requires that you not have addresses within 127.0.0.0/8 appear = outside of the host. It does not require the host to answer or auto configure all of the 127.0.0.0/8 = addresses on its loopback interface and, indeed, most hosts do NOT auto configure other than = 127.0.0.1. >>> =20 >=20 >>>>=20 >>>> Sorry, but I just don't get it. >>>>=20 >>>>>=20 >>>>=20 >>>>> This proposal also takes the opportunity to introduce IPv4-like=20 >> handling of=20 >>>> loopback IPv6 packets so that future functions similar to the use = in=20 >> RFC4379=20 >>>> have a native IPv6 address space to use, rather than using 127/8 = within=20 >> an IPv6=20 >>>> prefix. >>>>=20 >>>> In my (admittedly limited) testing, putting a /64 of ULA on the=20 >> loopback=20 >>>> interface did just that, so I'm not sure what it is that you feel=20= >> is=20 >>>> missing. >>>> =20 >>>=20 >>> All addresses within 127/8 are valid and available on the host, = where as=20 >> with your ULA, only 1 is. >>>=20 >>> e.g. >>>=20 >>>=20 >>> [root@opy mark]# ip addr show dev lo >>> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN=20= >>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >>> inet 127.0.0.1/8 scope host lo >>> inet6 fd00:db8::1/64 scope global=20 >>> valid_lft forever preferred_lft forever >>> inet6 1::1/64 scope global=20 >>> valid_lft forever preferred_lft forever >>> inet6 ::1/128 scope host=20 >>> valid_lft forever preferred_lft forever >>>=20 >>> [root@opy mark]# ping -c 1 127.1.2.3 >>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>> 64 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 ms >>>=20 >>> --- 127.1.2.3 ping statistics --- >>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms >>> rtt min/avg/max/mdev =3D 0.053/0.053/0.053/0.000 ms >>> [root@opy mark]#=20 >>>=20 >>=20 >> Interesting=85 I get this behavior on MacOS. >>=20 >> [tc01-dhcp153:~] owen% ifconfig lo0 >> lo0: flags=3D8049 mtu 16384 >> options=3D3 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 >> inet 127.0.0.1 netmask 0xff000000=20 >> inet6 ::1 prefixlen 128=20 >>=20 >> [tc01-dhcp153:~] owen% ping 127.1.2.3 >> PING 127.1.2.3 (127.1.2.3): 56 data bytes >> Request timeout for icmp_seq 0 >> Request timeout for icmp_seq 1 >> Request timeout for icmp_seq 2 >> Request timeout for icmp_seq 3 >> ^C >> --- 127.1.2.3 ping statistics --- >> 5 packets transmitted, 0 packets received, 100.0% packet loss >> =20 >=20 > So MacOS isn't compliant with RFC1122. >=20 How do you figure that? You'll need to be more specific. >=20 >> Admittedly, Linux does this: >>=20 >> owen.delong.com:owen /home4/owen (22) % ifconfig lo >> lo Link encap:Local Loopback =20 >> inet addr:127.0.0.1 Mask:255.0.0.0 >> inet6 addr: ::1/128 Scope:Host >> UP LOOPBACK RUNNING MTU:16436 Metric:1 >> RX packets:45816328 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:45816328 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0=20 >> RX bytes:578712867 (551.9 MiB) TX bytes:578712867 (551.9 = MiB) >>=20 >> owen.delong.com:owen /home4/owen (23) % ping 127.1.2.3 >> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >> 64 bytes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 time=3D0.043 ms >> 64 bytes from 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0.032 ms >> 64 bytes from 127.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 ms >> ^C >> --- 127.1.2.3 ping statistics --- >> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms >> rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 ms >> owen.delong.com:owen /home4/owen (24) %=20 >>=20 >>=20 >>=20 >>> [root@opy mark]# ping6 -c 1 fd00:db8::2 >>>=20 >>> connect: Network is unreachable >>> [root@opy mark]# >>>=20 >>> [mark@opy ~]$ ssh 127.1.2.3 >>> The authenticity of host '127.1.2.3 (127.1.2.3)' can't be=20 >> established. >>>=20 >>> [mark@opy ~]$ ssh -6 fd00:db8::2 >>> ssh: connect to host fd00:db8::2 port 22: Network is unreachable >>> [mark@opy ~]$ >>>=20 >>=20 >> =46rom what I can see, this seems to depend on a pathology not = universally=20 >> available even in IPv4. >>=20 >>> Another test you should do to measure the usefulness of this = proposal is=20 >> see how long it takes and your opinion afterwards of how hard or easy = it is to=20 >> type or cut and paste "fd00:db8::1" vs "1::1" a reasonable=20 >> number of times e.g. 6 times. >>>=20 >>=20 >> I'm fine with it. If you're doing it more than 6 times, that's what=20= >> DNS is for. >> =20 >=20 > That's an option, for applications that use DNS to resolve addresses. = There are applications that need to deal with addresses directly, such = as mine, due to their nature and purpose. Then use a configuration file or whatever. There are lots of = alternatives to repeatedly typing in addresses. (command-line aliases come to mind as an example). >=20 >>>=20 >>> Using a ULA doesn't really work at all. It only adds another address = to=20 >> the host, rather than many. A properly formed ULA is hard to type and = remember.=20 >> It's far less user friendly than the short larger loopback prefix I'm=20= >> proposing. This is based on my experience, as I've used a ULA for the=20= >> purpose of trying to increase the number of loopback IPv6 addresses. >>>=20 >>=20 >> The same is true with loopback except on Linux as near as I can tell. >> =20 >=20 > Windows 7 also behaves this way, as it complies with RFC1122. >=20 Nothing I found in RFC 1122 requires this, so if you think something = does, you'll need to point it out. I know for a fact that several Cisco switches did not. For example, they = used to use 127.0.0. as a convenient hack for connections across the = backplane to the IP stack running on IP-aware blades such as RSMs. >>>>> =20 >>>=20 >>>>>> Note, I don't know the answer, but I'm leaning heavily=20 >> towards,=20 >>>>=20 >>>>>> "no." >>>>>>=20 >>>>>> Primarily because we're asking people to deploy this=20 >> protocol for=20 >>>>>> real-world scenarios, and we already have a pretty wide=20 >> divergence in=20 >>>>>> the latest state of the standards vs. the oldest working=20 >> deployed base.=20 >>>>=20 >>>>>> Widening that gap should only be done for truly critical=20 >> changes, and=20 >>>>>> I'm not sure you've made your case sufficiently. >>>>>>=20 >>>>>> Put more simply, at some point we have to stop tinkering with=20 >> the plane=20 >>>>=20 >>>>>> while it's in the air. >>>>>> =20 >>>>>=20 >>>>> So I think the implication of that analogy is that deploying this=20= >>>> enhancement will somehow interrupt the existing operation of IPv6=20= >>>> implementations ("the plane") causing them to fail=20 >> ("fall out of=20 >>>> the sky"). I don't see how that will be the case. Deploying a=20 >> new=20 >>>> loopback prefix would leverage many of the existing address=20 >> configuration and=20 >>>> loopback related functions of existing IPv6 implementations. It is = not=20 >> much more=20 >>>> than a larger version of ::1/128. >>>>=20 >>>> The implication is that you are requesting to once again obsolete = all=20 >> existing=20 >>>> implementations in favor of requiring deploying another = fundamentally=20 >> changed=20 >>>> IPv6 stack. >>>=20 >>> Can you define the threshold of "fundamentally changed" for me? >>>=20 >>=20 >> Requiring a modification to every existing IPv6 stack in the wild = which could be >> incorporated into software dependencies which would render existing = stacks=20 >> unexpectedly >> obsolete. >>=20 >>> I don't consider this to be a fundamental change. It is adding = another=20 >> loopback prefix, which operates the same as the existing one, just = with a=20 >> shorter prefix length. It is adding values to the source and = destination address=20 >> selection policy, which is already possible to do because it's been = designed=20 >> that way. I'm quite confident that it is going to be no more than 10 = lines,=20 >> and probably closer to 5 additional lines of code in a stack for a = host=20 >> implementation that only supports a single loopback interface. That's = code=20 >> change size closer to the size of bug fixes than additional = functionality. >>>=20 >>=20 >> So you want to force everyone to update their IPv6 stack on every = host, router,=20 >> switch, etc. just so you can save some typing? >> =20 >=20 > The IETF (and I) can't force anything. If it's useful, it'll be = implemented. >=20 IMHO, it's not all that useful and making it a stack requirement would = lead to one of two bad situations: 1. Development resources would be taken away from tasks that = matter. or 2. Increasing divergence between the implemented stacks and the = documented standards. >> You're doing a very good job cementing my opposition here. >> =20 >=20 > You seem to like doing things the hard way. My view is computers = should do things automatically for people so that people can get on with = more valuable things. Developers should be cutting code instead of = setting up development environments, or waiting for system = administrators to set up the development environment for them. >=20 Actually, I do not. However, I do not believe in using the entire IP = stack development community as a workforce to save me a little bit of = typing which, as near as I can tell is all that this proposal would = accomplish. The functionality you seek is available using ULA. The issues you cite = with ULA would not apply to loopback usage. The functionality that you = attribute to RFC 1122 isn't (as near as I can tell) actually codified = into RFC 1122 (I don't see how requiring that an address range not = appear outside of a host requires that host to accept all packets to any = address in said range, which is what you are claiming). >>> My definition of a fundamental change would be to do something like = change=20 >> the change the size of the IPv6 address, or reorder the fields in the = IPv6=20 >> header. >>>=20 >>=20 >> That would be a drastic change, indeed. This is less drastic, but it = would make=20 >> current IPv6 stacks incompatible with the protocol definition. >> =20 >=20 > I don't get this. 1::/32 is not currently used for anything, so using = it is not going to make it incompatible with anything. Using other = prefixes for purposes that they weren't designed for, such as a ULA as a = loopback, has far greater risk of creating incompatibility.=20 If you add this as a required stack feature, stacks which don't = implement the feature are no longer compliant. >=20 >>>> The question is whether there is enough value in the change to=20 >>>> justify such a decision and IMHO, at this point, just to make it=20 >> "less=20 >>>> cumbersome" than putting (a) ULA address(es) on the loopback=20 >> interface=20 >>>> strikes me as not having much value. >>>> =20 >=20 > You don't seem to be placing any value convenience. Does your car have = an automatic transmission? Do you have a dishwasher? Do you go to = restaurants? All of those things only exist because humans place value = on the convenience of not manually changing gears, not manually washing = dishes, and not cooking at home when we could. Why have to do something = manually when a computer could do it automatically for you? > =20 I place tremendous value on convenience. My car does not have a = traditional automatic transmission, my car has an ECVT transmission. If = I were buying a car, I would actually prefer a manual transmission = because I prefer the greater control flexibility and shifting precision = afforded by a manual transmission. Yes, I go to restaurants. There are many equally automatic solutions to your problem already = available without involving the entire body of protocol developers and = the IETF in the process. Owen >>>> Owen >>>>=20 >>>>> =20 >>>>>=20 >>>>> Regards, >>>>> Mark. >>>>>=20 >>>>>=20 >>>>>> Doug >>>>>>=20 >>>>>>=20 >>>>>> On 02/11/2013 01:37 PM, David Farmer wrote: >>>>>>> On 2/11/13 14:28 , Owen DeLong wrote: >>>>>>>> Perhaps I'm not very bright, but is there any=20 >> reason ULA=20 >>>>>> couldn't be >>>>>>>> used on the LO interface to >>>>>>>> satisfy this corner case? >>>>>>>=20 >>>>>>> The Draft does cover why ULA is thought to not be a=20 >> sufficient=20 >>>> solution, >>>>>>> do you disagree with the reasoning in the draft? >>>>>>>=20 >>>>>>> from Section 1; >>>>>>>=20 >>>>>>> A Unique Local IPv6 Unicast Address (ULA) prefix=20 >> [RFC4193]=20 >>>> could be >>>>>>> used to increase the number of addresses available on=20 >> the=20 >>>> local host. >>>>>>> However this prefix would need to be manually=20 >> generated and >>>>>>> configured at least once by a system administrator or=20 >>=20 >>>> operator. >>>>>>> Without additonal configuration, traffic towards=20 >> addresses not >>>>>>> assigned to the local host would not be prevented=20 >> from leaving=20 >>>> the >>>>>>> host, and access may not be limited to the local=20 >> host. A ULA=20 >>>> prefix >>>>>>> would not be well known, and would not be convenient=20 >> to=20 >>>> remember and >>>>>>> type without violating the randomness requirements of=20 >> the=20 >>>> Global ID >>>>>>> component of a ULA prefix. >>>>>>>=20 >>>>>>>> Owen >>>>>>>>=20 >>>>>>>> On Feb 11, 2013, at 12:20 , Mark Smith=20 >>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> Here is a new version of my IPv6 larger loopback=20 >> prefix=20 >>>> draft. >>>>>>>>> Changes since the previous version: >>>>>>>>>=20 >>>>>>>>> o default address selection precedence and label=20 >> values >>>>>>>>> o comment about other IPv4 in IPv6 address forms >>>>>>>>>=20 >>>>>>>>> o more clarifications >>>>>>>>>=20 >>>>>>>>> o grammar corrections >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> My thanks to Bill Atwood, Matts Kallioniemi and=20 >> Tina Tsou=20 >>>> for their >>>>>>>>> review and comments on this revision. >>>>>>>>>=20 >>>>>>>>> Further review and comments would be most=20 >> appreciated. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Mark. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>=20 >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>=20 From markzzzsmith@yahoo.com.au Tue Feb 12 16:51: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 71C7D21F8971 for ; Tue, 12 Feb 2013 16:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.756 X-Spam-Level: ** X-Spam-Status: No, score=2.756 tagged_above=-999 required=5 tests=[AWL=-3.044, BAYES_99=3.5, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=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 uIflsXIq5u5H for ; Tue, 12 Feb 2013 16:51:51 -0800 (PST) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with SMTP id D9EF521F8949 for ; Tue, 12 Feb 2013 16:51:50 -0800 (PST) Received: from [98.139.212.151] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 13 Feb 2013 00:51:50 -0000 Received: from [98.139.212.195] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 13 Feb 2013 00:51:50 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 13 Feb 2013 00:51:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 342810.83127.bm@omp1004.mail.bf1.yahoo.com Received: (qmail 63034 invoked by uid 60001); 13 Feb 2013 00:51:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360716710; bh=KjqmrPhMxCNDro4R5kOUxtWeqv1KLEaNoF0WvtRDFyI=; 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=NFNSB5nxIM6TUXdEOWD5SuzQb9XYGbPdPcYFLjdS1wOL/n8lss0sNqHD1njfaSIUIlHxBc5AK5TI3so3bQEq5eXPhcSHdrKYkM6UIIbfnowDIXxse5OtKtZf+299nY2QHljbKeEfktO8Opeam2mcQFFv8ShEc2HEc13k7X408Vg= 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=nd047I49PviCmixDqvYZ/ZIOVDMBv4/rmNtj5uHSU6HuApOsoM1vhM2WBvM2CrIPYEE2YiIXqqOt1i55aue7vMFc/5MJIKU1Syb2aCfrQjJi6cp3GPydLJk6jTnBakyv3Div/+iZeBgcM0HK0YuEHBG+wTNwjGqAhZH++rpqCxs=; X-YMail-OSG: iKqrM3kVM1nFX3neUFcl6jcuEdfnJySr_6ga0LSdWaPIasJ pTu_ZlREnS7PoMPvqxMesYXxv6tkACrlSnWt4AIOF180qbLHmTO52muJVmR_ skAMSYLH4sRhxDXGd.o_0xhmris7fIPcJnD7NgkHPG9Oq5n7TjU4nLP3UP3A yr0cLT4npZoo31iKUjEODA3Z_axxKKapUa_IcNYiczFcnsSsMC6OXzhcMFEU TnPc2jKzzQMbqyxLC4onufQU0JzsIOEbgllR_BBJy0SHoO1Hoq6YxSOr8O0r yVG9Ll2OGjGSCg85NKFuKCnhYi0dPxjlyyowyzxV0MGgyOcD5uvoQi9nMZSw nTHfb.onbQFuE59cNWyIzDZPr3BRb5Tis96MtQugI8uVGyNNzMbnVTfpLhWk 165xpLo1TQaaW9PMvV93aC1fHWE2s4v4An6Dx_2lfPH1iwJTM_aQvxWKwk9F _ulUYcbxT10qLA_UNjr5h9V8YpiY2Fv_npCEMpOqpQ9nsieP2yG6AYzLQ7Ar qLdn1.Fps.1TFIt3yfoJDGzhuO_Hx5FflRq9U.X072XsqdUqqaMz2oN.FKxK 31VDwcnQNuCOsiSMqqsocXehnHj7k7PQStqzZ7VVZVT_ANVfClXEu74nZMvg 42i5jTGyccYSM2bSYOmin5SLRzPouO5EP2xii_EzpzpJO9fxOTXmqJF5LDy. GVhSAUcmRe44DPpt9IEbj.t.BMmC7x.kwRgyaqVETxunUxPcVBum.5PjY23m MZb_BMPm5TA-- Received: from [121.200.231.211] by web142504.mail.bf1.yahoo.com via HTTP; Tue, 12 Feb 2013 16:51:49 PST X-Rocket-MIMEInfo: 001.001, T3dlbiwgSSd2ZSBwcmV0dHkgbXVjaCBjb21lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgeW91IGhhdmVuJ3QgcmVhZCBteSBkcmFmdCwgYXMgdGhlIGlzc3VlcyB5b3UgYXJlIHJhaXNpbmcgYXJlIGRpc2N1c3NlZCBpbiBpdC4gSWYgdGhhdCBpcyB0aGUgY2FzZSwgeW91IGFyZSB3YXN0aW5nIGJvdGggbXkgdGltZSBhbmQgeW91ciB0aW1lLiBTbyBwbGVhc2UgcmVhZCBpdC4gSWYgeW91IGRpc2FncmVlIHdpdGggdGhlIHRleHQsIHRoZW4gcmVhZCB0aGUgcmVsZXZhbnQgc2VjdGlvbnMgb2YgdGhlIHJlZmVyZW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> Message-ID: <1360716709.59676.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Tue, 12 Feb 2013 16:51:49 -0800 (PST) From: Mark Smith To: Owen DeLong In-Reply-To: <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 00:51:57 -0000 Owen, I've pretty much come to the conclusion that you haven't read my draf= t, as the issues you are raising are discussed in it. If that is the case, = you are wasting both my time and your time. So please read it. If you disag= ree with the text, then read the relevant sections of the references I've p= rovided. Only then will I bother further engaging with you. I don't want to= spend time rehashing points I've discussed in the draft on this emailing l= ist, just because you haven't bothered reading the draft.=0A=0A=0A----- Ori= ginal Message -----=0A> From: Owen DeLong =0A> To: Mark Sm= ith =0A> Cc: Doug Barton ; = "v6ops@ietf.org" =0A> Sent: Wednesday, 13 February 2013 11:= 18 AM=0A> Subject: Re: [v6ops] New Version Notification for draft-smith-v6o= ps-larger-ipv6-loopback-prefix-03.txt=0A> =0A> =0A> On Feb 12, 2013, at 12:= 33 PM, Mark Smith =0A> wrote:=0A> =0A>> =0A>> = =0A>> =0A>> =0A>> ----- Original Message -----=0A>>> From: Owen DeLong =0A>>> To: Mark Smith =0A>>> Cc= : Doug Barton ; "v6ops@ietf.org" =0A> = =0A>>> Sent: Wednesday, 13 February 2013 6:59 AM=0A>>> Subject: Re: [v6op= s] New Version Notification for =0A> draft-smith-v6ops-larger-ipv6-loopback= -prefix-03.txt=0A>>> =0A>>>>> =0A>>>>> ?? I don't see how it gets easier t= o remember than fd00::/8=0A>>>> =0A>>>> The random bit is the hard bit to = remember and type. I don't =0A> think =0A>>> you're thinking enough about = how it is to use, you're only =0A> thinking =0A>>> about how hard it is to= configure. The time and effort to configure =0A> something is =0A>>> usua= lly minimal compared to the amount of time and effort spent while =0A> it i= s =0A>>> being used.=0A>>>> =0A>>> =0A>>> Nothing requires you to use ran= dom for this purpose. Use fd00::/64 for =0A> all =0A>>> anyone cares.=0A>>= > =C2=A0 =0A>> =0A>> RFC4193 does. It's not a ULA if it doesn't, it's been= made a =0A> site-local. See RFC3879 for the problems with them and your no= n-random ULA.=0A>> =0A> =0A> Which is irrelevant to the loopback scenario y= ou have described=E2=80=A6=0A> =0A>> =0A>>>>> and you can use =0A>>>> =0A>= >>>> anything you want inside of that to provide a /64 for your =0A> devel= opment =0A>>> purpose.=0A>>>>> =0A>>>>> What's more cumbersome about pick= ing something (even =0A> fd00::/64, if =0A>>> you want) =0A>>>> =0A>>>> N= o, that's bad, as it is a ULA prefix which doesn't have a =0A> random =0A>>= > component. Add the random component (if you aren't lazy), and it =0A> th= en =0A>>> becomes hard to remember and type.=0A>>>> =0A>>> =0A>>> Why is = it bad that it doesn't have a random component? If it's =0A> in a =0A>>> d= evelopment test lab, it's not like it's at risk of corporate =0A> merger = =0A>>> conflicts, etc.=0A>>> =C2=A0 =0A>> =0A>> See slide 26.=0A>> =0A>> = http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf=0A>> =0A> =0A> Which d= oes not apply to use on a loopback interface.=0A> =0A>> =0A>>>>> for devel= opment than having some other prefix you have to =0A> configure =0A>>> ass= igned by =0A>>>> =0A>>>>> the IETF.=0A>>>> =0A>>>> I'm starting to wonder= if you've actually read the draft. =0A> The =0A>>> intention is that it i= s that the larger loopback prefix automatically =0A> configured =0A>>> at = system initialisation, as ::1/128 and 127/8 currently are. There is =0A> a = whole =0A>>> section on automatic address assignment and configuration.=0A= >>> =0A>>> 127/8 isn't auto-assigned. 127.0.0.1/8 is.=0A>>> =C2=A0 =0A>> = =0A>> That's incorrect.=0A>> =0A>> =C2=A0 RFC1122, "Requirements for Inter= net Hosts -- Communication =0A> Layers", specifically the in=0A>> =0A= >> "(g) { 127, }=0A>> Internal host loopback address.=C2=A0 Address= es of this form MUST NOT appear =0A> outside a host."=0A>> =0A> =0A> Yes, i= t requires that you not have addresses within 127.0.0.0/8 appear outside = =0A> of the host. It does=0A> not require the host to answer or auto config= ure all of the 127.0.0.0/8 =0A> addresses on its loopback=0A> interface and= , indeed, most hosts do NOT auto configure other than 127.0.0.1.=0A> =0A>>>= > =C2=A0 =0A>> =0A>>>>> =0A>>>>> Sorry, but I just don't get it.=0A>>>>> = =0A>>>>>> =0A>>>>> =0A>>>>>> This proposal also takes the opportunity to i= ntroduce =0A> IPv4-like =0A>>> handling of =0A>>>>> loopback IPv6 packets= so that future functions similar to the =0A> use in =0A>>> RFC4379 =0A>>>= >> have a native IPv6 address space to use, rather than using =0A> 127/8 w= ithin =0A>>> an IPv6 =0A>>>>> prefix.=0A>>>>> =0A>>>>> In my (admittedly= limited) testing, putting a /64 of ULA on the =0A> =0A>>> loopback =0A>>>= >> interface did just that, so I'm not sure what it is that =0A> you feel = =0A>>> is =0A>>>>> missing.=0A>>>>> =C2=A0 =0A>>>> =0A>>>> All addresses= within 127/8 are valid and available on the host, =0A> where as =0A>>> wi= th your ULA, only 1 is.=0A>>>> =0A>>>> e.g.=0A>>>> =0A>>>> =0A>>>> [root@= opy mark]# ip addr show dev lo=0A>>>> 1: lo: mtu 65= 536 qdisc noqueue state =0A> UNKNOWN =0A>>>> =C2=A0 =C2=A0 =C2=A0 link/loop= back 00:00:00:00:00:00 brd 00:00:00:00:00:00=0A>>>> =C2=A0 =C2=A0 =C2=A0 in= et 127.0.0.1/8 scope host lo=0A>>>> =C2=A0 =C2=A0 =C2=A0 inet6 fd00:db8::1/= 64 scope global =0A>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid_lft forever pref= erred_lft forever=0A>>>> =C2=A0 =C2=A0 =C2=A0 inet6 1::1/64 scope global = =0A>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid_lft forever preferred_lft foreve= r=0A>>>> =C2=A0 =C2=A0 =C2=A0 inet6 ::1/128 scope host =0A>>>> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 valid_lft forever preferred_lft forever=0A>>>> =0A>>>> = [root@opy mark]# ping -c 1 127.1.2.3=0A>>>> PING 127.1.2.3 (127.1.2.3) 56(= 84) bytes of data.=0A>>>> 64 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 t= ime=3D0.053 ms=0A>>>> =0A>>>> --- 127.1.2.3 ping statistics ---=0A>>>> 1 = packets transmitted, 1 received, 0% packet loss, time 0ms=0A>>>> rtt min/a= vg/max/mdev =3D 0.053/0.053/0.053/0.000 ms=0A>>>> [root@opy mark]# =0A>>>>= =0A>>> =0A>>> Interesting=E2=80=A6 I get this behavior on MacOS.=0A>>> = =0A>>> [tc01-dhcp153:~] owen% ifconfig lo0=0A>>> lo0: flags=3D8049 mtu 16384=0A>>> =C2=A0 =C2=A0 options=3D3=0A>>> =C2=A0 =C2=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 =0A= >>> =C2=A0 =C2=A0 inet 127.0.0.1 netmask 0xff000000 =0A>>> =C2=A0 =C2=A0 = inet6 ::1 prefixlen 128 =0A>>> =0A>>> [tc01-dhcp153:~] owen% ping 127.1.2.= 3=0A>>> PING 127.1.2.3 (127.1.2.3): 56 data bytes=0A>>> Request timeout f= or icmp_seq 0=0A>>> Request timeout for icmp_seq 1=0A>>> Request timeout = for icmp_seq 2=0A>>> Request timeout for icmp_seq 3=0A>>> ^C=0A>>> --- 1= 27.1.2.3 ping statistics ---=0A>>> 5 packets transmitted, 0 packets receiv= ed, 100.0% packet loss=0A>>> =C2=A0 =0A>> =0A>> So MacOS isn't compliant w= ith RFC1122.=0A>> =0A> =0A> How do you figure that? You'll need to be more = specific.=0A> =0A>> =0A>>> Admittedly, Linux does this:=0A>>> =0A>>> owen= .delong.com:owen /home4/owen (22) % ifconfig lo=0A>>> lo=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Link encap:Local Loopback=C2=A0 =0A>>> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 inet addr:127.0.0.1=C2=A0 Mask:255.0.0.0=0A>>> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 inet6 addr: ::1/128 Scope:Host=0A>>> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 UP LOOPBACK RUNNING=C2=A0 MTU:16436=C2=A0 Metric:1=0A= >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX packets:45816328 errors:0 droppe= d:0 overruns:0 frame:0=0A>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX packets= :45816328 errors:0 dropped:0 overruns:0 carrier:0=0A>>> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 collisions:0 txqueuelen:0 =0A>>> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 RX bytes:578712867 (551.9 MiB)=C2=A0 TX bytes:578712867 (551= .9 =0A> MiB)=0A>>> =0A>>> owen.delong.com:owen /home4/owen (23) % ping 127= .1.2.3=0A>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.=0A>>> 64 by= tes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 time=3D0.043 ms=0A>>> 64 bytes f= rom 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0.032 ms=0A>>> 64 bytes from 1= 27.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 ms=0A>>> ^C=0A>>> --- 127.1.= 2.3 ping statistics ---=0A>>> 3 packets transmitted, 3 received, 0% packet= loss, time 2000ms=0A>>> rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 = ms=0A>>> owen.delong.com:owen /home4/owen (24) % =0A>>> =0A>>> =0A>>> =0A>= >>> [root@opy mark]# ping6 -c 1 fd00:db8::2=0A>>>> =0A>>>> connect: Netwo= rk is unreachable=0A>>>> [root@opy mark]#=0A>>>> =0A>>>> [mark@opy ~]$ ss= h 127.1.2.3=0A>>>> The authenticity of host '127.1.2.3 (127.1.2.3)' can't = =0A> be =0A>>> established.=0A>>>> =0A>>>> [mark@opy ~]$ ssh -6 fd00:db8:= :2=0A>>>> ssh: connect to host fd00:db8::2 port 22: Network is unreachable= =0A>>>> [mark@opy ~]$=0A>>>> =0A>>> =0A>>> From what I can see, this seem= s to depend on a pathology not =0A> universally =0A>>> available even in I= Pv4.=0A>>> =0A>>>> Another test you should do to measure the usefulness of= this =0A> proposal is =0A>>> see how long it takes and your opinion after= wards of how hard or easy =0A> it is to =0A>>> type or cut and paste "fd00= :db8::1" vs "1::1" a =0A> reasonable =0A>>> number of times e.g. 6 times.= =0A>>>> =0A>>> =0A>>> I'm fine with it. If you're doing it more than 6 tim= es, =0A> that's what =0A>>> DNS is for.=0A>>> =C2=A0 =0A>> =0A>> That's a= n option, for applications that use DNS to resolve addresses. =0A> There ar= e applications that need to deal with addresses directly, such as mine, =0A= > due to their nature and purpose.=0A> =0A> Then use a configuration file o= r whatever. There are lots of alternatives to =0A> repeatedly typing in add= resses.=0A> (command-line aliases come to mind as an example).=0A> =0A>> = =0A>>>> =0A>>>> Using a ULA doesn't really work at all. It only adds anoth= er =0A> address to =0A>>> the host, rather than many. A properly formed UL= A is hard to type and =0A> remember. =0A>>> It's far less user friendly th= an the short larger loopback prefix =0A> I'm =0A>>> proposing. This is bas= ed on my experience, as I've used a ULA for =0A> the =0A>>> purpose of try= ing to increase the number of loopback IPv6 addresses.=0A>>>> =0A>>> =0A>>>= The same is true with loopback except on Linux as near as I can tell.=0A>= >> =C2=A0 =0A>> =0A>> Windows 7 also behaves this way, as it complies with= RFC1122.=0A>> =0A> =0A> Nothing I found in RFC 1122 requires this, so if y= ou think something does, =0A> you'll=0A> need to point it out.=0A> =0A> I k= now for a fact that several Cisco switches did not. For example, they used = to =0A> use=0A> 127.0.0. as a convenient hack for connections = across the =0A> backplane=0A> to the IP stack running on IP-aware blades su= ch as RSMs.=0A> =0A>>>>>> =C2=A0 =0A>>>> =0A>>>>>>> Note, I don't know the= answer, but I'm leaning =0A> heavily =0A>>> towards, =0A>>>>> =0A>>>>>>> = "no."=0A>>>>>>> =0A>>>>>>> Primarily because we're asking people to deplo= y =0A> this =0A>>> protocol for =0A>>>>>>> real-world scenarios, and we a= lready have a pretty wide =0A> =0A>>> divergence in =0A>>>>>>> the latest= state of the standards vs. the oldest =0A> working =0A>>> deployed base. = =0A>>>>> =0A>>>>>>> Widening that gap should only be done for truly =0A> c= ritical =0A>>> changes, and =0A>>>>>>> I'm not sure you've made your case= =0A> sufficiently.=0A>>>>>>> =0A>>>>>>> Put more simply, at some point we= have to stop =0A> tinkering with =0A>>> the plane =0A>>>>> =0A>>>>>>> wh= ile it's in the air.=0A>>>>>>> =C2=A0 =0A>>>>>> =0A>>>>>> So I think the i= mplication of that analogy is that =0A> deploying this =0A>>>>> enhancemen= t will somehow interrupt the existing operation of =0A> IPv6 =0A>>>>> impl= ementations ("the plane") causing them to fail =0A>>> ("fall out of =0A>>>= >> the sky"). I don't see how that will be the case. =0A> Deploying a =0A>= >> new =0A>>>>> loopback prefix would leverage many of the existing addre= ss =0A>>> configuration and =0A>>>>> loopback related functions of existi= ng IPv6 implementations. It =0A> is not =0A>>> much more =0A>>>>> than a = larger version of ::1/128.=0A>>>>> =0A>>>>> The implication is that you ar= e requesting to once again =0A> obsolete all =0A>>> existing =0A>>>>> imp= lementations in favor of requiring deploying another =0A> fundamentally =0A= >>> changed =0A>>>>> IPv6 stack.=0A>>>> =0A>>>> Can you define the thres= hold of "fundamentally changed" =0A> for me?=0A>>>> =0A>>> =0A>>> Requirin= g a modification to every existing IPv6 stack in the wild which =0A> could = be=0A>>> incorporated into software dependencies which would render existi= ng =0A> stacks =0A>>> unexpectedly=0A>>> obsolete.=0A>>> =0A>>>> I don't= consider this to be a fundamental change. It is adding =0A> another =0A>>>= loopback prefix, which operates the same as the existing one, just with = =0A> a =0A>>> shorter prefix length. It is adding values to the source and= =0A> destination address =0A>>> selection policy, which is already possib= le to do because it's been =0A> designed =0A>>> that way. I'm quite confid= ent that it is going to be no more than =0A> 10 lines, =0A>>> and probably= closer to 5 additional lines of code in a stack for a host =0A> =0A>>> im= plementation that only supports a single loopback interface. =0A> That's co= de =0A>>> change size closer to the size of bug fixes than additional =0A>= functionality.=0A>>>> =0A>>> =0A>>> So you want to force everyone to upda= te their IPv6 stack on every host, =0A> router, =0A>>> switch, etc. just s= o you can save some typing?=0A>>> =C2=A0 =0A>> =0A>> The IETF (and I) can'= t force anything. If it's useful, it'll be =0A> implemented.=0A>> =0A> =0A>= IMHO, it's not all that useful and making it a stack requirement would lea= d =0A> to one of two bad situations:=0A> =0A> 1.=C2=A0=C2=A0=C2=A0 Developm= ent resources would be taken away from tasks that matter.=0A> or=0A> 2.=C2= =A0=C2=A0=C2=A0 Increasing divergence between the implemented stacks and th= e documented =0A> standards.=0A> =0A> =0A>>> You're doing a very good job = cementing my opposition here.=0A>>> =C2=A0 =0A>> =0A>> You seem to like do= ing things the hard way. My view is computers should do =0A> things automat= ically for people so that people can get on with more valuable =0A> things.= Developers should be cutting code instead of setting up development =0A> e= nvironments, or waiting for system administrators to set up the development= =0A> environment for them.=0A>> =0A> =0A> Actually, I do not. However, I d= o not believe in using the entire IP stack =0A> development community as a = workforce to save me a little bit of typing which, as =0A> near as I can te= ll is all that this proposal would accomplish.=0A> =0A> The functionality y= ou seek is available using ULA. The issues you cite with ULA =0A> would not= apply to loopback usage. The functionality that you attribute to RFC =0A> = 1122 isn't (as near as I can tell) actually codified into RFC 1122 (I =0A> = don't see how requiring that an address range not appear outside of a host = =0A> requires that host to accept all packets to any address in said range,= which is =0A> what you are claiming).=0A> =0A>>>> My definition of a fund= amental change would be to do something like =0A> change =0A>>> the change= the size of the IPv6 address, or reorder the fields in the =0A> IPv6 =0A>>= > header.=0A>>>> =0A>>> =0A>>> That would be a drastic change, indeed. Th= is is less drastic, but it =0A> would make =0A>>> current IPv6 stacks inco= mpatible with the protocol definition.=0A>>> =C2=A0 =0A>> =0A>> I don't ge= t this. 1::/32 is not currently used for anything, so using =0A> it is not = going to make it incompatible with anything. Using other prefixes for =0A> = purposes that they weren't designed for, such as a ULA as a loopback, has = =0A> far greater risk of creating incompatibility. =0A> =0A> If you add thi= s as a required stack feature, stacks which don't implement =0A> the featur= e are no longer compliant.=0A> =0A>> =0A>>>>> The question is whether ther= e is enough value in the change to =0A>>>>> justify such a decision and IM= HO, at this point, just to make =0A> it =0A>>> "less =0A>>>>> cumbersome"= than putting (a) ULA address(es) on the =0A> loopback =0A>>> interface = =0A>>>>> strikes me as not having much value.=0A>>>>> =C2=A0 =0A>> =0A>> = You don't seem to be placing any value convenience. Does your car have =0A>= an automatic transmission? Do you have a dishwasher? Do you go to restaura= nts? =0A> All of those things only exist because humans place value on the = convenience of =0A> not manually changing gears, not manually washing dishe= s, and not cooking at =0A> home when we could. Why have to do something man= ually when a computer could do =0A> it automatically for you?=0A>> =C2=A0 = =0A> =0A> I place tremendous value on convenience. My car does not have a t= raditional =0A> automatic transmission, my car has an ECVT transmission. If= I were buying a car, =0A> I would actually prefer a manual transmission be= cause I prefer the greater =0A> control flexibility and shifting precision = afforded by a manual transmission.=0A> =0A> Yes, I go to restaurants.=0A> = =0A> There are many equally automatic solutions to your problem already ava= ilable =0A> without involving the entire body of protocol developers and th= e IETF in the =0A> process.=0A> =0A> Owen=0A> =0A>>>>> Owen=0A>>>>> =0A>>>= >>> =C2=A0 =0A>>>>>> =0A>>>>>> Regards,=0A>>>>>> Mark.=0A>>>>>> =0A>>>>>>= =0A>>>>>>> Doug=0A>>>>>>> =0A>>>>>>> =0A>>>>>>> On 02/11/2013 01:37 PM, = David Farmer wrote:=0A>>>>>>>> On 2/11/13 14:28 , Owen DeLong wrote:=0A>>>= >>>>>> Perhaps I'm not very bright, but is there =0A> any =0A>>> reason U= LA =0A>>>>>>> couldn't be=0A>>>>>>>>> used on the LO interface to=0A>>>>>= >>>> satisfy this corner case?=0A>>>>>>>> =0A>>>>>>>> The Draft does cove= r why ULA is thought to not be a =0A> =0A>>> sufficient =0A>>>>> solution= ,=0A>>>>>>>> do you disagree with the reasoning in the draft?=0A>>>>>>>> = =0A>>>>>>>> from Section 1;=0A>>>>>>>> =0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 A Unique Local IPv6 Unicast Address (ULA) =0A> prefix =0A>>> [RFC41= 93] =0A>>>>> could be=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 used to incre= ase the number of addresses =0A> available on =0A>>> the =0A>>>>> local h= ost.=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 However this prefix would need = to be =0A> manually =0A>>> generated and=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 configured at least once by a system =0A> administrator or =0A>>> = =0A>>>>> operator.=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Without additona= l configuration, traffic =0A> towards =0A>>> addresses not=0A>>>>>>>> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 assigned to the local host would not be =0A> preve= nted =0A>>> from leaving =0A>>>>> the=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 host, and access may not be limited to the =0A> local =0A>>> host.=C2= =A0 A ULA =0A>>>>> prefix=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 would not= be well known, and would not be =0A> convenient =0A>>> to =0A>>>>> remem= ber and=0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 type without violating the r= andomness =0A> requirements of =0A>>> the =0A>>>>> Global ID=0A>>>>>>>> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 component of a ULA prefix.=0A>>>>>>>> =0A>>>>>>= >>> Owen=0A>>>>>>>>> =0A>>>>>>>>> On Feb 11, 2013, at 12:20 , Mark Smith = =0A>>>>>>> wrote:=0A>>>>>>>>> =0A>>>>>>>>>> H= i,=0A>>>>>>>>>> =0A>>>>>>>>>> Here is a new version of my IPv6 larger =0A>= loopback =0A>>> prefix =0A>>>>> draft.=0A>>>>>>>>>> Changes since the p= revious version:=0A>>>>>>>>>> =0A>>>>>>>>>> o=C2=A0 default address select= ion precedence and =0A> label =0A>>> values=0A>>>>>>>>>> o=C2=A0 comment = about other IPv4 in IPv6 address =0A> forms=0A>>>>>>>>>> =0A>>>>>>>>>> o= =C2=A0 more clarifications=0A>>>>>>>>>> =0A>>>>>>>>>> o=C2=A0 grammar corr= ections=0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> My thanks to Bill Atwood,= Matts Kallioniemi =0A> and =0A>>> Tina Tsou =0A>>>>> for their=0A>>>>>>>= >>> review and comments on this revision.=0A>>>>>>>>>> =0A>>>>>>>>>> Furt= her review and comments would be most =0A>>> appreciated.=0A>>>>>>>>>> =0A= >>>>>>>>>> Thanks,=0A>>>>>>>>>> Mark.=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> = =0A>>>>>>> =0A>>>>>>> _______________________________________________=0A>>= >>>>> v6ops mailing list=0A>>>>>>> v6ops@ietf.org=0A>>>>>>> https://www.= ietf.org/mailman/listinfo/v6ops=0A>>>>>>> =0A>>>>>> ______________________= _________________________=0A>>>>>> v6ops mailing list=0A>>>>>> v6ops@ietf= .org=0A>>>>>> https://www.ietf.org/mailman/listinfo/v6ops=0A>>>>> =0A>>> = =0A> From owen@delong.com Tue Feb 12 17:49: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 94FEC21F86E8 for ; Tue, 12 Feb 2013 17:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=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 LYS2fkemSTT7 for ; Tue, 12 Feb 2013 17:49:49 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDEB21F86E7 for ; Tue, 12 Feb 2013 17:49:48 -0800 (PST) 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 r1D1kGG3013321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Feb 2013 17:46:17 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1D1kGG3013321 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360719977; bh=0BP/nkiqR0vBfe6yYosJFrGWi0c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=cuiUP7e3XVwsVQk6LgtDxl/wRp9BizjfNWpConYKvQRjUquxmCu0tQHb61nMhkGeY JCw/uNaF7KeJsAy70lTE3zKkOLvZHJMPhFpit1xXj6xOv8EVAO3WuxoS63uR0P3Pn4 aqWHmZ6w73Whm3khSolc+rVc1GXRrgpRrng1vSoE= Content-Type: multipart/alternative; boundary="Apple-Mail=_50EB6A61-EFBC-4244-9396-503986386E84" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> Date: Tue, 12 Feb 2013 17:46:09 -0800 Message-Id: References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 12 Feb 2013 17:46:17 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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, 13 Feb 2013 01:49:52 -0000 --Apple-Mail=_50EB6A61-EFBC-4244-9396-503986386E84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I had actually read it, but, since you insist=85 1. Under IPv4, the 127/8 loopback prefix [RFC1122] provides many addresses that can be used to run multiple instances of an application on the same port, while also limiting access to the local host. RFC1122 provides that 127/8 cannot appear outside of a host. It does not = require that the host process all addresses within 127/8 as you = describe. 2. Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a single address. Multiple application instances using the same port, bound to different loopback addresses, is not possible. Is not true. You can configure additional addresses on to the loopback = interface as desired and use them just as you would additional addresses = from the 127/8 address range. Since RFC1122 does not require that the = host treat all these addresses identically as you assume, there is no = difference between the current standards in IPv6 and the current = standards in IPv4 except that IPv4 sets aside a dedicated 16.7 million = host addresses for this purpose (of which only one is utilized in most = cases) and IPv6 sets aside 1. However, you are free to assign any GUA = or ULA prefix to the IPv6 loopback and use it in the same manner as you = are currently using the other 127/8 addresses. 3. A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be used to increase the number of addresses available on the local host. However this prefix would need to be manually generated and configured at least once by a system administrator or operator. Without additonal configuration, traffic towards addresses not assigned to the local host would not be prevented from leaving the host, and access may not be limited to the local host. A ULA prefix would not be well known, and would not be convenient to remember and type without violating the randomness requirements of the Global ID component of a ULA prefix. Since the communication of this prefix in this case would not be = expected to extend beyond the host, the only requirement is that the ULA prefix chosen not conflict with one = that the host is expected to need to reach outside of the host. As such, = fd00::/48 is a perfectly viable candidate in the vast majority of cases = as it is very unlikely to conflict with a randomly chosen routable = prefix that follows the standards in RFC4193. The Global ID component of a ULA prefix is intended to avoid conflicts = in the results of M&A, etc. Since this would be host-local addressing = and not even have site-scope, use of a known non-conflicting ULA address = is perfectly feasible. fd00::/48 is very unlikely to conflict (1 in 2^40 = or < 0.000,000,000,1% or <1 in 1e12). 4. 2. Larger Loopback Prefix Requirements A new larger loopback prefix should attempt to satisfy all of the following requirements. It should: o be a well known prefix, o be within an existing special purpose prefix, such as 0000::/8 (the parent prefix of the current IPv6 loopback address), o be easy for a human to remember, o be easy for a human to type, o cover the existing loopback prefix, o support 64 bit Interface Identifiers, o provide a large number of /64 subnets. I believe that fd00::/48 could do what you describe: 1. I question the need for it to be well known. As long as = it is well known within the scope of the intended use, I think that suffices for = the use cases you have described. fd00::/48 could easily meet that test. 2. fd00::/48 is within the existing ULA special purpose = prefix. 3. fd00::/48 is very easy for a human to remember. 4. fd00::/48 is very easy for a human to type. 5. Please justify your claim that it should encompass the = existing loopback address. 6. fd00::/48 supports 64 bit IIDs. 7. fd00::/48 provides 65,536 /64 subnets. Is there some = reason you think this is insufficient? This is a total of 4 billion times 16.7 million times as = many host addresses as were provided in the IPv4 loopback. It is 1/256th as many networks as IPv4 provided loopback = hosts. 5. 3. Proposed Larger Loopback Prefix Ideally, the prefix length of ::1/128 could be shortened, resulting in a larger loopback prefix such as ::/48. However, if the existing loopback prefix length is shortened enough to satisfy all of the larger loopback prefix requirements, it would then cover the IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use described in [RFC4038]. Giving up the requirement of covering the existing loopback prefix, the proposed larger loopback prefix is: So why not simply delete this from the requirements list as you've = failed to provide any justification for said requirement anyway. Smith Expires August 15, 2013 [Page 4] =20 Internet-Draft A Larger IPv6 Loopback Prefix February 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 This prefix satisfies all remaining larger loopback prefix requirements. I think this is a terrible choice of location. It pretty much maximizes = the fragmentation damage that can be done by the choice of prefix. = :1::/32 would at least be the first /32 available. As I've stated, a = locally chosen address such as fd00::/48 (or whatever selection of = chosen ULA space meets local requirements) is equally viable IMHO. 6. Allocating a /32 prefix for the loopback function may seem excessive, as a /48 length prefix would satisfy the larger loopback prefix requirements. However, within the parent 0000::/8 special purpose prefix, there are approximately 16 million /32 prefixes, so a single /32 for the larger loopback prefix is easily afforded. A /32 larger loopback prefix will satisfy all current and likely future uses of the loopback function. Allocating a /32 is absurdly excessive and just because we can does not = strike me as anything remotely resembling an argument that we should. 4. Address Assignment and Configuration Consistent with the IPv6 addressing model [RFC4291], each address within the larger loopback prefix is associated with one of the node's interfaces, although not necessarily the same interface for all addresses. This means that the node acts as though all addresses within the larger loopback prefix have been configured on one or more interfaces. Applications will accept packets destined to any of the larger loopback prefix addresses, unless the application is bound to specific larger loopback addresses. Typically the addresses will be logically assigned to one or more virtual "loopback" interfaces, which locally returns or loops outgoing packets back to the same node that originated the packets. I believe you have misread and conflated RFC4291 and RFC1122 with = regards to how loopback addresses function. Unless I am mistaken, there is no requirement in RFC1122 that a node = answer all addresses within 127/8. Some nodes may support more than one loopback interface. These subsequent loopback interfaces, when initialised, should be assigned Smith Expires August 15, 2013 [Page 5] =20 Internet-Draft A Larger IPv6 Loopback Prefix February 2013 a larger loopback /64 prefix locally unique within the node. All addresses within the assigned /64 are logically assigned to the interface. Additionally, the ":1" address for the subnet should be configured on the loopback interface, making it visible to a system operator or user. This would, indeed, be new functionality. I am not convinced of any = value to having that functionality and it is radically different from = any required functionality in IPv4 today. In IPv4, hosts which support = multiple loopbacks have no default address or range on the subsequent = loopback interfaces. If you cannot justify a need for this functionality, I see no point in = advancing it as a standard. It should be possible for an operator to remove these automatically configured loopback addresses. It should also be possible for an operator to configure further loopback addresses from within the assigned /64, or addresses from other parts of the larger loopback prefix, including other /64s assigned to other loopback interfaces. Other addresses within the assigned /64(s) would continue to be logically assigned to the subsequent loopback interface. Configuration of addresses is for operational visibility and convenience, and does not change the behaviour of non-visible logically assigned addresses. If you're going to do this, then I would argue that it "must" be = possible for an operator to remove=85 The rest of what you suggest strikes me as being a kernel routing = hairball of unnecessarily large proportion and likely to engender more bugs than functionality. ------ This covers the first 6 pages (approximately half of the draft). I'm not = going to take the time to write up the problems in the rest of the draft = at this point because the above are, IMHO, more than sufficient reason = to oppose adoption. Owen On Feb 12, 2013, at 4:18 PM, Owen DeLong wrote: >=20 > On Feb 12, 2013, at 12:33 PM, Mark Smith = wrote: >=20 >>=20 >>=20 >>=20 >>=20 >> ----- Original Message ----- >>> From: Owen DeLong >>> To: Mark Smith >>> Cc: Doug Barton ; "v6ops@ietf.org" = >>> Sent: Wednesday, 13 February 2013 6:59 AM >>> Subject: Re: [v6ops] New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>>=20 >>>>>=20 >>>>> ?? I don't see how it gets easier to remember than fd00::/8 >>>>=20 >>>> The random bit is the hard bit to remember and type. I don't think=20= >>> you're thinking enough about how it is to use, you're only thinking=20= >>> about how hard it is to configure. The time and effort to configure = something is=20 >>> usually minimal compared to the amount of time and effort spent = while it is=20 >>> being used. >>>>=20 >>>=20 >>> Nothing requires you to use random for this purpose. Use fd00::/64 = for all=20 >>> anyone cares. >>>=20 >>=20 >> RFC4193 does. It's not a ULA if it doesn't, it's been made a = site-local. See RFC3879 for the problems with them and your non-random = ULA. >>=20 >=20 > Which is irrelevant to the loopback scenario you have described=85 >=20 >>=20 >>>>> and you can use=20 >>>>=20 >>>>> anything you want inside of that to provide a /64 for your = development=20 >>> purpose. >>>>>=20 >>>>> What's more cumbersome about picking something (even fd00::/64, if=20= >>> you want)=20 >>>>=20 >>>> No, that's bad, as it is a ULA prefix which doesn't have a random=20= >>> component. Add the random component (if you aren't lazy), and it = then=20 >>> becomes hard to remember and type. >>>>=20 >>>=20 >>> Why is it bad that it doesn't have a random component? If it's in a=20= >>> development test lab, it's not like it's at risk of corporate merger=20= >>> conflicts, etc. >>>=20 >>=20 >> See slide 26. >>=20 >> http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf >>=20 >=20 > Which does not apply to use on a loopback interface. >=20 >>=20 >>>>> for development than having some other prefix you have to = configure=20 >>> assigned by=20 >>>>=20 >>>>> the IETF. >>>>=20 >>>> I'm starting to wonder if you've actually read the draft. The=20 >>> intention is that it is that the larger loopback prefix = automatically configured=20 >>> at system initialisation, as ::1/128 and 127/8 currently are. There = is a whole=20 >>> section on automatic address assignment and configuration. >>>=20 >>> 127/8 isn't auto-assigned. 127.0.0.1/8 is. >>>=20 >>=20 >> That's incorrect. >>=20 >> RFC1122, "Requirements for Internet Hosts -- Communication Layers", = specifically the in >>=20 >> "(g) { 127, } >> Internal host loopback address. Addresses of this form MUST NOT = appear outside a host." >>=20 >=20 > Yes, it requires that you not have addresses within 127.0.0.0/8 appear = outside of the host. It does > not require the host to answer or auto configure all of the = 127.0.0.0/8 addresses on its loopback > interface and, indeed, most hosts do NOT auto configure other than = 127.0.0.1. >=20 >>>>=20 >>=20 >>>>>=20 >>>>> Sorry, but I just don't get it. >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>> This proposal also takes the opportunity to introduce IPv4-like=20= >>> handling of=20 >>>>> loopback IPv6 packets so that future functions similar to the use = in=20 >>> RFC4379=20 >>>>> have a native IPv6 address space to use, rather than using 127/8 = within=20 >>> an IPv6=20 >>>>> prefix. >>>>>=20 >>>>> In my (admittedly limited) testing, putting a /64 of ULA on the=20 >>> loopback=20 >>>>> interface did just that, so I'm not sure what it is that you feel=20= >>> is=20 >>>>> missing. >>>>>=20 >>>>=20 >>>> All addresses within 127/8 are valid and available on the host, = where as=20 >>> with your ULA, only 1 is. >>>>=20 >>>> e.g. >>>>=20 >>>>=20 >>>> [root@opy mark]# ip addr show dev lo >>>> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN=20= >>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >>>> inet 127.0.0.1/8 scope host lo >>>> inet6 fd00:db8::1/64 scope global=20 >>>> valid_lft forever preferred_lft forever >>>> inet6 1::1/64 scope global=20 >>>> valid_lft forever preferred_lft forever >>>> inet6 ::1/128 scope host=20 >>>> valid_lft forever preferred_lft forever >>>>=20 >>>> [root@opy mark]# ping -c 1 127.1.2.3 >>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>>> 64 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 ms >>>>=20 >>>> --- 127.1.2.3 ping statistics --- >>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms >>>> rtt min/avg/max/mdev =3D 0.053/0.053/0.053/0.000 ms >>>> [root@opy mark]#=20 >>>>=20 >>>=20 >>> Interesting=85 I get this behavior on MacOS. >>>=20 >>> [tc01-dhcp153:~] owen% ifconfig lo0 >>> lo0: flags=3D8049 mtu 16384 >>> options=3D3 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 >>> inet 127.0.0.1 netmask 0xff000000=20 >>> inet6 ::1 prefixlen 128=20 >>>=20 >>> [tc01-dhcp153:~] owen% ping 127.1.2.3 >>> PING 127.1.2.3 (127.1.2.3): 56 data bytes >>> Request timeout for icmp_seq 0 >>> Request timeout for icmp_seq 1 >>> Request timeout for icmp_seq 2 >>> Request timeout for icmp_seq 3 >>> ^C >>> --- 127.1.2.3 ping statistics --- >>> 5 packets transmitted, 0 packets received, 100.0% packet loss >>>=20 >>=20 >> So MacOS isn't compliant with RFC1122. >>=20 >=20 > How do you figure that? You'll need to be more specific. >=20 >>=20 >>> Admittedly, Linux does this: >>>=20 >>> owen.delong.com:owen /home4/owen (22) % ifconfig lo >>> lo Link encap:Local Loopback =20 >>> inet addr:127.0.0.1 Mask:255.0.0.0 >>> inet6 addr: ::1/128 Scope:Host >>> UP LOOPBACK RUNNING MTU:16436 Metric:1 >>> RX packets:45816328 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:45816328 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:0=20 >>> RX bytes:578712867 (551.9 MiB) TX bytes:578712867 (551.9 = MiB) >>>=20 >>> owen.delong.com:owen /home4/owen (23) % ping 127.1.2.3 >>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>> 64 bytes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 time=3D0.043 ms >>> 64 bytes from 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0.032 ms >>> 64 bytes from 127.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 ms >>> ^C >>> --- 127.1.2.3 ping statistics --- >>> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms >>> rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 ms >>> owen.delong.com:owen /home4/owen (24) %=20 >>>=20 >>>=20 >>>=20 >>>> [root@opy mark]# ping6 -c 1 fd00:db8::2 >>>>=20 >>>> connect: Network is unreachable >>>> [root@opy mark]# >>>>=20 >>>> [mark@opy ~]$ ssh 127.1.2.3 >>>> The authenticity of host '127.1.2.3 (127.1.2.3)' can't be=20 >>> established. >>>>=20 >>>> [mark@opy ~]$ ssh -6 fd00:db8::2 >>>> ssh: connect to host fd00:db8::2 port 22: Network is unreachable >>>> [mark@opy ~]$ >>>>=20 >>>=20 >>> =46rom what I can see, this seems to depend on a pathology not = universally=20 >>> available even in IPv4. >>>=20 >>>> Another test you should do to measure the usefulness of this = proposal is=20 >>> see how long it takes and your opinion afterwards of how hard or = easy it is to=20 >>> type or cut and paste "fd00:db8::1" vs "1::1" a reasonable=20 >>> number of times e.g. 6 times. >>>>=20 >>>=20 >>> I'm fine with it. If you're doing it more than 6 times, that's what=20= >>> DNS is for. >>>=20 >>=20 >> That's an option, for applications that use DNS to resolve addresses. = There are applications that need to deal with addresses directly, such = as mine, due to their nature and purpose. >=20 > Then use a configuration file or whatever. There are lots of = alternatives to repeatedly typing in addresses. > (command-line aliases come to mind as an example). >=20 >>=20 >>>>=20 >>>> Using a ULA doesn't really work at all. It only adds another = address to=20 >>> the host, rather than many. A properly formed ULA is hard to type = and remember.=20 >>> It's far less user friendly than the short larger loopback prefix = I'm=20 >>> proposing. This is based on my experience, as I've used a ULA for = the=20 >>> purpose of trying to increase the number of loopback IPv6 addresses. >>>>=20 >>>=20 >>> The same is true with loopback except on Linux as near as I can = tell. >>>=20 >>=20 >> Windows 7 also behaves this way, as it complies with RFC1122. >>=20 >=20 > Nothing I found in RFC 1122 requires this, so if you think something = does, you'll > need to point it out. >=20 > I know for a fact that several Cisco switches did not. For example, = they used to use > 127.0.0. as a convenient hack for connections across the = backplane > to the IP stack running on IP-aware blades such as RSMs. >=20 >>>>>>=20 >>>>=20 >>>>>>> Note, I don't know the answer, but I'm leaning heavily=20 >>> towards,=20 >>>>>=20 >>>>>>> "no." >>>>>>>=20 >>>>>>> Primarily because we're asking people to deploy this=20 >>> protocol for=20 >>>>>>> real-world scenarios, and we already have a pretty wide=20 >>> divergence in=20 >>>>>>> the latest state of the standards vs. the oldest working=20 >>> deployed base.=20 >>>>>=20 >>>>>>> Widening that gap should only be done for truly critical=20 >>> changes, and=20 >>>>>>> I'm not sure you've made your case sufficiently. >>>>>>>=20 >>>>>>> Put more simply, at some point we have to stop tinkering with=20 >>> the plane=20 >>>>>=20 >>>>>>> while it's in the air. >>>>>>>=20 >>>>>>=20 >>>>>> So I think the implication of that analogy is that deploying this=20= >>>>> enhancement will somehow interrupt the existing operation of IPv6=20= >>>>> implementations ("the plane") causing them to fail=20 >>> ("fall out of=20 >>>>> the sky"). I don't see how that will be the case. Deploying a=20 >>> new=20 >>>>> loopback prefix would leverage many of the existing address=20 >>> configuration and=20 >>>>> loopback related functions of existing IPv6 implementations. It is = not=20 >>> much more=20 >>>>> than a larger version of ::1/128. >>>>>=20 >>>>> The implication is that you are requesting to once again obsolete = all=20 >>> existing=20 >>>>> implementations in favor of requiring deploying another = fundamentally=20 >>> changed=20 >>>>> IPv6 stack. >>>>=20 >>>> Can you define the threshold of "fundamentally changed" for me? >>>>=20 >>>=20 >>> Requiring a modification to every existing IPv6 stack in the wild = which could be >>> incorporated into software dependencies which would render existing = stacks=20 >>> unexpectedly >>> obsolete. >>>=20 >>>> I don't consider this to be a fundamental change. It is adding = another=20 >>> loopback prefix, which operates the same as the existing one, just = with a=20 >>> shorter prefix length. It is adding values to the source and = destination address=20 >>> selection policy, which is already possible to do because it's been = designed=20 >>> that way. I'm quite confident that it is going to be no more than 10 = lines,=20 >>> and probably closer to 5 additional lines of code in a stack for a = host=20 >>> implementation that only supports a single loopback interface. = That's code=20 >>> change size closer to the size of bug fixes than additional = functionality. >>>>=20 >>>=20 >>> So you want to force everyone to update their IPv6 stack on every = host, router,=20 >>> switch, etc. just so you can save some typing? >>>=20 >>=20 >> The IETF (and I) can't force anything. If it's useful, it'll be = implemented. >>=20 >=20 > IMHO, it's not all that useful and making it a stack requirement would = lead to one of two bad situations: >=20 > 1. Development resources would be taken away from tasks that = matter. > or > 2. Increasing divergence between the implemented stacks and the = documented standards. >=20 >=20 >>> You're doing a very good job cementing my opposition here. >>>=20 >>=20 >> You seem to like doing things the hard way. My view is computers = should do things automatically for people so that people can get on with = more valuable things. Developers should be cutting code instead of = setting up development environments, or waiting for system = administrators to set up the development environment for them. >>=20 >=20 > Actually, I do not. However, I do not believe in using the entire IP = stack development community as a workforce to save me a little bit of = typing which, as near as I can tell is all that this proposal would = accomplish. >=20 > The functionality you seek is available using ULA. The issues you cite = with ULA would not apply to loopback usage. The functionality that you = attribute to RFC 1122 isn't (as near as I can tell) actually codified = into RFC 1122 (I don't see how requiring that an address range not = appear outside of a host requires that host to accept all packets to any = address in said range, which is what you are claiming). >=20 >>>> My definition of a fundamental change would be to do something like = change=20 >>> the change the size of the IPv6 address, or reorder the fields in = the IPv6=20 >>> header. >>>>=20 >>>=20 >>> That would be a drastic change, indeed. This is less drastic, but it = would make=20 >>> current IPv6 stacks incompatible with the protocol definition. >>>=20 >>=20 >> I don't get this. 1::/32 is not currently used for anything, so using = it is not going to make it incompatible with anything. Using other = prefixes for purposes that they weren't designed for, such as a ULA as a = loopback, has far greater risk of creating incompatibility.=20 >=20 > If you add this as a required stack feature, stacks which don't = implement the feature are no longer compliant. >=20 >>=20 >>>>> The question is whether there is enough value in the change to=20 >>>>> justify such a decision and IMHO, at this point, just to make it=20= >>> "less=20 >>>>> cumbersome" than putting (a) ULA address(es) on the loopback=20 >>> interface=20 >>>>> strikes me as not having much value. >>>>>=20 >>=20 >> You don't seem to be placing any value convenience. Does your car = have an automatic transmission? Do you have a dishwasher? Do you go to = restaurants? All of those things only exist because humans place value = on the convenience of not manually changing gears, not manually washing = dishes, and not cooking at home when we could. Why have to do something = manually when a computer could do it automatically for you? >>=20 >=20 > I place tremendous value on convenience. My car does not have a = traditional automatic transmission, my car has an ECVT transmission. If = I were buying a car, I would actually prefer a manual transmission = because I prefer the greater control flexibility and shifting precision = afforded by a manual transmission. >=20 > Yes, I go to restaurants. >=20 > There are many equally automatic solutions to your problem already = available without involving the entire body of protocol developers and = the IETF in the process. >=20 > Owen >=20 >>>>> Owen >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Mark. >>>>>>=20 >>>>>>=20 >>>>>>> Doug >>>>>>>=20 >>>>>>>=20 >>>>>>> On 02/11/2013 01:37 PM, David Farmer wrote: >>>>>>>> On 2/11/13 14:28 , Owen DeLong wrote: >>>>>>>>> Perhaps I'm not very bright, but is there any=20 >>> reason ULA=20 >>>>>>> couldn't be >>>>>>>>> used on the LO interface to >>>>>>>>> satisfy this corner case? >>>>>>>>=20 >>>>>>>> The Draft does cover why ULA is thought to not be a=20 >>> sufficient=20 >>>>> solution, >>>>>>>> do you disagree with the reasoning in the draft? >>>>>>>>=20 >>>>>>>> from Section 1; >>>>>>>>=20 >>>>>>>> A Unique Local IPv6 Unicast Address (ULA) prefix=20 >>> [RFC4193]=20 >>>>> could be >>>>>>>> used to increase the number of addresses available on=20 >>> the=20 >>>>> local host. >>>>>>>> However this prefix would need to be manually=20 >>> generated and >>>>>>>> configured at least once by a system administrator or=20 >>>=20 >>>>> operator. >>>>>>>> Without additonal configuration, traffic towards=20 >>> addresses not >>>>>>>> assigned to the local host would not be prevented=20 >>> from leaving=20 >>>>> the >>>>>>>> host, and access may not be limited to the local=20 >>> host. A ULA=20 >>>>> prefix >>>>>>>> would not be well known, and would not be convenient=20 >>> to=20 >>>>> remember and >>>>>>>> type without violating the randomness requirements of=20 >>> the=20 >>>>> Global ID >>>>>>>> component of a ULA prefix. >>>>>>>>=20 >>>>>>>>> Owen >>>>>>>>>=20 >>>>>>>>> On Feb 11, 2013, at 12:20 , Mark Smith=20 >>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> Here is a new version of my IPv6 larger loopback=20 >>> prefix=20 >>>>> draft. >>>>>>>>>> Changes since the previous version: >>>>>>>>>>=20 >>>>>>>>>> o default address selection precedence and label=20 >>> values >>>>>>>>>> o comment about other IPv4 in IPv6 address forms >>>>>>>>>>=20 >>>>>>>>>> o more clarifications >>>>>>>>>>=20 >>>>>>>>>> o grammar corrections >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> My thanks to Bill Atwood, Matts Kallioniemi and=20 >>> Tina Tsou=20 >>>>> for their >>>>>>>>>> review and comments on this revision. >>>>>>>>>>=20 >>>>>>>>>> Further review and comments would be most=20 >>> appreciated. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Mark. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> v6ops mailing list >>>>>>> v6ops@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>=20 >>>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_50EB6A61-EFBC-4244-9396-503986386E84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Under IPv4, the 127/8 loopback prefix = [RFC1122] provides many
   addresses that can be used to run =
multiple instances of an
   application on the same port, while also limiting access to the local
   host.

RFC1122 provides that 127/8 cannot = appear outside of a host. It does not require that the host process all = addresses within 127/8 as you = describe.

2.
Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a
   single address.  Multiple application instances using the same port,
   bound to different loopback addresses, is not possible.

Is not true. You can configure = additional addresses on to the loopback interface as desired and use = them just as you would additional addresses from the 127/8 address = range. Since RFC1122 does not require that the host treat all these = addresses identically as you assume, there is no difference between the = current standards in IPv6 and the current standards in IPv4 except that = IPv4 sets aside a dedicated 16.7 million host addresses for this purpose = (of which only one is utilized in most cases) and IPv6 sets  aside = 1. However, you are free to assign any GUA or ULA prefix to the IPv6 = loopback and use it in the same manner as you are currently using the = other 127/8 addresses.

3.
 A Unique Local IPv6 =
Unicast Address (ULA) prefix [RFC4193] could be
   used to increase the number of addresses available on the local host.
   However this prefix would need to be manually generated and
   configured at least once by a system administrator or operator.
   Without additonal configuration, traffic towards addresses not
   assigned to the local host would not be prevented from leaving the
   host, and access may not be limited to the local host.  A ULA prefix
   would not be well known, and would not be convenient to remember and
   type without violating the randomness requirements of the Global ID
   component of a ULA prefix.

Since the = communication of this prefix in this case would not be expected to = extend beyond the host, the
only requirement is that the ULA = prefix chosen not conflict with one that the host is expected to need to = reach outside of the host. As such, fd00::/48 is a perfectly viable = candidate in the vast majority of cases as it is very unlikely to = conflict with a randomly chosen routable prefix that follows the = standards in RFC4193.

The Global ID component = of  a ULA prefix is intended to avoid conflicts in the results of = M&A, etc. Since this would be host-local addressing and not even = have site-scope, use of a known non-conflicting ULA address is perfectly = feasible. fd00::/48 is very unlikely to conflict (1 in 2^40 or < = 0.000,000,000,1% or  <1 in = 1e12).

4.




RFC4038].

   Giving up the requirement of covering the existing loopback prefix,
   the proposed larger loopback prefix is:


So why not simply =
delete this from the requirements list as you've failed to
provide any =
justification for said requirement anyway.




Smith         =
           Expires August 15, 2013                [Page 4]

 
Allocating a /32 prefix for the loopback =
function may seem excessive,
   as a /48 length prefix would satisfy the larger loopback prefix
   requirements.  However, within the parent 0000::/8 special purpose
   prefix, there are approximately 16 million /32 prefixes, so a single
   /32 for the larger loopback prefix is easily afforded.  A /32 larger
   loopback prefix will satisfy all current and likely future uses of
   the loopback function.

Allocating a = /32 is absurdly excessive and just because we can does not strike me as = anything remotely resembling an argument that we = should.


 Consistent with the IPv6 =
addressing model [RFC4291], =
each address
   within the larger loopback prefix is associated with one of the
   node's interfaces, although not necessarily the same interface for
   all addresses.  This means that the node acts as though all addresses
   within the larger loopback prefix have been configured on one or more
   interfaces.  Applications will accept packets destined to any of the
   larger loopback prefix addresses, unless the application is bound to
   specific larger loopback addresses.  Typically the addresses will be
   logically assigned to one or more virtual "loopback" interfaces,
   which locally returns or loops outgoing packets back to the same node
   that originated the =
packets.



I believe you have misread and conflated RFC4291 and = RFC1122 with regards to how loopback
addresses = function.

Unless I am mistaken, there is no = requirement in RFC1122 that a node answer all addresses within = 127/8.

Smith         =
           Expires August 15, 2013                [Page 5]

This would, indeed, = be new functionality. I am not convinced of any value to having that = functionality and it is radically different from any required = functionality in IPv4 today. In IPv4, hosts which support multiple = loopbacks have no default address or range on the subsequent loopback = interfaces.

If you cannot justify a need for = this functionality, I see no point in advancing it as a = standard.

It should be possible for an operator to =
remove these automatically
   configured loopback addresses.  It should also be possible for an
   operator to configure further loopback addresses from within the
   assigned /64, or addresses from other parts of the larger loopback
   prefix, including other /64s assigned to other loopback interfaces.
   Other addresses within the assigned /64(s) would continue to be
   logically assigned to the subsequent loopback interface.
   Configuration of addresses is for operational visibility and
   convenience, and does not change the behaviour of non-visible
   logically assigned addresses.

If = you're going to do this, then I would argue that it "must" be possible = for an operator to remove=85

The rest of what = you suggest strikes me as being a kernel routing hairball of = unnecessarily large
proportion and likely to engender more = bugs than = functionality.

------

Th= is covers the first 6 pages (approximately half of the draft). I'm not = going to take the time to write up the problems in the rest of the draft = at this point because the above are, IMHO, more than sufficient reason = to oppose = adoption.

Owen

On Feb = 12, 2013, at 4:18 PM, Owen DeLong <owen@delong.com> wrote:


On Feb = 12, 2013, at 12:33 PM, Mark Smith <markzzzsmith@yahoo.com.au>= ; wrote:





----- Original = Message -----
From: Owen DeLong <owen@delong.com>
To: Mark = Smith <markzzzsmith@yahoo.com.au>= ;
Cc: Doug Barton <dougb@dougbarton.us>; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: = Wednesday, 13 February 2013 6:59 AM
Subject: Re: [v6ops] New Version = Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt


?? I don't see how it gets = easier to remember than fd00::/8

The random bit is = the hard bit to remember and type. I don't think
you're = thinking enough about how it is to use, you're only thinking
about = how hard it is to configure. The time and effort to configure something = is
usually minimal compared to the amount of time and effort spent = while it is
being used.


Nothing requires you to use random = for this purpose. Use fd00::/64 for all
anyone = cares.


RFC4193 does. It's not a ULA if it = doesn't, it's been made a site-local. See RFC3879 for the problems with = them and your non-random ULA.


Which is = irrelevant to the loopback scenario you have = described=85


and = you can use

anything you = want inside of that to provide a /64 for your development =
purpose.

What's more cumbersome about = picking something (even fd00::/64, if
you = want)

No, that's bad, as it is a ULA = prefix which doesn't have a random
component. Add the = random component (if you aren't lazy), and it then
becomes hard to = remember and type.


Why = is it bad that it doesn't have a random component? If it's in a =
development test lab, it's not like it's at risk of corporate merger =
conflicts, etc.


See slide 26.

http://www.us= ers.on.net/~markachy/resi_ipv6_cpe.pdf


Which = does not apply to use on a loopback interface.


for development than having some = other prefix you have to configure =
assigned by

the = IETF.

I'm starting to wonder if you've actually read = the draft. The
intention is that it is that the larger = loopback prefix automatically configured
at system initialisation, = as ::1/128 and 127/8 currently are. There is a whole
section on = automatic address assignment and configuration.

127/8 isn't = auto-assigned. 127.0.0.1/8 is.


That's = incorrect.

RFC1122, "Requirements for Internet Hosts -- = Communication Layers", specifically the <any> in

"(g) { = 127, <any> }
Internal host loopback address.  Addresses of = this form MUST NOT appear outside a host."


Yes, = it requires that you not have addresses within 127.0.0.0/8 appear = outside of the host. It does
not require the host to answer or auto = configure all of the 127.0.0.0/8 addresses on its loopback
interface = and, indeed, most hosts do NOT auto configure other than = 127.0.0.1.




Sorry, but I just don't get it.



This = proposal also takes the opportunity to introduce IPv4-like =
handling of
loopback IPv6 packets so that = future functions similar to the use in =
RFC4379
have a native IPv6 address space = to use, rather than using 127/8 within
an = IPv6
prefix.

In my (admittedly limited) testing, putting = a /64 of ULA on the
loopback =
interface did = just that, so I'm not sure what it is that you feel =
is
missing.


All addresses within = 127/8 are valid and available on the host, where as =
with your ULA, only 1 is.

e.g.


[root@opy mark]# ip addr show dev = lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state = UNKNOWN
    link/loopback 00:00:00:00:00:00 brd = 00:00:00:00:00:00
    inet 127.0.0.1/8 scope = host lo
    inet6 fd00:db8::1/64 scope global =
       valid_lft forever = preferred_lft forever
    inet6 1::1/64 scope = global
       valid_lft forever = preferred_lft forever
    inet6 ::1/128 scope = host
       valid_lft forever = preferred_lft forever

[root@opy mark]# ping -c 1 = 127.1.2.3
PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.
64 = bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 ms

--- = 127.1.2.3 ping statistics ---
1 packets transmitted, 1 received, 0% = packet loss, time 0ms
rtt min/avg/max/mdev =3D = 0.053/0.053/0.053/0.000 ms
[root@opy mark]# =


Interesting=85 I get this behavior on = MacOS.

[tc01-dhcp153:~] owen% ifconfig lo0
lo0: = flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
=    options=3D3<RXCSUM,TXCSUM>
=    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
=    inet 127.0.0.1 netmask 0xff000000
=    inet6 ::1 prefixlen 128

[tc01-dhcp153:~] owen% = ping 127.1.2.3
PING 127.1.2.3 (127.1.2.3): 56 data bytes
Request = timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request = timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- = 127.1.2.3 ping statistics ---
5 packets transmitted, 0 packets = received, 100.0% packet loss


So MacOS isn't = compliant with RFC1122.


How do you figure that? = You'll need to be more specific.


Admittedly, Linux does = this:

owen.delong.com:owen /home4/owen (22) % ifconfig lo
lo =        Link encap:Local Loopback =  
         inet = addr:127.0.0.1  Mask:255.0.0.0
=          inet6 addr: = ::1/128 Scope:Host
=          UP LOOPBACK = RUNNING  MTU:16436  Metric:1
=          RX = packets:45816328 errors:0 dropped:0 overruns:0 frame:0
=          TX = packets:45816328 errors:0 dropped:0 overruns:0 carrier:0
=          collisions:0 = txqueuelen:0
=          RX bytes:578712867 = (551.9 MiB)  TX bytes:578712867 (551.9 = MiB)

owen.delong.com:owen /home4/owen (23) % ping = 127.1.2.3
PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.
64 = bytes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 time=3D0.043 ms
64 bytes = from 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0.032 ms
64 bytes from = 127.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 ms
^C
--- 127.1.2.3 = ping statistics ---
3 packets transmitted, 3 received, 0% packet = loss, time 2000ms
rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 = ms
owen.delong.com:owen /home4/owen (24) % =



[root@opy mark]# ping6 -c 1 = fd00:db8::2

connect: Network is unreachable
[root@opy = mark]#

[mark@opy ~]$ ssh 127.1.2.3
The authenticity of host = '127.1.2.3 (127.1.2.3)' can't be =
established.

[mark@opy = ~]$ ssh -6 fd00:db8::2
ssh: connect to host fd00:db8::2 port 22: = Network is unreachable
[mark@opy ~]$


=46rom = what I can see, this seems to depend on a pathology not universally =
available even in IPv4.

Another = test you should do to measure the usefulness of this proposal is =
see how long it takes and your opinion afterwards of = how hard or easy it is to
type or cut and paste "fd00:db8::1" vs = "1::1" a reasonable
number of times e.g. 6 times.


I'm fine with it. If you're doing it = more than 6 times, that's what
DNS is = for.


That's an option, for applications that use = DNS to resolve addresses. There are applications that need to deal with = addresses directly, such as mine, due to their nature and = purpose.

Then use a configuration file or whatever. = There are lots of alternatives to repeatedly typing in = addresses.
(command-line aliases come to mind as an = example).



Using a ULA doesn't really = work at all. It only adds another address to
the host, = rather than many. A properly formed ULA is hard to type and remember. =
It's far less user friendly than the short larger loopback prefix = I'm
proposing. This is based on my experience, as I've used a ULA = for the
purpose of trying to increase the number of loopback IPv6 = addresses.


The same is = true with loopback except on Linux as near as I can = tell.


Windows 7 also behaves this way, as it = complies with RFC1122.


Nothing I found in RFC = 1122 requires this, so if you think something does, you'll
need to = point it out.

I know for a fact that several Cisco switches did = not. For example, they used to use
127.0.0.<slot number> as a = convenient hack for connections across the backplane
to the IP stack = running on IP-aware blades such as RSMs.



Note, = I don't know the answer, but I'm leaning heavily =
towards, =

"no."

Primarily because = we're asking people to deploy this =
protocol for =
real-world scenarios, and we = already have a pretty wide =
divergence in =
the latest state of the = standards vs. the oldest working =
deployed base. =

Widening that gap should only be = done for truly critical =
changes, and =
I'm not sure you've made your = case sufficiently.

Put more simply, at some point we have to stop = tinkering with =
the plane =

while it's in the = air.


So I think the implication of that analogy = is that deploying this
enhancement will somehow = interrupt the existing operation of IPv6
implementations ("the = plane") causing them to fail
("fall out of =
the sky"). I = don't see how that will be the case. Deploying a =
new
loopback prefix would leverage = many of the existing address
configuration = and
loopback = related functions of existing IPv6 implementations. It is not =
much more
than a larger version of = ::1/128.

The implication is that you are requesting to once again = obsolete all
existing
implementations in favor of = requiring deploying another fundamentally =
changed
IPv6 = stack.

Can you define the threshold of = "fundamentally changed" for me?


Requiring a = modification to every existing IPv6 stack in the wild which could = be
incorporated into software dependencies which would render = existing stacks
unexpectedly
obsolete.

I don't consider this to be a fundamental change. It is = adding another
loopback prefix, which operates the same = as the existing one, just with a
shorter prefix length. It is adding = values to the source and destination address
selection policy, which = is already possible to do because it's been designed
that way. I'm = quite confident that it is going to be no more than 10 lines,
and = probably closer to 5 additional lines of code in a stack for a host =
implementation that only supports a single loopback interface. = That's code
change size closer to the size of bug fixes than = additional functionality.


So you want to force everyone to = update their IPv6 stack on every host, router,
switch, etc. just so = you can save some typing?


The IETF (and I) can't = force anything. If it's useful, it'll be = implemented.


IMHO, it's not all that useful and = making it a stack requirement would lead to one of two bad = situations:

1. Development resources would be = taken away from tasks that matter.
or
2. = Increasing divergence between the implemented stacks and the = documented standards.


You're doing a very good job cementing my opposition = here.


You seem to like doing things the hard = way. My view is computers should do things automatically for people so = that people can get on with more valuable things. Developers should be = cutting code instead of setting up development environments, or waiting = for system administrators to set up the development environment for = them.


Actually, I do not. However, I do not = believe in using the entire IP stack development community as a = workforce to save me a little bit of typing which, as near as I can tell = is all that this proposal would accomplish.

The functionality you = seek is available using ULA. The issues you cite with ULA would not = apply to loopback usage. The functionality that you attribute to RFC = 1122 isn't (as near as I can tell) actually codified into RFC 1122 (I = don't see how requiring that an address range not appear outside of a = host requires that host to accept all packets to any address in said = range, which is what you are claiming).

My = definition of a fundamental change would be to do something like change =
the change the size of the IPv6 address, or reorder the = fields in the IPv6
header.


That would be a drastic change, = indeed. This is less drastic, but it would make
current IPv6 stacks = incompatible with the protocol definition.


I = don't get this. 1::/32 is not currently used for anything, so using it = is not going to make it incompatible with anything. Using other prefixes = for purposes that they weren't designed for, such as a ULA as a = loopback, has far greater risk of creating incompatibility. =

If you add this as a required stack feature, stacks = which don't implement the feature are no longer = compliant.


The = question is whether there is enough value in the change to
justify = such a decision and IMHO, at this point, just to make it =
"less
cumbersome" than putting (a) ULA = address(es) on the loopback
interface =
strikes me as = not having much = value.


You don't seem = to be placing any value convenience. Does your car have an automatic = transmission? Do you have a dishwasher? Do you go to restaurants? All of = those things only exist because humans place value on the convenience of = not manually changing gears, not manually washing dishes, and not = cooking at home when we could. Why have to do something manually when a = computer could do it automatically for you?


I = place tremendous value on convenience. My car does not have a = traditional automatic transmission, my car has an ECVT transmission. If = I were buying a car, I would actually prefer a manual transmission = because I prefer the greater control flexibility and shifting precision = afforded by a manual transmission.

Yes, I go to = restaurants.

There are many equally automatic solutions to your = problem already available without involving the entire body of protocol = developers and the IETF in the process.

Owen

Owen



Regards,
Mark.


Doug


On 02/11/2013 01:37 PM, David Farmer = wrote:
On 2/11/13 14:28 , Owen DeLong = wrote:
Perhaps I'm not very bright, but is = there any =
reason ULA
couldn't= be
used on the = LO interface to
satisfy this corner case?

The = Draft does cover why ULA is thought to not be a =
suffi= cient
solution,
do you disagree with the = reasoning in the draft?

from Section 1;

=       A Unique Local IPv6 Unicast Address = (ULA) prefix =
[RFC4= 193]
could = be
      used to increase the = number of addresses available on =
the =
local = host.
      However this prefix = would need to be manually =
gener= ated and
=       configured at least once by a system = administrator or =

<= blockquote type=3D"cite">
operator.
=       Without additonal configuration, = traffic towards =
addre= sses not
=       assigned to the local host would not = be prevented =
from = leaving
the
=       host, and access may not be limited = to the local =
host.=  A ULA
prefix
=       would not be well known, and would = not be convenient =
to =
remember = and
      type without = violating the randomness requirements of =
the =
Global = ID
      component of a ULA = prefix.

Owen

On Feb 11, 2013, at = 12:20 , Mark Smith
<markzzzsmith@yahoo.com.au>= ; wrote:

Hi,

Here is a new = version of my IPv6 larger loopback =
prefix
draft.
Changes since the previous = version:

o  default address selection precedence and label =
values
o  comment about other IPv4 = in IPv6 address forms

o  more clarifications

o =  grammar corrections


My thanks to Bill Atwood, Matts = Kallioniemi and =
Tina Tsou
for their
review and comments on this = revision.

Further review and comments would be most =
appreciated.

Thanks,
Mark.



_______________________________________________
v6op= s 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


<= /blockquote>

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

= --Apple-Mail=_50EB6A61-EFBC-4244-9396-503986386E84-- From dougb@dougbarton.us Tue Feb 12 23:00: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 9D27121F8AD4 for ; Tue, 12 Feb 2013 23:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-1.881, BAYES_50=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=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 zYbwHrDciShd for ; Tue, 12 Feb 2013 23:00:07 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69E9121F8AC8 for ; Tue, 12 Feb 2013 23:00:04 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:9e1:ea6b:840:cf33] (unknown [IPv6:2001:470:d:5e7:9e1:ea6b:840:cf33]) by dougbarton.us (Postfix) with ESMTPSA id 278F022B1C for ; Wed, 13 Feb 2013 07:00:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1360738804; bh=mR+iNGedkiv7ObZYg/uyA49Wv9fyS5mg5oEVDoTLz3w=; h=Date:From:To:Subject:References:In-Reply-To; b=oRNhkrc6ZmybNnB3BSf2DH0p8xv4ZpzjREDcXVCcGwEq+kyniRbuXBNampR7hTxO3 qvLfqpnZ6JOQr85RGkshnIplrEcDPB/rS3FSY2xhih5MWq1CUHJXlol87b9HTisuFi iEyE3XIxL/6fIV2ccXs68dz8pLFWMNMc/TzG6GbU= Message-ID: <511B39F3.6080002@dougbarton.us> Date: Tue, 12 Feb 2013 23:00:03 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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, 13 Feb 2013 07:00:09 -0000 FWIW, I had also read the draft, and my analysis is identical to Owen's, albeit he stated it below much better, and much more thoroughly than I would have. I'm opposed to the group adopting the draft, and opposed to its publication in any form. Doug On 02/12/2013 05:46 PM, Owen DeLong wrote: > I had actually read it, but, since you insist… > > > 1. > Under IPv4, the 127/8 loopback prefix [RFC1122 > ] provides many > > addresses that can be used to run multiple instances of an > application on the same port, while also limiting access to the local > host. > > > RFC1122 provides that 127/8 cannot appear outside of a host. It does not > require that the host process all addresses within 127/8 as you describe. > > 2. > > Under IPv6, the ::1/128 loopback prefix [RFC4291 ] only provides a > single address. Multiple application instances using the same port, > bound to different loopback addresses, is not possible. > > > Is not true. You can configure additional addresses on to the loopback > interface as desired and use them just as you would additional addresses > from the 127/8 address range. Since RFC1122 does not require that the > host treat all these addresses identically as you assume, there is no > difference between the current standards in IPv6 and the current > standards in IPv4 except that IPv4 sets aside a dedicated 16.7 million > host addresses for this purpose (of which only one is utilized in most > cases) and IPv6 sets aside 1. However, you are free to assign any GUA > or ULA prefix to the IPv6 loopback and use it in the same manner as you > are currently using the other 127/8 addresses. > > 3. > > A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193 ] could be > used to increase the number of addresses available on the local host. > However this prefix would need to be manually generated and > configured at least once by a system administrator or operator. > Without additonal configuration, traffic towards addresses not > assigned to the local host would not be prevented from leaving the > host, and access may not be limited to the local host. A ULA prefix > would not be well known, and would not be convenient to remember and > type without violating the randomness requirements of the Global ID > component of a ULA prefix. > > > Since the communication of this prefix in this case would not be > expected to extend beyond the host, the > only requirement is that the ULA prefix chosen not conflict with one > that the host is expected to need to reach outside of the host. As such, > fd00::/48 is a perfectly viable candidate in the vast majority of cases > as it is very unlikely to conflict with a randomly chosen routable > prefix that follows the standards in RFC4193. > > The Global ID component of a ULA prefix is intended to avoid conflicts > in the results of M&A, etc. Since this would be host-local addressing > and not even have site-scope, use of a known non-conflicting ULA address > is perfectly feasible. fd00::/48 is very unlikely to conflict (1 in 2^40 > or < 0.000,000,000,1% or <1 in 1e12). > > 4. > > > 2 > . > Larger Loopback Prefix Requirements > > > > A new larger loopback prefix should attempt to satisfy all of the > following requirements. It should: > > o be a well known prefix, > > o be within an existing special purpose prefix, such as 0000::/8 > (the parent prefix of the current IPv6 loopback address), > > o be easy for a human to remember, > > o be easy for a human to type, > > o cover the existing loopback prefix, > > o support 64 bit Interface Identifiers, > > o provide a large number of /64 subnets. > > > I believe that fd00::/48 could do what you describe: > > 1.I question the need for it to be well known. As long as it is well > known within > the scope of the intended use, I think that suffices for the use cases > you have > described. > > fd00::/48 could easily meet that test. > > 2.fd00::/48 is within the existing ULA special purpose prefix. > 3.fd00::/48 is very easy for a human to remember. > 4.fd00::/48 is very easy for a human to type. > 5.Please justify your claim that it should encompass the existing > loopback address. > 6.fd00::/48 supports 64 bit IIDs. > 7.fd00::/48 provides 65,536 /64 subnets. Is there some reason you think > this is insufficient? > This is a total of 4 billion times 16.7 million times as many host > addresses as were provided > in the IPv4 loopback. > > It is 1/256th as many networks as IPv4 provided loopback hosts. > > 5. > > > 3 > . > Proposed Larger Loopback Prefix > > > > Ideally, the prefix length of ::1/128 could be shortened, resulting > in a larger loopback prefix such as ::/48. However, if the existing > loopback prefix length is shortened enough to satisfy all of the > larger loopback prefix requirements, it would then cover the IPv4 > Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use > described in [RFC4038 ]. > > Giving up the requirement of covering the existing loopback prefix, > the proposed larger loopback prefix is: > > > So why not simply delete this from the requirements list as you've failed to > > provide any justification for said requirement anyway. > > > > > > Smith Expires August 15, 2013 [Page 4] > > > Internet-Draft A Larger IPv6 Loopback Prefix February 2013 > > > 0001:0000:0000:0000:0000:0000:0000:0000/32 > > or concisely, > > 1::/32 > > This prefix satisfies all remaining larger loopback prefix > requirements. > > > I think this is a terrible choice of location. It pretty much maximizes > the fragmentation damage that can be done by the choice of prefix. > :1::/32 would at least be the first /32 available. As I've stated, a > locally chosen address such as fd00::/48 (or whatever selection of > chosen ULA space meets local requirements) is equally viable IMHO. > > 6. > > Allocating a /32 prefix for the loopback function may seem excessive, > as a /48 length prefix would satisfy the larger loopback prefix > requirements. However, within the parent 0000::/8 special purpose > prefix, there are approximately 16 million /32 prefixes, so a single > /32 for the larger loopback prefix is easily afforded. A /32 larger > loopback prefix will satisfy all current and likely future uses of > the loopback function. > > > Allocating a /32 is absurdly excessive and just because we can does not > strike me as anything remotely resembling an argument that we should. > > > 4 > . > Address Assignment and Configuration > > > > Consistent with the IPv6 addressing model [RFC4291 ], each address > within the larger loopback prefix is associated with one of the > node's interfaces, although not necessarily the same interface for > all addresses. This means that the node acts as though all addresses > within the larger loopback prefix have been configured on one or more > interfaces. Applications will accept packets destined to any of the > larger loopback prefix addresses, unless the application is bound to > specific larger loopback addresses. Typically the addresses will be > logically assigned to one or more virtual "loopback" interfaces, > which locally returns or loops outgoing packets back to the same node > that originated the packets. > > > > > I believe you have misread and conflated RFC4291 and RFC1122 with > regards to how loopback > addresses function. > > Unless I am mistaken, there is no requirement in RFC1122 that a node > answer all addresses within 127/8. > > Some nodes may support more than one loopback interface. These > subsequent loopback interfaces, when initialised, should be assigned > > > > Smith Expires August 15, 2013 [Page 5] > > > Internet-Draft A Larger IPv6 Loopback Prefix February 2013 > > > a larger loopback /64 prefix locally unique within the node. All > addresses within the assigned /64 are logically assigned to the > interface. Additionally, the ":1" address for the subnet should be > configured on the loopback interface, making it visible to a system > operator or user. > > > This would, indeed, be new functionality. I am not convinced of any > value to having that functionality and it is radically different from > any required functionality in IPv4 today. In IPv4, hosts which support > multiple loopbacks have no default address or range on the subsequent > loopback interfaces. > > If you cannot justify a need for this functionality, I see no point in > advancing it as a standard. > > It should be possible for an operator to remove these automatically > configured loopback addresses. It should also be possible for an > operator to configure further loopback addresses from within the > assigned /64, or addresses from other parts of the larger loopback > prefix, including other /64s assigned to other loopback interfaces. > Other addresses within the assigned /64(s) would continue to be > logically assigned to the subsequent loopback interface. > Configuration of addresses is for operational visibility and > convenience, and does not change the behaviour of non-visible > logically assigned addresses. > > > If you're going to do this, then I would argue that it "must" be > possible for an operator to remove… > > The rest of what you suggest strikes me as being a kernel routing > hairball of unnecessarily large > proportion and likely to engender more bugs than functionality. > > ------ > > This covers the first 6 pages (approximately half of the draft). I'm not > going to take the time to write up the problems in the rest of the draft > at this point because the above are, IMHO, more than sufficient reason > to oppose adoption. > > Owen > > On Feb 12, 2013, at 4:18 PM, Owen DeLong > wrote: > >> >> On Feb 12, 2013, at 12:33 PM, Mark Smith > > wrote: >> >>> >>> >>> >>> >>> ----- Original Message ----- >>>> From: Owen DeLong > >>>> To: Mark Smith >>> > >>>> Cc: Doug Barton >; >>>> "v6ops@ietf.org " >>> > >>>> Sent: Wednesday, 13 February 2013 6:59 AM >>>> Subject: Re: [v6ops] New Version Notification for >>>> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>>> >>>>>> >>>>>> ?? I don't see how it gets easier to remember than fd00::/8 >>>>> >>>>> The random bit is the hard bit to remember and type. I don't think >>>> you're thinking enough about how it is to use, you're only thinking >>>> about how hard it is to configure. The time and effort to configure >>>> something is >>>> usually minimal compared to the amount of time and effort spent >>>> while it is >>>> being used. >>>>> >>>> >>>> Nothing requires you to use random for this purpose. Use fd00::/64 >>>> for all >>>> anyone cares. >>>> >>> >>> RFC4193 does. It's not a ULA if it doesn't, it's been made a >>> site-local. See RFC3879 for the problems with them and your >>> non-random ULA. >>> >> >> Which is irrelevant to the loopback scenario you have described… >> >>> >>>>>> and you can use >>>>> >>>>>> anything you want inside of that to provide a /64 for your >>>>>> development >>>> purpose. >>>>>> >>>>>> What's more cumbersome about picking something (even fd00::/64, if >>>> you want) >>>>> >>>>> No, that's bad, as it is a ULA prefix which doesn't have a random >>>> component. Add the random component (if you aren't lazy), and it then >>>> becomes hard to remember and type. >>>>> >>>> >>>> Why is it bad that it doesn't have a random component? If it's in a >>>> development test lab, it's not like it's at risk of corporate merger >>>> conflicts, etc. >>>> >>> >>> See slide 26. >>> >>> http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf >>> >> >> Which does not apply to use on a loopback interface. >> >>> >>>>>> for development than having some other prefix you have to configure >>>> assigned by >>>>> >>>>>> the IETF. >>>>> >>>>> I'm starting to wonder if you've actually read the draft. The >>>> intention is that it is that the larger loopback prefix >>>> automatically configured >>>> at system initialisation, as ::1/128 and 127/8 currently are. There >>>> is a whole >>>> section on automatic address assignment and configuration. >>>> >>>> 127/8 isn't auto-assigned. 127.0.0.1/8 is. >>>> >>> >>> That's incorrect. >>> >>> RFC1122, "Requirements for Internet Hosts -- Communication Layers", >>> specifically the in >>> >>> "(g) { 127, } >>> Internal host loopback address. Addresses of this form MUST NOT >>> appear outside a host." >>> >> >> Yes, it requires that you not have addresses within 127.0.0.0/8 appear >> outside of the host. It does >> not require the host to answer or auto configure all of the >> 127.0.0.0/8 addresses on its loopback >> interface and, indeed, most hosts do NOT auto configure other than >> 127.0.0.1. >> >>>>> >>> >>>>>> >>>>>> Sorry, but I just don't get it. >>>>>> >>>>>>> >>>>>> >>>>>>> This proposal also takes the opportunity to introduce IPv4-like >>>> handling of >>>>>> loopback IPv6 packets so that future functions similar to the use in >>>> RFC4379 >>>>>> have a native IPv6 address space to use, rather than using 127/8 >>>>>> within >>>> an IPv6 >>>>>> prefix. >>>>>> >>>>>> In my (admittedly limited) testing, putting a /64 of ULA on the >>>> loopback >>>>>> interface did just that, so I'm not sure what it is that you feel >>>> is >>>>>> missing. >>>>>> >>>>> >>>>> All addresses within 127/8 are valid and available on the host, >>>>> where as >>>> with your ULA, only 1 is. >>>>> >>>>> e.g. >>>>> >>>>> >>>>> [root@opy mark]# ip addr show dev lo >>>>> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN >>>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >>>>> inet 127.0.0.1/8 scope host lo >>>>> inet6 fd00:db8::1/64 scope global >>>>> valid_lft forever preferred_lft forever >>>>> inet6 1::1/64 scope global >>>>> valid_lft forever preferred_lft forever >>>>> inet6 ::1/128 scope host >>>>> valid_lft forever preferred_lft forever >>>>> >>>>> [root@opy mark]# ping -c 1 127.1.2.3 >>>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>>>> 64 bytes from 127.1.2.3: icmp_req=1 ttl=64 time=0.053 ms >>>>> >>>>> --- 127.1.2.3 ping statistics --- >>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms >>>>> rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms >>>>> [root@opy mark]# >>>>> >>>> >>>> Interesting… I get this behavior on MacOS. >>>> >>>> [tc01-dhcp153:~] owen% ifconfig lo0 >>>> lo0: flags=8049 mtu 16384 >>>> options=3 >>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >>>> inet 127.0.0.1 netmask 0xff000000 >>>> inet6 ::1 prefixlen 128 >>>> >>>> [tc01-dhcp153:~] owen% ping 127.1.2.3 >>>> PING 127.1.2.3 (127.1.2.3): 56 data bytes >>>> Request timeout for icmp_seq 0 >>>> Request timeout for icmp_seq 1 >>>> Request timeout for icmp_seq 2 >>>> Request timeout for icmp_seq 3 >>>> ^C >>>> --- 127.1.2.3 ping statistics --- >>>> 5 packets transmitted, 0 packets received, 100.0% packet loss >>>> >>> >>> So MacOS isn't compliant with RFC1122. >>> >> >> How do you figure that? You'll need to be more specific. >> >>> >>>> Admittedly, Linux does this: >>>> >>>> owen.delong.com:owen /home4/owen (22) % ifconfig lo >>>> lo Link encap:Local Loopback >>>> inet addr:127.0.0.1 Mask:255.0.0.0 >>>> inet6 addr: ::1/128 Scope:Host >>>> UP LOOPBACK RUNNING MTU:16436 Metric:1 >>>> RX packets:45816328 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:45816328 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:0 >>>> RX bytes:578712867 (551.9 MiB) TX bytes:578712867 (551.9 MiB) >>>> >>>> owen.delong.com:owen /home4/owen (23) % ping 127.1.2.3 >>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>>> 64 bytes from 127.1.2.3: icmp_seq=1 ttl=64 time=0.043 ms >>>> 64 bytes from 127.1.2.3: icmp_seq=2 ttl=64 time=0.032 ms >>>> 64 bytes from 127.1.2.3: icmp_seq=3 ttl=64 time=0.019 ms >>>> ^C >>>> --- 127.1.2.3 ping statistics --- >>>> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms >>>> rtt min/avg/max/mdev = 0.019/0.031/0.043/0.010 ms >>>> owen.delong.com:owen /home4/owen (24) % >>>> >>>> >>>> >>>>> [root@opy mark]# ping6 -c 1 fd00:db8::2 >>>>> >>>>> connect: Network is unreachable >>>>> [root@opy mark]# >>>>> >>>>> [mark@opy ~]$ ssh 127.1.2.3 >>>>> The authenticity of host '127.1.2.3 (127.1.2.3)' can't be >>>> established. >>>>> >>>>> [mark@opy ~]$ ssh -6 fd00:db8::2 >>>>> ssh: connect to host fd00:db8::2 port 22: Network is unreachable >>>>> [mark@opy ~]$ >>>>> >>>> >>>> From what I can see, this seems to depend on a pathology not >>>> universally >>>> available even in IPv4. >>>> >>>>> Another test you should do to measure the usefulness of this >>>>> proposal is >>>> see how long it takes and your opinion afterwards of how hard or >>>> easy it is to >>>> type or cut and paste "fd00:db8::1" vs "1::1" a reasonable >>>> number of times e.g. 6 times. >>>>> >>>> >>>> I'm fine with it. If you're doing it more than 6 times, that's what >>>> DNS is for. >>>> >>> >>> That's an option, for applications that use DNS to resolve addresses. >>> There are applications that need to deal with addresses directly, >>> such as mine, due to their nature and purpose. >> >> Then use a configuration file or whatever. There are lots of >> alternatives to repeatedly typing in addresses. >> (command-line aliases come to mind as an example). >> >>> >>>>> >>>>> Using a ULA doesn't really work at all. It only adds another >>>>> address to >>>> the host, rather than many. A properly formed ULA is hard to type >>>> and remember. >>>> It's far less user friendly than the short larger loopback prefix I'm >>>> proposing. This is based on my experience, as I've used a ULA for the >>>> purpose of trying to increase the number of loopback IPv6 addresses. >>>>> >>>> >>>> The same is true with loopback except on Linux as near as I can tell. >>>> >>> >>> Windows 7 also behaves this way, as it complies with RFC1122. >>> >> >> Nothing I found in RFC 1122 requires this, so if you think something >> does, you'll >> need to point it out. >> >> I know for a fact that several Cisco switches did not. For example, >> they used to use >> 127.0.0. as a convenient hack for connections across the >> backplane >> to the IP stack running on IP-aware blades such as RSMs. >> >>>>>>> >>>>> >>>>>>>> Note, I don't know the answer, but I'm leaning heavily >>>> towards, >>>>>> >>>>>>>> "no." >>>>>>>> >>>>>>>> Primarily because we're asking people to deploy this >>>> protocol for >>>>>>>> real-world scenarios, and we already have a pretty wide >>>> divergence in >>>>>>>> the latest state of the standards vs. the oldest working >>>> deployed base. >>>>>> >>>>>>>> Widening that gap should only be done for truly critical >>>> changes, and >>>>>>>> I'm not sure you've made your case sufficiently. >>>>>>>> >>>>>>>> Put more simply, at some point we have to stop tinkering with >>>> the plane >>>>>> >>>>>>>> while it's in the air. >>>>>>>> >>>>>>> >>>>>>> So I think the implication of that analogy is that deploying this >>>>>> enhancement will somehow interrupt the existing operation of IPv6 >>>>>> implementations ("the plane") causing them to fail >>>> ("fall out of >>>>>> the sky"). I don't see how that will be the case. Deploying a >>>> new >>>>>> loopback prefix would leverage many of the existing address >>>> configuration and >>>>>> loopback related functions of existing IPv6 implementations. It is >>>>>> not >>>> much more >>>>>> than a larger version of ::1/128. >>>>>> >>>>>> The implication is that you are requesting to once again obsolete all >>>> existing >>>>>> implementations in favor of requiring deploying another fundamentally >>>> changed >>>>>> IPv6 stack. >>>>> >>>>> Can you define the threshold of "fundamentally changed" for me? >>>>> >>>> >>>> Requiring a modification to every existing IPv6 stack in the wild >>>> which could be >>>> incorporated into software dependencies which would render existing >>>> stacks >>>> unexpectedly >>>> obsolete. >>>> >>>>> I don't consider this to be a fundamental change. It is adding another >>>> loopback prefix, which operates the same as the existing one, just >>>> with a >>>> shorter prefix length. It is adding values to the source and >>>> destination address >>>> selection policy, which is already possible to do because it's been >>>> designed >>>> that way. I'm quite confident that it is going to be no more than 10 >>>> lines, >>>> and probably closer to 5 additional lines of code in a stack for a host >>>> implementation that only supports a single loopback interface. >>>> That's code >>>> change size closer to the size of bug fixes than additional >>>> functionality. >>>>> >>>> >>>> So you want to force everyone to update their IPv6 stack on every >>>> host, router, >>>> switch, etc. just so you can save some typing? >>>> >>> >>> The IETF (and I) can't force anything. If it's useful, it'll be >>> implemented. >>> >> >> IMHO, it's not all that useful and making it a stack requirement would >> lead to one of two bad situations: >> >> 1.Development resources would be taken away from tasks that matter. >> or >> 2.Increasing divergence between the implemented stacks and the >> documented standards. >> >> >>>> You're doing a very good job cementing my opposition here. >>>> >>> >>> You seem to like doing things the hard way. My view is computers >>> should do things automatically for people so that people can get on >>> with more valuable things. Developers should be cutting code instead >>> of setting up development environments, or waiting for system >>> administrators to set up the development environment for them. >>> >> >> Actually, I do not. However, I do not believe in using the entire IP >> stack development community as a workforce to save me a little bit of >> typing which, as near as I can tell is all that this proposal would >> accomplish. >> >> The functionality you seek is available using ULA. The issues you cite >> with ULA would not apply to loopback usage. The functionality that you >> attribute to RFC 1122 isn't (as near as I can tell) actually codified >> into RFC 1122 (I don't see how requiring that an address range not >> appear outside of a host requires that host to accept all packets to >> any address in said range, which is what you are claiming). >> >>>>> My definition of a fundamental change would be to do something like >>>>> change >>>> the change the size of the IPv6 address, or reorder the fields in >>>> the IPv6 >>>> header. >>>>> >>>> >>>> That would be a drastic change, indeed. This is less drastic, but it >>>> would make >>>> current IPv6 stacks incompatible with the protocol definition. >>>> >>> >>> I don't get this. 1::/32 is not currently used for anything, so using >>> it is not going to make it incompatible with anything. Using other >>> prefixes for purposes that they weren't designed for, such as a ULA >>> as a loopback, has far greater risk of creating incompatibility. >> >> If you add this as a required stack feature, stacks which don't >> implement the feature are no longer compliant. >> >>> >>>>>> The question is whether there is enough value in the change to >>>>>> justify such a decision and IMHO, at this point, just to make it >>>> "less >>>>>> cumbersome" than putting (a) ULA address(es) on the loopback >>>> interface >>>>>> strikes me as not having much value. >>>>>> >>> >>> You don't seem to be placing any value convenience. Does your car >>> have an automatic transmission? Do you have a dishwasher? Do you go >>> to restaurants? All of those things only exist because humans place >>> value on the convenience of not manually changing gears, not manually >>> washing dishes, and not cooking at home when we could. Why have to do >>> something manually when a computer could do it automatically for you? >>> >> >> I place tremendous value on convenience. My car does not have a >> traditional automatic transmission, my car has an ECVT transmission. >> If I were buying a car, I would actually prefer a manual transmission >> because I prefer the greater control flexibility and shifting >> precision afforded by a manual transmission. >> >> Yes, I go to restaurants. >> >> There are many equally automatic solutions to your problem already >> available without involving the entire body of protocol developers and >> the IETF in the process. >> >> Owen >> >>>>>> Owen >>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Mark. >>>>>>> >>>>>>> >>>>>>>> Doug >>>>>>>> >>>>>>>> >>>>>>>> On 02/11/2013 01:37 PM, David Farmer wrote: >>>>>>>>> On 2/11/13 14:28 , Owen DeLong wrote: >>>>>>>>>> Perhaps I'm not very bright, but is there any >>>> reason ULA >>>>>>>> couldn't be >>>>>>>>>> used on the LO interface to >>>>>>>>>> satisfy this corner case? >>>>>>>>> >>>>>>>>> The Draft does cover why ULA is thought to not be a >>>> sufficient >>>>>> solution, >>>>>>>>> do you disagree with the reasoning in the draft? >>>>>>>>> >>>>>>>>> from Section 1; >>>>>>>>> >>>>>>>>> A Unique Local IPv6 Unicast Address (ULA) prefix >>>> [RFC4193] >>>>>> could be >>>>>>>>> used to increase the number of addresses available on >>>> the >>>>>> local host. >>>>>>>>> However this prefix would need to be manually >>>> generated and >>>>>>>>> configured at least once by a system administrator or >>>> >>>>>> operator. >>>>>>>>> Without additonal configuration, traffic towards >>>> addresses not >>>>>>>>> assigned to the local host would not be prevented >>>> from leaving >>>>>> the >>>>>>>>> host, and access may not be limited to the local >>>> host. A ULA >>>>>> prefix >>>>>>>>> would not be well known, and would not be convenient >>>> to >>>>>> remember and >>>>>>>>> type without violating the randomness requirements of >>>> the >>>>>> Global ID >>>>>>>>> component of a ULA prefix. >>>>>>>>> >>>>>>>>>> Owen >>>>>>>>>> >>>>>>>>>> On Feb 11, 2013, at 12:20 , Mark Smith >>>>>>>> > >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Here is a new version of my IPv6 larger loopback >>>> prefix >>>>>> draft. >>>>>>>>>>> Changes since the previous version: >>>>>>>>>>> >>>>>>>>>>> o default address selection precedence and label >>>> values >>>>>>>>>>> o comment about other IPv4 in IPv6 address forms >>>>>>>>>>> >>>>>>>>>>> o more clarifications >>>>>>>>>>> >>>>>>>>>>> o grammar corrections >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> My thanks to Bill Atwood, Matts Kallioniemi and >>>> Tina Tsou >>>>>> for their >>>>>>>>>>> review and comments on this revision. >>>>>>>>>>> >>>>>>>>>>> Further review and comments would be most >>>> appreciated. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Mark. From markzzzsmith@yahoo.com.au Wed Feb 13 00:09: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 002B021F8A72 for ; Wed, 13 Feb 2013 00:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.468 X-Spam-Level: ** X-Spam-Status: No, score=2.468 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, SARE_RAND_1=2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJjnzw-AnNaP for ; Wed, 13 Feb 2013 00:09:53 -0800 (PST) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with SMTP id 2421C21F8A69 for ; Wed, 13 Feb 2013 00:09:53 -0800 (PST) Received: from [98.139.212.144] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 13 Feb 2013 08:09:52 -0000 Received: from [98.139.212.228] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 13 Feb 2013 08:09:52 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 13 Feb 2013 08:09:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 560750.7316.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 54542 invoked by uid 60001); 13 Feb 2013 08:09:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360742992; bh=lJdzx0I12XA7oNkMBpJaAK7eZIdd+VXN+cO+f6CotyM=; 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=6fbgdowY4cudcuBsQLnDqQXzT5GYjcLimFJ7xnQNRk0lJuOYET1PKJCTO5AUdEGAEW69zDN51em4VxuJZYGbOonRAUrNBqZuBCzld9eSQRyf579ctUmAAy3N36ISY1WA0KVe2xr0DP7UIbej9iaChs9gQZsYA4QDTtEGoANmiOg= 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=caMOoLi4b5AtQjJ3ih5cgiLrxq0U12n/AGiA6f4XQxxXEPJSY8d3PBIpFBcD5BjWi59UqoBWSehrBWrwZ+xpGLaQFUQsVLo8ddZ8Nngvnpdf9Xl4diw2bSJYcjjU8SNWokn7r0gms++hI5Uj6S4PAbriPNqfims2BgzlqMxpGe8=; X-YMail-OSG: TqbdW5cVM1kkMTLwssB7k.1s9pNA6uNdMGWE8Imbo0GgRhn 66volIGHJ1zPml3v7BL3UNhXDdyehVgjoAMDnROLYjXkGecWYMkyLGN1scSc KN78w.a4UIaelq9_rs.w9YLQTkcVgj2SqflLLGYt524D62NwKlKxYSGdrCbb 6NBt6.GUEecK5IH7lUzUTT_vzsyRu8TTgcEid.HtJZrwiUJRy8drKsmmkSEN iHWesFB8s5ce5q8pDRHDMMcqi0BQSFsV1RtjlD2UuSYgapc_I9d2Neq92JJ1 iH85N_u03UFICp7hRYt99nOZTHVWWr6YhM1olC.BnfWjavJ161mY0CvLvV3B fx7oXMInP.wsccqrXwu2NNLQa3ExLqhMPoUPQPFCwF7xVpJh1l.Ajil_L_PT ZhkkbTTpGxZRNLvgW0NE42RTp98pE3J1ZV1Osvr8As9HmZItnxtghhieQeDk WeWd1uVxv_SEmG_UXlUxWRuMF6bF_mZrPIQf8gX57gHOSose2rUn4rfEXZeW vLgod4x.ewN.1rQO3P4I9Fam_W.WrVBi86_As5GwRTzFHuO.3qKEs7jU_fKp zwRTxOpP1ROqZCHBD1eyydVyGkLJ_jfhdvv_nPQBHxmNwyeVdU7Ts0KtQKO_ 458_ZKOAd3ky03ZUA6n3FQAoGjddsrlNamXxJeIKAGtmGX6MhFhGiPgUL5ri YujTcGObEOIc84Tp0fWMkLtDhGRDgLvdtSO1.bnx6yYJhzW5h89RN1AcmCvq auSpQEYCrvArFHfTfCB6mhE.ZxB8VwSVaiyju.1bi82ZyjEPglbb4pFu0IL. wWxmw9VEAmY0jSxbM60AlI6wRGMZFSMfHC_h9ENDtvQmMcWk6X1_eBp.PJ.l 3 Received: from [121.200.231.211] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 13 Feb 2013 00:09:52 PST X-Rocket-MIMEInfo: 001.001, Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbT4KPlRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PiAKPkNjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBXZWRuZXNkYXksIDEzIEZlYnJ1YXJ5IDIwMTMgMTI6NDYgUE0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc21pdGgtdjZvcHMtbGFyZ2VyLWlwdjYtbG9vcGJhY2sBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> Message-ID: <1360742992.43052.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 13 Feb 2013 00:09:52 -0800 (PST) From: Mark Smith To: Owen DeLong In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 08:09:56 -0000 >________________________________=0A> From: Owen DeLong = =0A>To: Mark Smith =0A>Cc: "v6ops@ietf.org" =0A>Sent: Wednesday, 13 February 2013 12:46 PM=0A>Subject: Re= : [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopba= ck-prefix-03.txt=0A> =0A>=0A>I had actually read it, but, since you insist= =E2=80=A6=0A>=0A>=0A=0AI think it is an obligation of being a member of thi= s mailing list if you are going to disagree with parts of an ID publicly.= =C2=A0=0A=0A>=0A>1.=0A>Under IPv4, the 127/8 loopback prefix [RFC1122] prov= ides many=0A>addresses that can be used to run multiple instances of an app= lication on the same port, while also limiting access to the local host.=0A= >=0A>=0A>RFC1122 provides that 127/8 cannot appear outside of a host. It do= es not require that the host process all addresses within 127/8 as you desc= ribe.=0A>=0A=0AYou're right it doesn't say that. It is common convention to= do so, and has been a useful one to me and others. I will change the text = to reflect that it is a common convention.=0A=0A>=0A>2.=0A>Under IPv6, the = ::1/128 loopback prefix [RFC4291] only provides a single address.=C2=A0=C2= =A0Multiple application instances using the same port, bound to different l= oopback addresses, is not possible. =0A>=0A>=0A>Is not true. You can config= ure additional addresses on to the loopback interface as desired and use th= em just as you would additional addresses from the 127/8 address range. Sin= ce RFC1122 does not require that the host treat all these addresses identic= ally as you assume, there is no difference between the current standards in= IPv6 and the current standards in IPv4 except that IPv4 sets aside a dedic= ated 16.7 million host addresses for this purpose (of which only one is uti= lized in most cases) and IPv6 sets =C2=A0aside 1. However, you are free to = assign any GUA or ULA prefix to the IPv6 loopback and use it in the same ma= nner as you are currently using the other 127/8 addresses.=0A>=0A=0AI think= you're choosing to misread this two sentence paragraph. Normal English con= vention is that sentences subsequent to the first in a paragraph are in the= context of the topic described by the first sentence. Specifying the topic= of a paragraph in each sentence is redundant.=C2=A0The second sentence is = describing a limitation with the ::1/128 loopback prefix, which I'm confide= nt is obvious to most English speakers. One of my past reviewers isn't a na= tive English speaker, and they have had no trouble with that paragraph.=0A= =0AGUAs and ULAs aren't loopback prefixes (see RFC4291 and RFC4193), so my = statement is true.=0A=0A>=0A>3.=0A>A Unique Local IPv6 Unicast Address (ULA= ) prefix [RFC4193] could be used to increase the number of addresses availa= ble on the local host. However this prefix would need to be manually genera= ted and configured at least once by a system administrator or operator. Wit= hout additonal configuration, traffic towards addresses not assigned to the= local host would not be prevented from leaving the host, and access may no= t be limited to the local host.=C2=A0=C2=A0A ULA prefix would not be well k= nown, and would not be convenient to remember and type without violating th= e randomness requirements of the Global ID component of a ULA prefix.=0A>= =0A>=0A>Since the communication of this prefix in this case would not be ex= pected to extend beyond the host, the=0A>only requirement is that the ULA p= refix chosen not conflict with one that the host is expected to need to rea= ch outside of the host. As such, fd00::/48 is a perfectly viable candidate = in the vast majority of cases as it is very unlikely to conflict with a ran= domly chosen routable prefix that follows the standards in RFC4193.=0A>=0A>= =0A>The Global ID component of =C2=A0a ULA prefix is intended to avoid conf= licts in the results of M&A, etc. Since this would be host-local addressing= and not even have site-scope, use of a known non-conflicting ULA address i= s perfectly feasible. fd00::/48 is very unlikely to conflict (1 in 2^40 or = < 0.000,000,000,1% or =C2=A0<1 in 1e12).=0A>=0A=0ASo what would happen if y= ou had an IPv6 CPE that was announcing fd00::/64 in it's RAs (slide 26 ...)= , and you configured fd00::/48 or fd00::/64 on one of your loopback interfa= ces?=0A=0A>=0A>4.=0A>2.=C2=A0=C2=A0Larger Loopback Prefix Requirements A ne= w larger loopback prefix should attempt to satisfy all of the following req= uirements.=C2=A0=C2=A0It should: o=C2=A0=C2=A0be a well known prefix, o=C2= =A0=C2=A0be within an existing special purpose prefix, such as 0000::/8 (th= e parent prefix of the current IPv6 loopback address), o=C2=A0=C2=A0be easy= for a human to remember, o=C2=A0=C2=A0be easy for a human to type, o=C2=A0= =C2=A0cover the existing loopback prefix, o=C2=A0=C2=A0support 64 bit Inter= face Identifiers, o=C2=A0=C2=A0provide a large number of /64 subnets. =0A>= =0A>=0A>I believe that fd00::/48 could do what you describe:=0A>=0A>=0A>1.I= question the need for it to be well known. As long as it is well known wit= hin=0A>the scope of the intended use, I think that suffices for the use cas= es you have=0A>described.=0A>=0A=0AWell known makes it easy to add to ACLs.= Well known makes it easy to remember. Well known means it is the same on a= ll hosts.=0A=0APeople will even turn an "unusable=C2=A0definition of the lo= opback address", used to "encourage use=09of=C2=A0officially-assigned addre= sses", into=C2=A0the well known loopback address.=0A=0Ahttp://www-mice.cs.u= cl.ac.uk/multimedia/misc/tcp_ip/8603.mm.www/0184.html=0A=0A=0A=0A>=0A>fd00:= :/48 could easily meet that test.=0A>=0A=0AAnd fails to comply with the RFC= that defines the address space it falls within. From RFC4193:=0A" The allo= cation of Global IDs is pseudo-random [RANDOM]. They MUST NOT be assigned = sequentially or with well-known numbers."=0A"Locally assigned Global IDs MU= ST be generated with a pseudo-random=0A=0Aalgorithm consistent with [RANDOM= ]."=0A=0ASo your proposal violates that RFC, and therefore you would need t= o write an ID changing it to support your use of the Global ID zero value.= =0A=0A>=0A>2.fd00::/48 is within the existing ULA special purpose prefix.= =0A>3.fd00::/48 is very easy for a human to remember.=0A>4.fd00::/48 is ver= y easy for a human to type.=0A>5.Please justify your claim that it should e= ncompass the existing loopback address.=0A=0AI'd have thought it'd be obvio= us that expanding the existing prefix would have been better if possible. I= 'd have thought this text would convey that.=0A=0A"Ideally, the prefix leng= th of ::1/128 could be shortened, resulting in a larger loopback prefix suc= h as ::/48. However, if the existing loopback prefix length is shortened e= nough to satisfy all of the larger loopback prefix requirements, it would t= hen cover the IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and preve= nt its use described in [RFC4038]."=0A=0A=0A=0A>6.fd00::/48 supports 64 bit= IIDs.=0A>7.fd00::/48 provides 65,536 /64 subnets. Is there some reason you= think this is insufficient?=0A>This is a total of 4 billion times 16.7 mil= lion times as many host addresses as were provided=0A>in the IPv4 loopback.= =0A>=0A=0AIt is quite adequate, and the size I proposed in the first two dr= afts. However, under 0000::/8, it's possible to make it a /32, because thei= r are 16 million of them. Since this draft is revisiting the original ::1/1= 28 decision, why not make every attempt that can be easily afforded to avoi= d revisiting the IPv6 loopback prefix the 3rd time. "More than enough" is b= etter than "just enough" when cheap enough, as it saves coming back for mor= e.=C2=A0=0A=0A>=0A>It is 1/256th as many networks as IPv4 provided loopback= hosts.=0A>=0A>=0A>5.=0A>3.=C2=A0=C2=A0Proposed Larger Loopback Prefix Idea= lly, the prefix length of ::1/128 could be shortened, resulting in a larger= loopback prefix such as ::/48.=C2=A0=C2=A0However, if the existing loopbac= k prefix length is shortened enough to satisfy all of the larger loopback p= refix requirements, it would then cover the IPv4 Mapped IPv6 Address prefix= , ::ffff:0.0.0.0/96, and prevent its use described in [RFC4038]. Giving up = the requirement of covering the existing loopback prefix, the proposed larg= er loopback prefix is: =0A>=0A>=0A>=0A>So why not simply delete this from t= he requirements list as you've failed to=0A>provide any justification for s= aid requirement anyway.=0A=0ARequirementlists define both wants and needs. = It's there because more than once people have asked why not just shorten th= e prefix length of the existing prefix.=0A=0A>Smith=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Expires August 15, 2013=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[Page 4] = =0A> Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A Larger= IPv6 Loopback Prefix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Februa= ry 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 Thi= s prefix satisfies all remaining larger loopback prefix requirements.=0A>= =0A>=0A>I think this is a terrible choice of location. It pretty much maxim= izes the fragmentation damage that can be done by the choice of prefix. :1:= :/32 would at least be the first /32 available. As I've stated, a locally c= hosen address such as fd00::/48 (or whatever selection of chosen ULA space = meets local requirements) is equally viable IMHO.=0A>=0A=0AThe goal was the= shortest thing to type, and I don't think fragmentation matters within 000= 0::/8. I think people will commonly forget the colon on the front of :1::/3= 2, or mix up where the two contiguous colons are e.g. they'll type ::1:/32.= =0A=0A>=0A>6.=0A>Allocating a /32 prefix for the loopback function may seem= excessive, as a /48 length prefix would satisfy the larger loopback prefix= requirements.=C2=A0=C2=A0However, within the parent 0000::/8 special purpo= se prefix, there are approximately 16 million /32 prefixes, so a single /32= for the larger loopback prefix is easily afforded.=C2=A0=C2=A0A /32 larger= loopback prefix will satisfy all current and likely future uses of the loo= pback function.=0A>=0A>=0A>Allocating a /32 is absurdly excessive and just = because we can does not strike me as anything remotely resembling an argume= nt that we should.=0A>=0A=0ASo you're saying that you can think of better u= ses for the 16 million /32s within 0000::/8, such that just one can't be us= ed for this purpose? What are some of your better uses?=0A=0A>=0A>4.=C2=A0= =C2=A0Address Assignment and Configuration =0A>=0A>=0A>Consistent with the = IPv6 addressing model [RFC4291], each address within the larger loopback pr= efix is associated with one of the node's interfaces, although not necessar= ily the same interface for all addresses.=C2=A0=C2=A0This means that the no= de acts as though all addresses within the larger loopback prefix have been= configured on one or more interfaces.=C2=A0=C2=A0Applications will accept = packets destined to any of the larger loopback prefix addresses, unless the= application is bound to specific larger loopback addresses.=C2=A0=C2=A0Typ= ically the addresses will be logically assigned to one or more virtual "loo= pback" interfaces, which locally returns or loops outgoing packets back to = the same node that originated the packets.=0A>=0A>=0A>=0A>=0A>=0A>=0A>I bel= ieve you have misread and conflated RFC4291 and RFC1122 with regards to how= loopback=0A>addresses function.=0A>=0A=0AThis is specifying the address as= signment and configuration scheme for the proposed larger loopback prefix. = You have misread and misunderstood this text.=0A=0A>=0A>Unless I am mistake= n, there is no requirement in RFC1122 that a node answer all addresses with= in 127/8.=0A>=0A>=0A>Some nodes may support more than one loopback interfac= e.=C2=A0=C2=A0These subsequent loopback interfaces, when initialised, shoul= d be assigned Smith=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Expires A= ugust 15, 2013=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[Page 5] =0A> Internet-Draft=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A Larger IPv6 Loopback Prefix=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0February 2013 a larger loopback /= 64 prefix locally unique within the node.=C2=A0=C2=A0All addresses within t= he assigned /64 are logically assigned to the interface.=C2=A0=C2=A0Additio= nally, the ":1" address for the subnet should be configured on the loopback= interface, making it visible to a system operator or user.=0A>=0A>=0A>This= would, indeed, be new functionality. I am not convinced of any value to ha= ving that functionality and it is radically different from any required fun= ctionality in IPv4 today. In IPv4, hosts which support multiple loopbacks h= ave no default address or range on the subsequent loopback interfaces.=0A>= =0A=0ARight. The goal here is to take something useful in IPv4 that doesn't= exist in IPv6, and then to also see if there are opportunities to make fur= ther improvements. This is not a literal copy of IPv4 functionality into IP= v6. Changes to fix limitations are also opportunities to make improvements.= =0A=0A>=0A>If you cannot justify a need for this functionality, I see no po= int in advancing it as a standard.=0A>=0A=0AI have justified it, in Abstrac= t and the Introduction. You might not believe there is a problem to solve, = but that doesn't mean that other people don't, and that they haven't experi= enced a problem. In addition to myself, Erik Kline and=C2=A0Vijayrajan Rang= anathan have encountered situations where more IPv6 loopback addresses woul= d be useful:=0A=0Ahttp://www.ietf.org/mail-archive/web/v6ops/current/msg148= 15.html=0A=0A=0Ahttp://www.ietf.org/mail-archive/web/ipv6/current/msg10882.= html=0A=0A=0AHere is Erik, back in 2009, describing the exact scenario that= I've described in the Abstract and Intro.=0A=0Ahttp://www.ietf.org/mail-ar= chive/web/ipv6/current/msg11018.html=0A=0A=0A=0A=0A>=0A>It should be possib= le for an operator to remove these automatically configured loopback addres= ses.=C2=A0=C2=A0It should also be possible for an operator to configure fur= ther loopback addresses from within the assigned /64, or addresses from oth= er parts of the larger loopback prefix, including other /64s assigned to ot= her loopback interfaces. Other addresses within the assigned /64(s) would c= ontinue to be logically assigned to the subsequent loopback interface. Conf= iguration of addresses is for operational visibility and convenience, and d= oes not change the behaviour of non-visible logically assigned addresses.= =0A>=0A>=0A>If you're going to do this, then I would argue that it "must" b= e possible for an operator to remove=E2=80=A6=0A>=0A=0Aok. I've tried to av= oid being too absolute in this area because it's describing operator/system= interface functionality, rather than things a compliant implementation mus= t do.=0A=0A=0A>=0A>The rest of what you suggest strikes me as being a kerne= l routing hairball of unnecessarily large=0A>proportion and likely to engen= der more bugs than functionality.=0A>=0A=0AI'm curious as to what experienc= e you have to be able to make that judgement. Using Linux as an example IPv= 6 implementation,=C2=A0I know enough about the Linux kernel networking code= that I'm pretty sure it shouldn't be too hard to make these changes.=0A=0A= =0A>=0A>------=0A>=0A>=0A>This covers the first 6 pages (approximately half= of the draft). I'm not going to take the time to write up the problems in = the rest of the draft at this point because the above are, IMHO, more than = sufficient reason to oppose adoption.=0A>=0A>=0A>Owen=0A>=0A>=0A>On Feb 12,= 2013, at 4:18 PM, Owen DeLong wrote:=0A>=0A>=0A>>On Feb = 12, 2013, at 12:33 PM, Mark Smith wrote:=0A>>= =0A>>=0A>>=0A>>>=0A>>>=0A>>>=0A>>>----- Original Message -----=0A>>>=0A>>>F= rom: Owen DeLong =0A>>>>To: Mark Smith =0A>>>>Cc: Doug Barton ; "v6ops@ietf.org" =0A>>>>Sent: Wednesday, 13 February 2013 6:59 AM=0A>>>>Subject:= Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loo= pback-prefix-03.txt=0A>>>>=0A>>>>=0A>>>>=0A>>>>>>?? I don't see how it gets= easier to remember than fd00::/8=0A>>>>>>=0A>>>>>The random bit is the har= d bit to remember and type. I don't think =0A>>>>>you're thinking enough ab= out how it is to use, you're only thinking =0A>>>>about how hard it is to c= onfigure. The time and effort to configure something is =0A>>>>usually mini= mal compared to the amount of time and effort spent while it is =0A>>>>bein= g used.=0A>>>>=0A>>>>=0A>>>>>=0A>>>>Nothing requires you to use random for = this purpose. Use fd00::/64 for all =0A>>>>anyone cares.=0A>>>>=0A>>>>=0A>>= >RFC4193 does. It's not a ULA if it doesn't, it's been made a site-local. S= ee RFC3879 for the problems with them and your non-random ULA.=0A>>>=0A>>>= =0A>>Which is irrelevant to the loopback scenario you have described=E2=80= =A6=0A>>=0A>>=0A>>=0A>>>=0A>>>and you can use =0A>>>>>>=0A>>>>>=0A>>>>>anyt= hing you want inside of that to provide a /64 for your development =0A>>>>>= >purpose.=0A>>>>=0A>>>>=0A>>>>>>What's more cumbersome about picking someth= ing (even fd00::/64, if =0A>>>>>>you want) =0A>>>>=0A>>>>=0A>>>>>No, that's= bad, as it is a ULA prefix which doesn't have a random =0A>>>>>component. = Add the random component (if you aren't lazy), and it then =0A>>>>becomes h= ard to remember and type.=0A>>>>=0A>>>>=0A>>>>>=0A>>>>Why is it bad that it= doesn't have a random component? If it's in a =0A>>>>development test lab,= it's not like it's at risk of corporate merger =0A>>>>conflicts, etc.=0A>>= >>=0A>>>>=0A>>>See slide 26.=0A>>>=0A>>>http://www.users.on.net/~markachy/r= esi_ipv6_cpe.pdf=0A>>>=0A>>>=0A>>Which does not apply to use on a loopback = interface.=0A>>=0A>>=0A>>=0A>>>=0A>>>for development than having some other= prefix you have to configure =0A>>>>>>assigned by =0A>>>>=0A>>>>=0A>>>>>= =0A>>>>>the IETF.=0A>>>>>>=0A>>>>>I'm starting to wonder if you've actually= read the draft. The =0A>>>>>intention is that it is that the larger loopba= ck prefix automatically configured =0A>>>>at system initialisation, as ::1/= 128 and 127/8 currently are. There is a whole =0A>>>>section on automatic a= ddress assignment and configuration.=0A>>>>=0A>>>>127/8 isn't auto-assigned= . 127.0.0.1/8 is.=0A>>>>=0A>>>>=0A>>>That's incorrect.=0A>>>=0A>>>RFC1122, = "Requirements for Internet Hosts -- Communication Layers", specifically the= in=0A>>>=0A>>>"(g) { 127, }=0A>>>Internal host loopback addres= s. =C2=A0Addresses of this form MUST NOT appear outside a host."=0A>>>=0A>>= >=0A>>Yes, it requires that you not have addresses within 127.0.0.0/8 appea= r outside of the host. It does=0A>>not require the host to answer or auto c= onfigure all of the 127.0.0.0/8 addresses on its loopback=0A>>interface and= , indeed, most hosts do NOT auto configure other than 127.0.0.1.=0A>>=0A>>= =0A>>=0A>>>>>=0A>>>=0A>>>=0A>>>>>>Sorry, but I just don't get it.=0A>>>>>>= =0A>>>>>>=0A>>>>>>=0A>>>>>>>=0A>>>>>>=0A>>>>>>This proposal also takes the = opportunity to introduce IPv4-like =0A>>>>>>>handling of =0A>>>>=0A>>>>loop= back IPv6 packets so that future functions similar to the use in =0A>>>>>>R= FC4379 =0A>>>>=0A>>>>have a native IPv6 address space to use, rather than u= sing 127/8 within =0A>>>>>>an IPv6 =0A>>>>=0A>>>>prefix.=0A>>>>>>=0A>>>>>>I= n my (admittedly limited) testing, putting a /64 of ULA on the =0A>>>>>>loo= pback =0A>>>>=0A>>>>interface did just that, so I'm not sure what it is tha= t you feel =0A>>>>>>is =0A>>>>=0A>>>>missing.=0A>>>>>>=0A>>>>>>=0A>>>>>All = addresses within 127/8 are valid and available on the host, where as =0A>>>= >>with your ULA, only 1 is.=0A>>>>=0A>>>>=0A>>>>>e.g.=0A>>>>>=0A>>>>>=0A>>>= >>[root@opy mark]# ip addr show dev lo=0A>>>>>1: lo: = mtu 65536 qdisc noqueue state UNKNOWN =0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0link= /loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00=0A>>>>>=C2=A0=C2=A0=C2=A0= =C2=A0inet 127.0.0.1/8 scope host lo=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0inet6 f= d00:db8::1/64 scope global =0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0valid_lft forever preferred_lft forever=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0i= net6 1::1/64 scope global =0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0valid_lft forever preferred_lft forever=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0i= net6 ::1/128 scope host =0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0v= alid_lft forever preferred_lft forever=0A>>>>>=0A>>>>>[root@opy mark]# ping= -c 1 127.1.2.3=0A>>>>>PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.=0A>= >>>>64 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 ms=0A>>>>>= =0A>>>>>--- 127.1.2.3 ping statistics ---=0A>>>>>1 packets transmitted, 1 r= eceived, 0% packet loss, time 0ms=0A>>>>>rtt min/avg/max/mdev =3D 0.053/0.0= 53/0.053/0.000 ms=0A>>>>>[root@opy mark]# =0A>>>>>=0A>>>>>=0A>>>>Interestin= g=E2=80=A6 I get this behavior on MacOS.=0A>>>>=0A>>>>[tc01-dhcp153:~] owen= % ifconfig lo0=0A>>>>lo0: flags=3D8049 mtu 1= 6384=0A>>>>=C2=A0=C2=A0=C2=A0options=3D3=0A>>>>=C2=A0=C2=A0= =C2=A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 =0A>>>>=C2=A0=C2=A0=C2=A0i= net 127.0.0.1 netmask 0xff000000 =0A>>>>=C2=A0=C2=A0=C2=A0inet6 ::1 prefixl= en 128 =0A>>>>=0A>>>>[tc01-dhcp153:~] owen% ping 127.1.2.3=0A>>>>PING 127.1= .2.3 (127.1.2.3): 56 data bytes=0A>>>>Request timeout for icmp_seq 0=0A>>>>= Request timeout for icmp_seq 1=0A>>>>Request timeout for icmp_seq 2=0A>>>>R= equest timeout for icmp_seq 3=0A>>>>^C=0A>>>>--- 127.1.2.3 ping statistics = ---=0A>>>>5 packets transmitted, 0 packets received, 100.0% packet loss=0A>= >>>=0A>>>>=0A>>>So MacOS isn't compliant with RFC1122.=0A>>>=0A>>>=0A>>How = do you figure that? You'll need to be more specific.=0A>>=0A>>=0A>>=0A>>>= =0A>>>Admittedly, Linux does this:=0A>>>>=0A>>>>owen.delong.com:owen /home4= /owen (22) % ifconfig lo=0A>>>>lo =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Link encap:Local Loopback =C2=A0=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0inet addr:127.0.0.1 =C2=A0Mask:255.0.0.0=0A>>>>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0inet6 addr: ::1/128 Scope:H= ost=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0UP LOOPBACK= RUNNING =C2=A0MTU:16436 =C2=A0Metric:1=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0RX packets:45816328 errors:0 dropped:0 overruns:= 0 frame:0=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0TX pa= ckets:45816328 errors:0 dropped:0 overruns:0 carrier:0=0A>>>>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collisions:0 txqueuelen:0 =0A>>>>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RX bytes:578712867 (5= 51.9 MiB) =C2=A0TX bytes:578712867 (551.9 MiB)=0A>>>>=0A>>>>owen.delong.com= :owen /home4/owen (23) % ping 127.1.2.3=0A>>>>PING 127.1.2.3 (127.1.2.3) 56= (84) bytes of data.=0A>>>>64 bytes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 ti= me=3D0.043 ms=0A>>>>64 bytes from 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0= .032 ms=0A>>>>64 bytes from 127.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 m= s=0A>>>>^C=0A>>>>--- 127.1.2.3 ping statistics ---=0A>>>>3 packets transmit= ted, 3 received, 0% packet loss, time 2000ms=0A>>>>rtt min/avg/max/mdev =3D= 0.019/0.031/0.043/0.010 ms=0A>>>>owen.delong.com:owen /home4/owen (24) % = =0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>[root@opy mark]# ping6 -c 1 fd00:db8::2= =0A>>>>>=0A>>>>>connect: Network is unreachable=0A>>>>>[root@opy mark]#=0A>= >>>>=0A>>>>>[mark@opy ~]$ ssh 127.1.2.3=0A>>>>>The authenticity of host '12= 7.1.2.3 (127.1.2.3)' can't be =0A>>>>>established.=0A>>>>=0A>>>>=0A>>>>>[ma= rk@opy ~]$ ssh -6 fd00:db8::2=0A>>>>>ssh: connect to host fd00:db8::2 port = 22: Network is unreachable=0A>>>>>[mark@opy ~]$=0A>>>>>=0A>>>>>=0A>>>>From = what I can see, this seems to depend on a pathology not universally =0A>>>>= available even in IPv4.=0A>>>>=0A>>>>=0A>>>>Another test you should do to m= easure the usefulness of this proposal is =0A>>>>>see how long it takes and= your opinion afterwards of how hard or easy it is to =0A>>>>type or cut an= d paste "fd00:db8::1" vs "1::1" a reasonable =0A>>>>number of times e.g. 6 = times.=0A>>>>=0A>>>>=0A>>>>>=0A>>>>I'm fine with it. If you're doing it mor= e than 6 times, that's what =0A>>>>DNS is for.=0A>>>>=0A>>>>=0A>>>That's an= option, for applications that use DNS to resolve addresses. There are appl= ications that need to deal with addresses directly, such as mine, due to th= eir nature and purpose.=0A>>>=0A>>Then use a configuration file or whatever= . There are lots of alternatives to repeatedly typing in addresses.=0A>>(co= mmand-line aliases come to mind as an example).=0A>>=0A>>=0A>>=0A>>>=0A>>>= =0A>>>>>Using a ULA doesn't really work at all. It only adds another addres= s to =0A>>>>>the host, rather than many. A properly formed ULA is hard to t= ype and remember. =0A>>>>It's far less user friendly than the short larger = loopback prefix I'm =0A>>>>proposing. This is based on my experience, as I'= ve used a ULA for the =0A>>>>purpose of trying to increase the number of lo= opback IPv6 addresses.=0A>>>>=0A>>>>=0A>>>>>=0A>>>>The same is true with lo= opback except on Linux as near as I can tell.=0A>>>>=0A>>>>=0A>>>Windows 7 = also behaves this way, as it complies with RFC1122.=0A>>>=0A>>>=0A>>Nothing= I found in RFC 1122 requires this, so if you think something does, you'll= =0A>>need to point it out.=0A>>=0A>>I know for a fact that several Cisco sw= itches did not. For example, they used to use=0A>>127.0.0. as = a convenient hack for connections across the backplane=0A>>to the IP stack = running on IP-aware blades such as RSMs.=0A>>=0A>>=0A>>=0A>>>>>>>=0A>>>>>= =0A>>>>>Note, I don't know the answer, but I'm leaning heavily =0A>>>>>>>>t= owards, =0A>>>>=0A>>>>=0A>>>>>>=0A>>>>>>"no."=0A>>>>>>>>=0A>>>>>>>>Primaril= y because we're asking people to deploy this =0A>>>>>>>>protocol for =0A>>>= >=0A>>>>real-world scenarios, and we already have a pretty wide =0A>>>>>>>>= divergence in =0A>>>>=0A>>>>the latest state of the standards vs. the oldes= t working =0A>>>>>>>>deployed base. =0A>>>>=0A>>>>=0A>>>>>>=0A>>>>>>Widenin= g that gap should only be done for truly critical =0A>>>>>>>>changes, and = =0A>>>>=0A>>>>I'm not sure you've made your case sufficiently.=0A>>>>>>>>= =0A>>>>>>>>Put more simply, at some point we have to stop tinkering with = =0A>>>>>>>>the plane =0A>>>>=0A>>>>=0A>>>>>>=0A>>>>>>while it's in the air.= =0A>>>>>>>>=0A>>>>>>>>=0A>>>>>>>So I think the implication of that analogy = is that deploying this =0A>>>>>>>enhancement will somehow interrupt the exi= sting operation of IPv6 =0A>>>>>>implementations ("the plane") causing them= to fail =0A>>>>>>("fall out of =0A>>>>=0A>>>>the sky"). I don't see how th= at will be the case. Deploying a =0A>>>>>>new =0A>>>>=0A>>>>loopback prefix= would leverage many of the existing address =0A>>>>>>configuration and =0A= >>>>=0A>>>>loopback related functions of existing IPv6 implementations. It = is not =0A>>>>>>much more =0A>>>>=0A>>>>than a larger version of ::1/128.= =0A>>>>>>=0A>>>>>>The implication is that you are requesting to once again = obsolete all =0A>>>>>>existing =0A>>>>=0A>>>>implementations in favor of re= quiring deploying another fundamentally =0A>>>>>>changed =0A>>>>=0A>>>>IPv6= stack.=0A>>>>>>=0A>>>>>Can you define the threshold of "fundamentally chan= ged" for me?=0A>>>>>=0A>>>>>=0A>>>>Requiring a modification to every existi= ng IPv6 stack in the wild which could be=0A>>>>incorporated into software d= ependencies which would render existing stacks =0A>>>>unexpectedly=0A>>>>ob= solete.=0A>>>>=0A>>>>=0A>>>>I don't consider this to be a fundamental chang= e. It is adding another =0A>>>>>loopback prefix, which operates the same as= the existing one, just with a =0A>>>>shorter prefix length. It is adding v= alues to the source and destination address =0A>>>>selection policy, which = is already possible to do because it's been designed =0A>>>>that way. I'm q= uite confident that it is going to be no more than 10 lines, =0A>>>>and pro= bably closer to 5 additional lines of code in a stack for a host =0A>>>>imp= lementation that only supports a single loopback interface. That's code =0A= >>>>change size closer to the size of bug fixes than additional functionali= ty.=0A>>>>=0A>>>>=0A>>>>>=0A>>>>So you want to force everyone to update the= ir IPv6 stack on every host, router, =0A>>>>switch, etc. just so you can sa= ve some typing?=0A>>>>=0A>>>>=0A>>>The IETF (and I) can't force anything. I= f it's useful, it'll be implemented.=0A>>>=0A>>>=0A>>IMHO, it's not all tha= t useful and making it a stack requirement would lead to one of two bad sit= uations:=0A>>=0A>>1.Development resources would be taken away from tasks th= at matter.=0A>>or=0A>>2.Increasing divergence between the implemented stack= s and the documented standards.=0A>>=0A>>=0A>>=0A>>You're doing a very good= job cementing my opposition here.=0A>>>>=0A>>>>=0A>>>You seem to like doin= g things the hard way. My view is computers should do things automatically = for people so that people can get on with more valuable things. Developers = should be cutting code instead of setting up development environments, or w= aiting for system administrators to set up the development environment for = them.=0A>>>=0A>>>=0A>>Actually, I do not. However, I do not believe in usin= g the entire IP stack development community as a workforce to save me a lit= tle bit of typing which, as near as I can tell is all that this proposal wo= uld accomplish.=0A>>=0A>>The functionality you seek is available using ULA.= The issues you cite with ULA would not apply to loopback usage. The functi= onality that you attribute to RFC 1122 isn't (as near as I can tell) actual= ly codified into RFC 1122 (I don't see how requiring that an address range = not appear outside of a host requires that host to accept all packets to an= y address in said range, which is what you are claiming).=0A>>=0A>>=0A>>My = definition of a fundamental change would be to do something like change =0A= >>>>>the change the size of the IPv6 address, or reorder the fields in the = IPv6 =0A>>>>header.=0A>>>>=0A>>>>=0A>>>>>=0A>>>>That would be a drastic cha= nge, indeed. This is less drastic, but it would make =0A>>>>current IPv6 st= acks incompatible with the protocol definition.=0A>>>>=0A>>>>=0A>>>I don't = get this. 1::/32 is not currently used for anything, so using it is not goi= ng to make it incompatible with anything. Using other prefixes for purposes= that they weren't designed for, such as a ULA as a loopback, has far great= er risk of creating incompatibility. =0A>>>=0A>>If you add this as a requir= ed stack feature, stacks which don't implement the feature are no longer co= mpliant.=0A>>=0A>>=0A>>=0A>>>=0A>>>The question is whether there is enough = value in the change to =0A>>>>>>justify such a decision and IMHO, at this p= oint, just to make it =0A>>>>>>"less =0A>>>>=0A>>>>cumbersome" than putting= (a) ULA address(es) on the loopback =0A>>>>>>interface =0A>>>>=0A>>>>strik= es me as not having much value.=0A>>>>>>=0A>>>>>>=0A>>>You don't seem to be= placing any value convenience. Does your car have an automatic transmissio= n? Do you have a dishwasher? Do you go to restaurants? All of those things = only exist because humans place value on the convenience of not manually ch= anging gears, not manually washing dishes, and not cooking at home when we = could. Why have to do something manually when a computer could do it automa= tically for you?=0A>>>=0A>>>=0A>>I place tremendous value on convenience. M= y car does not have a traditional automatic transmission, my car has an ECV= T transmission. If I were buying a car, I would actually prefer a manual tr= ansmission because I prefer the greater control flexibility and shifting pr= ecision afforded by a manual transmission.=0A>>=0A>>Yes, I go to restaurant= s.=0A>>=0A>>There are many equally automatic solutions to your problem alre= ady available without involving the entire body of protocol developers and = the IETF in the process.=0A>>=0A>>Owen=0A>>=0A>>=0A>>Owen=0A>>>>>>=0A>>>>>>= =0A>>>>>>=0A>>>>>>>=0A>>>>>>>Regards,=0A>>>>>>>Mark.=0A>>>>>>>=0A>>>>>>>=0A= >>>>>>>=0A>>>>>>>Doug=0A>>>>>>>>=0A>>>>>>>>=0A>>>>>>>>On 02/11/2013 01:37 P= M, David Farmer wrote:=0A>>>>>>>>=0A>>>>>>>>On 2/11/13 14:28 , Owen DeLong = wrote:=0A>>>>>>>>>=0A>>>>>>>>>Perhaps I'm not very bright, but is there any= =0A>>>>>>>>>>reason ULA =0A>>>>=0A>>>>couldn't be=0A>>>>>>>>=0A>>>>>>>>use= d on the LO interface to=0A>>>>>>>>>>satisfy this corner case?=0A>>>>>>>>>>= =0A>>>>>>>>>The Draft does cover why ULA is thought to not be a =0A>>>>>>>>= >sufficient =0A>>>>=0A>>>>solution,=0A>>>>>>=0A>>>>>>do you disagree with t= he reasoning in the draft?=0A>>>>>>>>>=0A>>>>>>>>>from Section 1;=0A>>>>>>>= >>=0A>>>>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A Unique Local IPv6 Unica= st Address (ULA) prefix =0A>>>>>>>>>[RFC4193] =0A>>>>=0A>>>>could be=0A>>>>= >>=0A>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0used to increase the number = of addresses available on =0A>>>>>>>>>the =0A>>>>=0A>>>>local host.=0A>>>>>= >=0A>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0However this prefix would nee= d to be manually =0A>>>>>>>>>generated and=0A>>>>=0A>>>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0configured at least once by a system administrator or =0A= >>>>>>>>>=0A>>>>=0A>>>>operator.=0A>>>>>>=0A>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Without additonal configuration, traffic towards =0A>>>>>>>>>ad= dresses not=0A>>>>=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0assigned to th= e local host would not be prevented =0A>>>>>>>>>from leaving =0A>>>>=0A>>>>= the=0A>>>>>>=0A>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0host, and access m= ay not be limited to the local =0A>>>>>>>>>host. =C2=A0A ULA =0A>>>>=0A>>>>= prefix=0A>>>>>>=0A>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0would not be we= ll known, and would not be convenient =0A>>>>>>>>>to =0A>>>>=0A>>>>remember= and=0A>>>>>>=0A>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0type without viol= ating the randomness requirements of =0A>>>>>>>>>the =0A>>>>=0A>>>>Global I= D=0A>>>>>>=0A>>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0component of a ULA p= refix.=0A>>>>>>>>>=0A>>>>>>>>>=0A>>>>>>>>>Owen=0A>>>>>>>>>>=0A>>>>>>>>>>On = Feb 11, 2013, at 12:20 , Mark Smith =0A>>>>>>>>>> wrote:=0A>>>>>>>>=0A>>>>>>>>=0A>>>>>>>>>>=0A>>>>>>>>>>Hi,=0A>>>>>>>>>>>= =0A>>>>>>>>>>>Here is a new version of my IPv6 larger loopback =0A>>>>>>>>>= >>prefix =0A>>>>=0A>>>>draft.=0A>>>>>>=0A>>>>>>Changes since the previous v= ersion:=0A>>>>>>>>>>>=0A>>>>>>>>>>>o =C2=A0default address selection preced= ence and label =0A>>>>>>>>>>>values=0A>>>>=0A>>>>o =C2=A0comment about othe= r IPv4 in IPv6 address forms=0A>>>>>>>>>>>=0A>>>>>>>>>>>o =C2=A0more clarif= ications=0A>>>>>>>>>>>=0A>>>>>>>>>>>o =C2=A0grammar corrections=0A>>>>>>>>>= >>=0A>>>>>>>>>>>=0A>>>>>>>>>>>My thanks to Bill Atwood, Matts Kallioniemi a= nd =0A>>>>>>>>>>>Tina Tsou =0A>>>>=0A>>>>for their=0A>>>>>>=0A>>>>>>review = and comments on this revision.=0A>>>>>>>>>>>=0A>>>>>>>>>>>Further review an= d comments would be most =0A>>>>>>>>>>>appreciated.=0A>>>>=0A>>>>=0A>>>>>>>= >>>>Thanks,=0A>>>>>>>>>>>Mark.=0A>>>>>>>>>>>=0A>>>>>>>>>=0A>>>>>>>>>=0A>>>>= >>>>>=0A>>>>>>>>_______________________________________________=0A>>>>>>>>v= 6ops mailing list=0A>>>>>>>>v6ops@ietf.org=0A>>>>>>>>https://www.ietf.org/m= ailman/listinfo/v6ops=0A>>>>>>>>=0A>>>>>>>>________________________________= _______________=0A>>>>>>>v6ops mailing list=0A>>>>>>>v6ops@ietf.org=0A>>>>>= >>https://www.ietf.org/mailman/listinfo/v6ops=0A>>>>>>>=0A>>>>>>=0A>>>>=0A>= >_______________________________________________=0A>>v6ops mailing list=0A>= >v6ops@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/v6ops=0A>>=0A>=0A= >=0A> From owen@delong.com Wed Feb 13 01:59: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 EFAA821F8848 for ; Wed, 13 Feb 2013 01:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[AWL=-2.720, BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, SARE_RAND_1=2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ln3SSxP1yTzN for ; Wed, 13 Feb 2013 01:59:48 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 48BE521F866D for ; Wed, 13 Feb 2013 01:59:48 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1D9vJTT020775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Feb 2013 01:57:19 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1D9vJTT020775 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1360749439; bh=K6CQiUvQw/ku92qYayPT8ec4GFM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=k+MfLYsEcs3qYFylrqL6DvkqRr5G9hBq48uKK7jdjtdtzc7s0ELr3ER9sRcrj7DWh 8vBXX0UXgHkEUwCInfu3HYleYnK75vdUxRkdsFF1s3zfQlwwoF1xR81nEbWzRPUVQ6 vL9HGO6RnKw+C2n2RyV3cqwCzJ0q6XHQHaqzZo+I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1360742992.43052.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 13 Feb 2013 01:57:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF3EA92-AEB2-42C2-949E-951E2C471686@delong.com> References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> <1360742992.43052.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 13 Feb 2013 01:57:19 -0800 (PST) Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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, 13 Feb 2013 09:59:51 -0000 On Feb 13, 2013, at 12:09 AM, Mark Smith = wrote: >> ________________________________ >> From: Owen DeLong >> To: Mark Smith =20 >> Cc: "v6ops@ietf.org" =20 >> Sent: Wednesday, 13 February 2013 12:46 PM >> Subject: Re: [v6ops] New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>=20 >>=20 >> I had actually read it, but, since you insist=85 >>=20 >>=20 >=20 > I think it is an obligation of being a member of this mailing list if = you are going to disagree with parts of an ID publicly.=20 >=20 As I said, I had actually read it. In spite of your claim that I hadn't. = While my subsequent post was more detailed than my previous arguments, I = do not think any of my previous arguments were in any way inconsistent = with the subsequent more detailed post. >>=20 >> 1. >> Under IPv4, the 127/8 loopback prefix [RFC1122] provides many >> addresses that can be used to run multiple instances of an = application on the same port, while also limiting access to the local = host. >>=20 >>=20 >> RFC1122 provides that 127/8 cannot appear outside of a host. It does = not require that the host process all addresses within 127/8 as you = describe. >>=20 >=20 > You're right it doesn't say that. It is common convention to do so, = and has been a useful one to me and others. I will change the text to = reflect that it is a common convention. >=20 I don't know how common that convention is. We've identified only 2 = operating systems that actually do so as yet. I don't know what the = behavior in other BSD derivatives, embedded operating systems, etc. is. = Certainly it is not common enough that I would consider counting on it a = good strategy for portable code. >>=20 >> 2. >> Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a = single address. Multiple application instances using the same port, = bound to different loopback addresses, is not possible.=20 >>=20 >>=20 >> Is not true. You can configure additional addresses on to the = loopback interface as desired and use them just as you would additional = addresses from the 127/8 address range. Since RFC1122 does not require = that the host treat all these addresses identically as you assume, there = is no difference between the current standards in IPv6 and the current = standards in IPv4 except that IPv4 sets aside a dedicated 16.7 million = host addresses for this purpose (of which only one is utilized in most = cases) and IPv6 sets aside 1. However, you are free to assign any GUA = or ULA prefix to the IPv6 loopback and use it in the same manner as you = are currently using the other 127/8 addresses. >>=20 >=20 > I think you're choosing to misread this two sentence paragraph. Normal = English convention is that sentences subsequent to the first in a = paragraph are in the context of the topic described by the first = sentence. Specifying the topic of a paragraph in each sentence is = redundant. The second sentence is describing a limitation with the = ::1/128 loopback prefix, which I'm confident is obvious to most English = speakers. One of my past reviewers isn't a native English speaker, and = they have had no trouble with that paragraph. >=20 > GUAs and ULAs aren't loopback prefixes (see RFC4291 and RFC4193), so = my statement is true. >=20 Your statement is not true. Multiple application instances using the = same port bound to different loopback addresses is possible. The fact = that the loopback addresses in question must be pulled from the ULA or = GUA pools is irrelevant to the truth or falsehood of the statement. Once = you assign an address to a loopback interface, it is by definition a = loopback address whether or not it came from a "loopback prefix". >>=20 >> 3. >> A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be = used to increase the number of addresses available on the local host. = However this prefix would need to be manually generated and configured = at least once by a system administrator or operator. Without additonal = configuration, traffic towards addresses not assigned to the local host = would not be prevented from leaving the host, and access may not be = limited to the local host. A ULA prefix would not be well known, and = would not be convenient to remember and type without violating the = randomness requirements of the Global ID component of a ULA prefix. >>=20 >>=20 >> Since the communication of this prefix in this case would not be = expected to extend beyond the host, the >> only requirement is that the ULA prefix chosen not conflict with one = that the host is expected to need to reach outside of the host. As such, = fd00::/48 is a perfectly viable candidate in the vast majority of cases = as it is very unlikely to conflict with a randomly chosen routable = prefix that follows the standards in RFC4193. >>=20 >>=20 >> The Global ID component of a ULA prefix is intended to avoid = conflicts in the results of M&A, etc. Since this would be host-local = addressing and not even have site-scope, use of a known non-conflicting = ULA address is perfectly feasible. fd00::/48 is very unlikely to = conflict (1 in 2^40 or < 0.000,000,000,1% or <1 in 1e12). >>=20 >=20 > So what would happen if you had an IPv6 CPE that was announcing = fd00::/64 in it's RAs (slide 26 =85), and you configured fd00::/48 or = fd00::/64 on one of your loopback interfaces? >=20 You'd be unable to reach the other hosts using that prefix most likely. = However, one wouldn't expect that you would do such a thing. If your = router is actually using fd00::/64, you'd want to use something else for = the loopback. Fortunately, you have 40 bits worth (more than a trillion) = other prefixes to choose from. >>=20 >> 4. >> 2. Larger Loopback Prefix Requirements A new larger loopback prefix = should attempt to satisfy all of the following requirements. It should: = o be a well known prefix, o be within an existing special purpose = prefix, such as 0000::/8 (the parent prefix of the current IPv6 loopback = address), o be easy for a human to remember, o be easy for a human to = type, o cover the existing loopback prefix, o support 64 bit Interface = Identifiers, o provide a large number of /64 subnets.=20 >>=20 >>=20 >> I believe that fd00::/48 could do what you describe: >>=20 >>=20 >> 1.I question the need for it to be well known. As long as it is well = known within >> the scope of the intended use, I think that suffices for the use = cases you have >> described. >>=20 >=20 > Well known makes it easy to add to ACLs. Well known makes it easy to = remember. Well known means it is the same on all hosts. >=20 If it's a loopback, what's the point of putting it in ACLs? Since the = packets shouldn't leave the host, there's not much utility to ACLs. As long as it's well known within the context (i.e. workgroup, company, = site, whatever administrative boundary you decide is appropriate under the circumstances) it still meets those = requirements anyway. > People will even turn an "unusable definition of the loopback = address", used to "encourage use of officially-assigned = addresses", into the well known loopback address. >=20 > = http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8603.mm.www/0184.html >=20 That URL leads to a rather lengthy rant about bugs in 4.2 (and 4.3) BSD = which I believe were fixed many years ago. It talks about software mistakenly choosing the loopback address as a = source address when creating a reply packet in UDP. I fail to see any = relevance to the current proposal other than as a possible further = indication of just how bad an idea this actually is, since the closest = connection that comes to mind is the probability of implementing this = draft leading to the introduction of similar bugs. >=20 >=20 >>=20 >> fd00::/48 could easily meet that test. >>=20 >=20 > And fails to comply with the RFC that defines the address space it = falls within. =46rom RFC4193: > " The allocation of Global IDs is pseudo-random [RANDOM]. They MUST = NOT be assigned sequentially or with well-known numbers." > "Locally assigned Global IDs MUST be generated with a pseudo-random >=20 > algorithm consistent with [RANDOM]." >=20 > So your proposal violates that RFC, and therefore you would need to = write an ID changing it to support your use of the Global ID zero value. >=20 Or you sanely realize that the reason for that is the assumption that = the addresses would be applied to routable interfaces and not loopbacks. = Certainly an ID using fd00::/48 would be preferable to this debacle as = it doesn't require any software updates and provides the same = functionality. However, as I pointed out, fd00::/48 was just an easy example. You could = use a truly random ULA if you were so inclined, but you lose out on the = easy to type/easy to remember features. >>=20 >> 2.fd00::/48 is within the existing ULA special purpose prefix. >> 3.fd00::/48 is very easy for a human to remember. >> 4.fd00::/48 is very easy for a human to type. >> 5.Please justify your claim that it should encompass the existing = loopback address. >=20 > I'd have thought it'd be obvious that expanding the existing prefix = would have been better if possible. I'd have thought this text would = convey that. Better in what way. You still haven't actually justified this claim, = you've merely told me it should be obvious. Certainly, if it's so obvious, it shouldn't be hard to explain. >=20 > "Ideally, the prefix length of ::1/128 could be shortened, resulting = in a larger loopback prefix such as ::/48. However, if the existing = loopback prefix length is shortened enough to satisfy all of the larger = loopback prefix requirements, it would then cover the IPv4 Mapped IPv6 = Address prefix, ::ffff:0.0.0.0/96, and prevent its use described in = [RFC4038]." >=20 Yes, I read that. Restating it adds nothing to the discussion. You still = haven't said anything which supports your claim that this would somehow = be ideal." >=20 >=20 >> 6.fd00::/48 supports 64 bit IIDs. >> 7.fd00::/48 provides 65,536 /64 subnets. Is there some reason you = think this is insufficient? >> This is a total of 4 billion times 16.7 million times as many host = addresses as were provided >> in the IPv4 loopback. >>=20 >=20 > It is quite adequate, and the size I proposed in the first two drafts. = However, under 0000::/8, it's possible to make it a /32, because their = are 16 million of them. Since this draft is revisiting the original = ::1/128 decision, why not make every attempt that can be easily afforded = to avoid revisiting the IPv6 loopback prefix the 3rd time. "More than = enough" is better than "just enough" when cheap enough, as it saves = coming back for more.=20 >=20 For that matter, it's possible to make it a /16 or a /64, but I don't = see any justification for those numbers, either. I would argue that if you can't do it in 65,536 times 18 quintillion = loopback addresses, it probably won't fit in any host ever likely to be = manufactured within the useful lifetime of IPv6. OTOH, given how much we wish we could have revisited the absolutely = moronic choice to waste an entire /8 on IPv4 loopbacks, going to a /32 = seems likely to be equally moronic. While I personally think this is a = boondoggle to begin with, if it is to be adopted, I certainly thin a /48 = is so much more than enough that multiplying that mistake by 65,536 = makes no sense whatsoever. >>=20 >> It is 1/256th as many networks as IPv4 provided loopback hosts. >>=20 >>=20 >> 5. >> 3. Proposed Larger Loopback Prefix Ideally, the prefix length of = ::1/128 could be shortened, resulting in a larger loopback prefix such = as ::/48. However, if the existing loopback prefix length is shortened = enough to satisfy all of the larger loopback prefix requirements, it = would then cover the IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, = and prevent its use described in [RFC4038]. Giving up the requirement of = covering the existing loopback prefix, the proposed larger loopback = prefix is:=20 >>=20 >>=20 >>=20 >> So why not simply delete this from the requirements list as you've = failed to >> provide any justification for said requirement anyway. >=20 > Requirementlists define both wants and needs. It's there because more = than once people have asked why not just shorten the prefix length of = the existing prefix. Interesting=85 That was the part I considered obvious. I still don't see = any advantage to doing so vs. using space somewhere else. >=20 >> Smith Expires August 15, 2013 [Page = 4]=20 >> Internet-Draft A Larger IPv6 Loopback Prefix February = 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 = This prefix satisfies all remaining larger loopback prefix requirements. >>=20 >>=20 >> I think this is a terrible choice of location. It pretty much = maximizes the fragmentation damage that can be done by the choice of = prefix. :1::/32 would at least be the first /32 available. As I've = stated, a locally chosen address such as fd00::/48 (or whatever = selection of chosen ULA space meets local requirements) is equally = viable IMHO. >>=20 >=20 > The goal was the shortest thing to type, and I don't think = fragmentation matters within 0000::/8. I think people will commonly = forget the colon on the front of :1::/32, or mix up where the two = contiguous colons are e.g. they'll type ::1:/32. >=20 Good arguments against using 1::/32 as well. >>=20 >> 6. >> Allocating a /32 prefix for the loopback function may seem excessive, = as a /48 length prefix would satisfy the larger loopback prefix = requirements. However, within the parent 0000::/8 special purpose = prefix, there are approximately 16 million /32 prefixes, so a single /32 = for the larger loopback prefix is easily afforded. A /32 larger = loopback prefix will satisfy all current and likely future uses of the = loopback function. >>=20 >>=20 >> Allocating a /32 is absurdly excessive and just because we can does = not strike me as anything remotely resembling an argument that we = should. >>=20 >=20 > So you're saying that you can think of better uses for the 16 million = /32s within 0000::/8, such that just one can't be used for this purpose? = What are some of your better uses? >=20 No, but I am saying I'm willing to bet that other better uses for the = other 65,535 /48s in 1::/32 are not at all unlikely to come along. >>=20 >> 4. Address Assignment and Configuration=20 >>=20 >>=20 >> Consistent with the IPv6 addressing model [RFC4291], each address = within the larger loopback prefix is associated with one of the node's = interfaces, although not necessarily the same interface for all = addresses. This means that the node acts as though all addresses within = the larger loopback prefix have been configured on one or more = interfaces. Applications will accept packets destined to any of the = larger loopback prefix addresses, unless the application is bound to = specific larger loopback addresses. Typically the addresses will be = logically assigned to one or more virtual "loopback" interfaces, which = locally returns or loops outgoing packets back to the same node that = originated the packets. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> I believe you have misread and conflated RFC4291 and RFC1122 with = regards to how loopback >> addresses function. >>=20 >=20 > This is specifying the address assignment and configuration scheme for = the proposed larger loopback prefix. You have misread and misunderstood = this text. >=20 No, I didn't. However, you claim "Consistent with=85" and follow it with = a description which is not consistent. >>=20 >> Unless I am mistaken, there is no requirement in RFC1122 that a node = answer all addresses within 127/8. >>=20 >>=20 >> Some nodes may support more than one loopback interface. These = subsequent loopback interfaces, when initialised, should be assigned = Smith Expires August 15, 2013 [Page 5]=20= >> Internet-Draft A Larger IPv6 Loopback Prefix February = 2013 a larger loopback /64 prefix locally unique within the node. All = addresses within the assigned /64 are logically assigned to the = interface. Additionally, the ":1" address for the subnet should be = configured on the loopback interface, making it visible to a system = operator or user. >>=20 >>=20 >> This would, indeed, be new functionality. I am not convinced of any = value to having that functionality and it is radically different from = any required functionality in IPv4 today. In IPv4, hosts which support = multiple loopbacks have no default address or range on the subsequent = loopback interfaces. >>=20 >=20 > Right. The goal here is to take something useful in IPv4 that doesn't = exist in IPv6, and then to also see if there are opportunities to make = further improvements. This is not a literal copy of IPv4 functionality = into IPv6. Changes to fix limitations are also opportunities to make = improvements. >=20 My point is that the capability that exists in IPv4 today also exists in = IPv6 already. The only difference is the pool of addresses you have to = choose from for that purpose. In IPv4, you have, in addition to the = global unicast, RFC-1918, and in some circumstances, link local = addresses the normally unused addresses within 127/8. In IPv6, you are = limited to the ULA and GUA in addition to ::1/128. >>=20 >> If you cannot justify a need for this functionality, I see no point = in advancing it as a standard. >>=20 >=20 > I have justified it, in Abstract and the Introduction. You might not = believe there is a problem to solve, but that doesn't mean that other = people don't, and that they haven't experienced a problem. In addition = to myself, Erik Kline and Vijayrajan Ranganathan have encountered = situations where more IPv6 loopback addresses would be useful: >=20 Your justification isn't. The problem statements you have presented so = far can be solved without requiring software modifications to every IPv6 = stack. > http://www.ietf.org/mail-archive/web/v6ops/current/msg14815.html >=20 >=20 > http://www.ietf.org/mail-archive/web/ipv6/current/msg10882.html >=20 >=20 > Here is Erik, back in 2009, describing the exact scenario that I've = described in the Abstract and Intro. >=20 > http://www.ietf.org/mail-archive/web/ipv6/current/msg11018.html >=20 I'm not saying your problem shouldn't be solved. I'm saying that it = already has been. >=20 >=20 >=20 >>=20 >> It should be possible for an operator to remove these automatically = configured loopback addresses. It should also be possible for an = operator to configure further loopback addresses from within the = assigned /64, or addresses from other parts of the larger loopback = prefix, including other /64s assigned to other loopback interfaces. = Other addresses within the assigned /64(s) would continue to be = logically assigned to the subsequent loopback interface. Configuration = of addresses is for operational visibility and convenience, and does not = change the behaviour of non-visible logically assigned addresses. >>=20 >>=20 >> If you're going to do this, then I would argue that it "must" be = possible for an operator to remove=85 >>=20 >=20 > ok. I've tried to avoid being too absolute in this area because it's = describing operator/system interface functionality, rather than things a = compliant implementation must do. >=20 But you don't say that a compliant implementation must. As written, your = draft would allow a compliant implementation which did not allow = operator removal. I consider this highly undesirable. >=20 >>=20 >> The rest of what you suggest strikes me as being a kernel routing = hairball of unnecessarily large >> proportion and likely to engender more bugs than functionality. >>=20 >=20 > I'm curious as to what experience you have to be able to make that = judgement. Using Linux as an example IPv6 implementation, I know enough = about the Linux kernel networking code that I'm pretty sure it shouldn't = be too hard to make these changes. >=20 I know that most hosts today do not behave well and most routers won't = even allow you to configure overlapping prefixes and addresses on multiple interfaces. Admittedly, some of that is due to = the fact that the desired behavior is not defined anywhere, which = admittedly is addressed to some extent in your draft. However, even with = those definitions it still strikes me as being quite a mess both from a principle-of-least-surprise = perspective as well as a complexity for the sake of complexity perspective. Owen >=20 >>=20 >> ------ >>=20 >>=20 >> This covers the first 6 pages (approximately half of the draft). I'm = not going to take the time to write up the problems in the rest of the = draft at this point because the above are, IMHO, more than sufficient = reason to oppose adoption. >>=20 >>=20 >> Owen >>=20 >>=20 >> On Feb 12, 2013, at 4:18 PM, Owen DeLong wrote: >>=20 >>=20 >>> On Feb 12, 2013, at 12:33 PM, Mark Smith = wrote: >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>>=20 >>>> From: Owen DeLong >>>>> To: Mark Smith >>>>> Cc: Doug Barton ; "v6ops@ietf.org" = >>>>> Sent: Wednesday, 13 February 2013 6:59 AM >>>>> Subject: Re: [v6ops] New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>> ?? I don't see how it gets easier to remember than fd00::/8 >>>>>>>=20 >>>>>> The random bit is the hard bit to remember and type. I don't = think=20 >>>>>> you're thinking enough about how it is to use, you're only = thinking=20 >>>>> about how hard it is to configure. The time and effort to = configure something is=20 >>>>> usually minimal compared to the amount of time and effort spent = while it is=20 >>>>> being used. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>> Nothing requires you to use random for this purpose. Use fd00::/64 = for all=20 >>>>> anyone cares. >>>>>=20 >>>>>=20 >>>> RFC4193 does. It's not a ULA if it doesn't, it's been made a = site-local. See RFC3879 for the problems with them and your non-random = ULA. >>>>=20 >>>>=20 >>> Which is irrelevant to the loopback scenario you have described=85 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> and you can use=20 >>>>>>>=20 >>>>>>=20 >>>>>> anything you want inside of that to provide a /64 for your = development=20 >>>>>>> purpose. >>>>>=20 >>>>>=20 >>>>>>> What's more cumbersome about picking something (even fd00::/64, = if=20 >>>>>>> you want)=20 >>>>>=20 >>>>>=20 >>>>>> No, that's bad, as it is a ULA prefix which doesn't have a random=20= >>>>>> component. Add the random component (if you aren't lazy), and it = then=20 >>>>> becomes hard to remember and type. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>> Why is it bad that it doesn't have a random component? If it's in = a=20 >>>>> development test lab, it's not like it's at risk of corporate = merger=20 >>>>> conflicts, etc. >>>>>=20 >>>>>=20 >>>> See slide 26. >>>>=20 >>>> http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf >>>>=20 >>>>=20 >>> Which does not apply to use on a loopback interface. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> for development than having some other prefix you have to configure=20= >>>>>>> assigned by=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> the IETF. >>>>>>>=20 >>>>>> I'm starting to wonder if you've actually read the draft. The=20 >>>>>> intention is that it is that the larger loopback prefix = automatically configured=20 >>>>> at system initialisation, as ::1/128 and 127/8 currently are. = There is a whole=20 >>>>> section on automatic address assignment and configuration. >>>>>=20 >>>>> 127/8 isn't auto-assigned. 127.0.0.1/8 is. >>>>>=20 >>>>>=20 >>>> That's incorrect. >>>>=20 >>>> RFC1122, "Requirements for Internet Hosts -- Communication Layers", = specifically the in >>>>=20 >>>> "(g) { 127, } >>>> Internal host loopback address. Addresses of this form MUST NOT = appear outside a host." >>>>=20 >>>>=20 >>> Yes, it requires that you not have addresses within 127.0.0.0/8 = appear outside of the host. It does >>> not require the host to answer or auto configure all of the = 127.0.0.0/8 addresses on its loopback >>> interface and, indeed, most hosts do NOT auto configure other than = 127.0.0.1. >>>=20 >>>=20 >>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>>>>> Sorry, but I just don't get it. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> This proposal also takes the opportunity to introduce IPv4-like=20= >>>>>>>> handling of=20 >>>>>=20 >>>>> loopback IPv6 packets so that future functions similar to the use = in=20 >>>>>>> RFC4379=20 >>>>>=20 >>>>> have a native IPv6 address space to use, rather than using 127/8 = within=20 >>>>>>> an IPv6=20 >>>>>=20 >>>>> prefix. >>>>>>>=20 >>>>>>> In my (admittedly limited) testing, putting a /64 of ULA on the=20= >>>>>>> loopback=20 >>>>>=20 >>>>> interface did just that, so I'm not sure what it is that you feel=20= >>>>>>> is=20 >>>>>=20 >>>>> missing. >>>>>>>=20 >>>>>>>=20 >>>>>> All addresses within 127/8 are valid and available on the host, = where as=20 >>>>>> with your ULA, only 1 is. >>>>>=20 >>>>>=20 >>>>>> e.g. >>>>>>=20 >>>>>>=20 >>>>>> [root@opy mark]# ip addr show dev lo >>>>>> 1: lo: mtu 65536 qdisc noqueue state = UNKNOWN=20 >>>>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >>>>>> inet 127.0.0.1/8 scope host lo >>>>>> inet6 fd00:db8::1/64 scope global=20 >>>>>> valid_lft forever preferred_lft forever >>>>>> inet6 1::1/64 scope global=20 >>>>>> valid_lft forever preferred_lft forever >>>>>> inet6 ::1/128 scope host=20 >>>>>> valid_lft forever preferred_lft forever >>>>>>=20 >>>>>> [root@opy mark]# ping -c 1 127.1.2.3 >>>>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>>>>> 64 bytes from 127.1.2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 ms >>>>>>=20 >>>>>> --- 127.1.2.3 ping statistics --- >>>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms >>>>>> rtt min/avg/max/mdev =3D 0.053/0.053/0.053/0.000 ms >>>>>> [root@opy mark]#=20 >>>>>>=20 >>>>>>=20 >>>>> Interesting=85 I get this behavior on MacOS. >>>>>=20 >>>>> [tc01-dhcp153:~] owen% ifconfig lo0 >>>>> lo0: flags=3D8049 mtu 16384 >>>>> options=3D3 >>>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 >>>>> inet 127.0.0.1 netmask 0xff000000=20 >>>>> inet6 ::1 prefixlen 128=20 >>>>>=20 >>>>> [tc01-dhcp153:~] owen% ping 127.1.2.3 >>>>> PING 127.1.2.3 (127.1.2.3): 56 data bytes >>>>> Request timeout for icmp_seq 0 >>>>> Request timeout for icmp_seq 1 >>>>> Request timeout for icmp_seq 2 >>>>> Request timeout for icmp_seq 3 >>>>> ^C >>>>> --- 127.1.2.3 ping statistics --- >>>>> 5 packets transmitted, 0 packets received, 100.0% packet loss >>>>>=20 >>>>>=20 >>>> So MacOS isn't compliant with RFC1122. >>>>=20 >>>>=20 >>> How do you figure that? You'll need to be more specific. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Admittedly, Linux does this: >>>>>=20 >>>>> owen.delong.com:owen /home4/owen (22) % ifconfig lo >>>>> lo Link encap:Local Loopback =20 >>>>> inet addr:127.0.0.1 Mask:255.0.0.0 >>>>> inet6 addr: ::1/128 Scope:Host >>>>> UP LOOPBACK RUNNING MTU:16436 Metric:1 >>>>> RX packets:45816328 errors:0 dropped:0 overruns:0 frame:0 >>>>> TX packets:45816328 errors:0 dropped:0 overruns:0 = carrier:0 >>>>> collisions:0 txqueuelen:0=20 >>>>> RX bytes:578712867 (551.9 MiB) TX bytes:578712867 (551.9 = MiB) >>>>>=20 >>>>> owen.delong.com:owen /home4/owen (23) % ping 127.1.2.3 >>>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>>>> 64 bytes from 127.1.2.3: icmp_seq=3D1 ttl=3D64 time=3D0.043 ms >>>>> 64 bytes from 127.1.2.3: icmp_seq=3D2 ttl=3D64 time=3D0.032 ms >>>>> 64 bytes from 127.1.2.3: icmp_seq=3D3 ttl=3D64 time=3D0.019 ms >>>>> ^C >>>>> --- 127.1.2.3 ping statistics --- >>>>> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms >>>>> rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 ms >>>>> owen.delong.com:owen /home4/owen (24) %=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> [root@opy mark]# ping6 -c 1 fd00:db8::2 >>>>>>=20 >>>>>> connect: Network is unreachable >>>>>> [root@opy mark]# >>>>>>=20 >>>>>> [mark@opy ~]$ ssh 127.1.2.3 >>>>>> The authenticity of host '127.1.2.3 (127.1.2.3)' can't be=20 >>>>>> established. >>>>>=20 >>>>>=20 >>>>>> [mark@opy ~]$ ssh -6 fd00:db8::2 >>>>>> ssh: connect to host fd00:db8::2 port 22: Network is unreachable >>>>>> [mark@opy ~]$ >>>>>>=20 >>>>>>=20 >>>>> =46rom what I can see, this seems to depend on a pathology not = universally=20 >>>>> available even in IPv4. >>>>>=20 >>>>>=20 >>>>> Another test you should do to measure the usefulness of this = proposal is=20 >>>>>> see how long it takes and your opinion afterwards of how hard or = easy it is to=20 >>>>> type or cut and paste "fd00:db8::1" vs "1::1" a reasonable=20 >>>>> number of times e.g. 6 times. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>> I'm fine with it. If you're doing it more than 6 times, that's = what=20 >>>>> DNS is for. >>>>>=20 >>>>>=20 >>>> That's an option, for applications that use DNS to resolve = addresses. There are applications that need to deal with addresses = directly, such as mine, due to their nature and purpose. >>>>=20 >>> Then use a configuration file or whatever. There are lots of = alternatives to repeatedly typing in addresses. >>> (command-line aliases come to mind as an example). >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>>> Using a ULA doesn't really work at all. It only adds another = address to=20 >>>>>> the host, rather than many. A properly formed ULA is hard to type = and remember.=20 >>>>> It's far less user friendly than the short larger loopback prefix = I'm=20 >>>>> proposing. This is based on my experience, as I've used a ULA for = the=20 >>>>> purpose of trying to increase the number of loopback IPv6 = addresses. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>> The same is true with loopback except on Linux as near as I can = tell. >>>>>=20 >>>>>=20 >>>> Windows 7 also behaves this way, as it complies with RFC1122. >>>>=20 >>>>=20 >>> Nothing I found in RFC 1122 requires this, so if you think something = does, you'll >>> need to point it out. >>>=20 >>> I know for a fact that several Cisco switches did not. For example, = they used to use >>> 127.0.0. as a convenient hack for connections across = the backplane >>> to the IP stack running on IP-aware blades such as RSMs. >>>=20 >>>=20 >>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>> Note, I don't know the answer, but I'm leaning heavily=20 >>>>>>>>> towards,=20 >>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> "no." >>>>>>>>>=20 >>>>>>>>> Primarily because we're asking people to deploy this=20 >>>>>>>>> protocol for=20 >>>>>=20 >>>>> real-world scenarios, and we already have a pretty wide=20 >>>>>>>>> divergence in=20 >>>>>=20 >>>>> the latest state of the standards vs. the oldest working=20 >>>>>>>>> deployed base.=20 >>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> Widening that gap should only be done for truly critical=20 >>>>>>>>> changes, and=20 >>>>>=20 >>>>> I'm not sure you've made your case sufficiently. >>>>>>>>>=20 >>>>>>>>> Put more simply, at some point we have to stop tinkering with=20= >>>>>>>>> the plane=20 >>>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>> while it's in the air. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>> So I think the implication of that analogy is that deploying = this=20 >>>>>>>> enhancement will somehow interrupt the existing operation of = IPv6=20 >>>>>>> implementations ("the plane") causing them to fail=20 >>>>>>> ("fall out of=20 >>>>>=20 >>>>> the sky"). I don't see how that will be the case. Deploying a=20 >>>>>>> new=20 >>>>>=20 >>>>> loopback prefix would leverage many of the existing address=20 >>>>>>> configuration and=20 >>>>>=20 >>>>> loopback related functions of existing IPv6 implementations. It is = not=20 >>>>>>> much more=20 >>>>>=20 >>>>> than a larger version of ::1/128. >>>>>>>=20 >>>>>>> The implication is that you are requesting to once again = obsolete all=20 >>>>>>> existing=20 >>>>>=20 >>>>> implementations in favor of requiring deploying another = fundamentally=20 >>>>>>> changed=20 >>>>>=20 >>>>> IPv6 stack. >>>>>>>=20 >>>>>> Can you define the threshold of "fundamentally changed" for me? >>>>>>=20 >>>>>>=20 >>>>> Requiring a modification to every existing IPv6 stack in the wild = which could be >>>>> incorporated into software dependencies which would render = existing stacks=20 >>>>> unexpectedly >>>>> obsolete. >>>>>=20 >>>>>=20 >>>>> I don't consider this to be a fundamental change. It is adding = another=20 >>>>>> loopback prefix, which operates the same as the existing one, = just with a=20 >>>>> shorter prefix length. It is adding values to the source and = destination address=20 >>>>> selection policy, which is already possible to do because it's = been designed=20 >>>>> that way. I'm quite confident that it is going to be no more than = 10 lines,=20 >>>>> and probably closer to 5 additional lines of code in a stack for a = host=20 >>>>> implementation that only supports a single loopback interface. = That's code=20 >>>>> change size closer to the size of bug fixes than additional = functionality. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>> So you want to force everyone to update their IPv6 stack on every = host, router,=20 >>>>> switch, etc. just so you can save some typing? >>>>>=20 >>>>>=20 >>>> The IETF (and I) can't force anything. If it's useful, it'll be = implemented. >>>>=20 >>>>=20 >>> IMHO, it's not all that useful and making it a stack requirement = would lead to one of two bad situations: >>>=20 >>> 1.Development resources would be taken away from tasks that matter. >>> or >>> 2.Increasing divergence between the implemented stacks and the = documented standards. >>>=20 >>>=20 >>>=20 >>> You're doing a very good job cementing my opposition here. >>>>>=20 >>>>>=20 >>>> You seem to like doing things the hard way. My view is computers = should do things automatically for people so that people can get on with = more valuable things. Developers should be cutting code instead of = setting up development environments, or waiting for system = administrators to set up the development environment for them. >>>>=20 >>>>=20 >>> Actually, I do not. However, I do not believe in using the entire IP = stack development community as a workforce to save me a little bit of = typing which, as near as I can tell is all that this proposal would = accomplish. >>>=20 >>> The functionality you seek is available using ULA. The issues you = cite with ULA would not apply to loopback usage. The functionality that = you attribute to RFC 1122 isn't (as near as I can tell) actually = codified into RFC 1122 (I don't see how requiring that an address range = not appear outside of a host requires that host to accept all packets to = any address in said range, which is what you are claiming). >>>=20 >>>=20 >>> My definition of a fundamental change would be to do something like = change=20 >>>>>> the change the size of the IPv6 address, or reorder the fields in = the IPv6=20 >>>>> header. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>> That would be a drastic change, indeed. This is less drastic, but = it would make=20 >>>>> current IPv6 stacks incompatible with the protocol definition. >>>>>=20 >>>>>=20 >>>> I don't get this. 1::/32 is not currently used for anything, so = using it is not going to make it incompatible with anything. Using other = prefixes for purposes that they weren't designed for, such as a ULA as a = loopback, has far greater risk of creating incompatibility.=20 >>>>=20 >>> If you add this as a required stack feature, stacks which don't = implement the feature are no longer compliant. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> The question is whether there is enough value in the change to=20 >>>>>>> justify such a decision and IMHO, at this point, just to make it=20= >>>>>>> "less=20 >>>>>=20 >>>>> cumbersome" than putting (a) ULA address(es) on the loopback=20 >>>>>>> interface=20 >>>>>=20 >>>>> strikes me as not having much value. >>>>>>>=20 >>>>>>>=20 >>>> You don't seem to be placing any value convenience. Does your car = have an automatic transmission? Do you have a dishwasher? Do you go to = restaurants? All of those things only exist because humans place value = on the convenience of not manually changing gears, not manually washing = dishes, and not cooking at home when we could. Why have to do something = manually when a computer could do it automatically for you? >>>>=20 >>>>=20 >>> I place tremendous value on convenience. My car does not have a = traditional automatic transmission, my car has an ECVT transmission. If = I were buying a car, I would actually prefer a manual transmission = because I prefer the greater control flexibility and shifting precision = afforded by a manual transmission. >>>=20 >>> Yes, I go to restaurants. >>>=20 >>> There are many equally automatic solutions to your problem already = available without involving the entire body of protocol developers and = the IETF in the process. >>>=20 >>> Owen >>>=20 >>>=20 >>> Owen >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Mark. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Doug >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 02/11/2013 01:37 PM, David Farmer wrote: >>>>>>>>>=20 >>>>>>>>> On 2/11/13 14:28 , Owen DeLong wrote: >>>>>>>>>>=20 >>>>>>>>>> Perhaps I'm not very bright, but is there any=20 >>>>>>>>>>> reason ULA=20 >>>>>=20 >>>>> couldn't be >>>>>>>>>=20 >>>>>>>>> used on the LO interface to >>>>>>>>>>> satisfy this corner case? >>>>>>>>>>>=20 >>>>>>>>>> The Draft does cover why ULA is thought to not be a=20 >>>>>>>>>> sufficient=20 >>>>>=20 >>>>> solution, >>>>>>>=20 >>>>>>> do you disagree with the reasoning in the draft? >>>>>>>>>>=20 >>>>>>>>>> from Section 1; >>>>>>>>>>=20 >>>>>>>>>> A Unique Local IPv6 Unicast Address (ULA) prefix=20 >>>>>>>>>> [RFC4193]=20 >>>>>=20 >>>>> could be >>>>>>>=20 >>>>>>> used to increase the number of addresses available on=20 >>>>>>>>>> the=20 >>>>>=20 >>>>> local host. >>>>>>>=20 >>>>>>> However this prefix would need to be manually=20 >>>>>>>>>> generated and >>>>>=20 >>>>> configured at least once by a system administrator or=20 >>>>>>>>>>=20 >>>>>=20 >>>>> operator. >>>>>>>=20 >>>>>>> Without additonal configuration, traffic towards=20 >>>>>>>>>> addresses not >>>>>=20 >>>>> assigned to the local host would not be prevented=20 >>>>>>>>>> from leaving=20 >>>>>=20 >>>>> the >>>>>>>=20 >>>>>>> host, and access may not be limited to the local=20 >>>>>>>>>> host. A ULA=20 >>>>>=20 >>>>> prefix >>>>>>>=20 >>>>>>> would not be well known, and would not be convenient=20 >>>>>>>>>> to=20 >>>>>=20 >>>>> remember and >>>>>>>=20 >>>>>>> type without violating the randomness requirements of=20 >>>>>>>>>> the=20 >>>>>=20 >>>>> Global ID >>>>>>>=20 >>>>>>> component of a ULA prefix. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Owen >>>>>>>>>>>=20 >>>>>>>>>>> On Feb 11, 2013, at 12:20 , Mark Smith=20 >>>>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> Here is a new version of my IPv6 larger loopback=20 >>>>>>>>>>>> prefix=20 >>>>>=20 >>>>> draft. >>>>>>>=20 >>>>>>> Changes since the previous version: >>>>>>>>>>>>=20 >>>>>>>>>>>> o default address selection precedence and label=20 >>>>>>>>>>>> values >>>>>=20 >>>>> o comment about other IPv4 in IPv6 address forms >>>>>>>>>>>>=20 >>>>>>>>>>>> o more clarifications >>>>>>>>>>>>=20 >>>>>>>>>>>> o grammar corrections >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> My thanks to Bill Atwood, Matts Kallioniemi and=20 >>>>>>>>>>>> Tina Tsou=20 >>>>>=20 >>>>> for their >>>>>>>=20 >>>>>>> review and comments on this revision. >>>>>>>>>>>>=20 >>>>>>>>>>>> Further review and comments would be most=20 >>>>>>>>>>>> appreciated. >>>>>=20 >>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Mark. >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> v6ops mailing list >>>>>>>>> v6ops@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>> v6ops mailing list >>>>>>>> v6ops@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >>=20 >>=20 From geir.egeland.ietf@gmail.com Wed Feb 13 03: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 167F821F8632 for ; Wed, 13 Feb 2013 03:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.221 X-Spam-Level: *** X-Spam-Status: No, score=3.221 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=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 ohhiAvVyzXge for ; Wed, 13 Feb 2013 03:37:09 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 12EE821F862E for ; Wed, 13 Feb 2013 03:37:08 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so1067395lab.13 for ; Wed, 13 Feb 2013 03:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=Vl9nkYQhn6Ba6PeTHSheXvOKqxQLempfxecqDqonJJM=; b=APmE8HEKu5wGVHK71txgA9dKXVbcJuuU7QDSnsBka01X31QvRLSOEKsAxy3hxI0RlR 7VsDga8WEbFIyiP1x2iMDUqS92uLy+6A9o1LVWc2B+vQCmMnNXdYFU37FTUw9BnYsw7X Q5V94GlGvvqZ63XyOQ2K3vfBjfRtfsrwrZB6d0lpHYsALAHi9o2ybQYLUgZSc6A1PWkw wnvNqZ/dydrWd9aEmQmQ8DQlStcScdU4PqTUCEVzuVg8Wngw+dCIXp7xJxBKVaipvh0k +9mMsJIgZaB4cFThpNLu0qkpLe3VNZXw+Zb6V7gUgSKyzFZA8x4BwI+kAEOhrdrq1Eco eqLw== X-Received: by 10.152.110.116 with SMTP id hz20mr10732958lab.18.1360755428043; Wed, 13 Feb 2013 03:37:08 -0800 (PST) Received: from [172.20.10.2] (2.150.17.146.tmi.telenormobil.no. [2.150.17.146]) by mx.google.com with ESMTPS id fz16sm6397824lab.5.2013.02.13.03.37.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 03:37:07 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geir Egeland In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> Date: Wed, 13 Feb 2013 12:15:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <788406EC-28E0-428E-9808-ADE0F49F39BC@gmail.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <1808340F7EC362469DDFFB112B37E2FCC6CFA33B99@SRVHKE02.rdm.cz> To: =?windows-1252?Q?V=EDzdal_Ale=9A?= X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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, 13 Feb 2013 11:37:10 -0000 Hi, Speaking as a mobile operator I support this document. =20 Personally, I do not feel comfortable having references to 3GPP TS = documents in an IETF requirements document. I am aware that this has = been done in other RFCs, but requirements on PDP contexts handling = should IMHO be left to 3GPP (REQ 2&3). If this document gets accepted = and the WG insists on keeping the 3GPP stuff, we should at least = specify the exact section in the TS we are refering to. Geir Egeland Telenor Group/Norway On 01-02-13, at 12:43 , V=EDzdal Ale=9A wrote: > Hi, >=20 > speaking as an Operator (not as a co-author) working on IPv6 = introduction in Mobile. >=20 > I see this document useful as it >=20 > * defines a cellular IPv6 profile not yet specified anywhere = else > * goes behind the 3GPP architecture using NAT64, 464xlat, etc. = features that are not part of the 3GPP architecture > * can serve as basis for testing / validation later on >=20 > As IPv6 has been 'invented' by the IETF, it seems to me to be the = right place to look into=20 > what IPv6 means for these devices (as has already been done for CPEs = in 6204, IPv6 Nodes=20 > in 6434). >=20 > Secondly, this group has the right skill set required for such a work. >=20 > Ales >=20 >> -----Original Message----- >> From: joel jaeggli [mailto:joelja@bogus.com] >> Sent: Wednesday, January 30, 2013 8:19 PM >> To: IPv6 Ops WG; = draft-binet-v6ops-cellular-host-requirements@tools.ietf.org >> Subject: Test for adoption as a working group document - Re: I-D = Action: draft-binet- >> v6ops-cellular-host-requirements-02.txt >>=20 >> Greetings, >>=20 >> This kicks of a request for adoption as a working group document on >> draft-binet-v6ops-cellular-host-requirements-02.txt >>=20 >> This document and a similar one were discussed during IETF 85 and = were >> updated accordingly. Support was far from unanimous at the time and >> we're interested in seeing how far it has progressed. >>=20 >> The deadline for this discussion phase is two weeks from today, 2/13. >>=20 >> thanks >> joelja >>=20 >> On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : Internet Protocol Version 6 (IPv6) = Requirements for Cellular Hosts >>> Author(s) : David Binet >>> Mohamed Boucadair >>> Ales Vizdal >>> Cameron Byrne >>> Gang Chen >>> Filename : = draft-binet-v6ops-cellular-host-requirements-02.txt >>> Pages : 17 >>> Date : 2013-01-30 >>>=20 >>> Abstract: >>> This document lists a set of IPv6-related requirements to be >>> supported by cellular hosts. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requireme= nts >>>=20 >>> There's also a htmlized version available at: >>> = http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-02= >>>=20 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-require= ments-02 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From geir.egeland.ietf@gmail.com Wed Feb 13 04:08: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 3C7B521F8838 for ; Wed, 13 Feb 2013 04:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.065 X-Spam-Level: * X-Spam-Status: No, score=1.065 tagged_above=-999 required=5 tests=[AWL=2.156, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, 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 NXFWltlvvHQD for ; Wed, 13 Feb 2013 04:08:44 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 60B6A21F8837 for ; Wed, 13 Feb 2013 04:08:44 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id q12so891864lbc.11 for ; Wed, 13 Feb 2013 04:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=Sud0VIeYXVBV0mJL8Rtir22OTBrFWaDp7Oeyy8N7FiA=; b=ziqd9QUK1r+kQixOFqS6Ma1BNLOFL62SylQcLccli2r/OqT/o5ctp2M6zj8mMOoJBB bywZbIsbz40ClGFV49Ntv/gxevyuGyVKuueeG56sUoaSPF5sIXS9jQ0iDkLKY+CcTYZ0 SWk7WjFP9YQrcEdKeAIaT2g/JHzNaqltAZAfPf7gRGMX5mBT/2bjWJoOspuj719jXJJD lPpf9s5fkQELn5UN1bJBlgvul9tbXD+HBYSjKDZkkNGXqnD8+3FgljPSFI3RbnCHZJCE twbGMbaQSjDWR8sOKk3OSmd/sgJ8Ju8ctWE26G5XABuWMBh+Hw5QJUh8pWmShk6ZP6eb 2zxQ== X-Received: by 10.152.136.20 with SMTP id pw20mr19702950lab.16.1360757323284; Wed, 13 Feb 2013 04:08:43 -0800 (PST) Received: from [172.20.10.2] (2.150.17.146.tmi.telenormobil.no. [2.150.17.146]) by mx.google.com with ESMTPS id mq7sm8086846lab.1.2013.02.13.04.08.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 04:08:42 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geir Egeland In-Reply-To: Date: Wed, 13 Feb 2013 13:08:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86605002-4988-45F1-8177-F122C9D10CF6@gmail.com> References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Feb 2013 12:08:45 -0000 On 04-02-13, at 17:43 , Mikael Abrahamsson wrote: > On Mon, 4 Feb 2013, Alexandru Petrescu wrote: >=20 >> A parallel could be drawned between the GPRS-3G migration and 3G-LTE, = in terms of IP family of protocols. If I remember correctly, the GPRS = deployment was IPv4 NAT and one had to wait for 2nd generation 3G = deployments to see publicly routable IPv4 addresses and IPv6 in test. = Maybe now we wait the same - a second or 3rd generation LTE deployment = to see publicly routable IPv4 and IPv6. >=20 > This is really weird. >=20 > Personally, I'm trying to get 2G/3G/4G equal service with proper = establishment and handover between the networks for a IPv4v6 PDP = context. You are not the only one... >=20 >> So, I personnally wait for the following, in this order: >> - 3G network to become IPv6 for everybody >> - LTE network to become IPv4 publicly routable addresses >> - LTE network to become IPv6 as test >> - LTE network to become IPv6 for everybody >> All this maybe in 3-6 years time. At that time we'd talk 5G already = I >> believe. >=20 > Doing IPv4v6 on LTE is not that much of a problem, that's doable today = (my experience). Getting the same IPv4v6 so the customer can establish a = IPv4v6 PDP context in 3G, handing over to 4G and back to 3G, that's = where it gets interesting. :P >=20 > For me 2G/3G/4G are different access technologies that should be = transparent to the user, they should offer the same services just at = increasingly higher speeds. This is our approach as well and I think many european operators have a = similar 3G/LTE business model. >=20 > IPv6 only access on 2G/3G/4G is also doable (there are quite a few = phones and usb dongles that do this), the problem is that IPv6 only + = NAT64 gives a lousy end user experience without 464XLAT, so that's a = no-go. Some mobile terminals with IPv4v6 PDP support would be nice=85=85terminal = vendors, - any input here please? Geir Egeland Telenor Group/Norway >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nordmark@acm.org Wed Feb 13 10:50: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 BFEE121F86CB for ; Wed, 13 Feb 2013 10:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ1vaqnu9lZF for ; Wed, 13 Feb 2013 10:50:31 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id EB49C21F86C8 for ; Wed, 13 Feb 2013 10:50:27 -0800 (PST) Received: from [10.154.212.59] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r1DIoO8b014608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 10:50:25 -0800 Message-ID: <511BE070.3000607@acm.org> Date: Wed, 13 Feb 2013 10:50:24 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sander Steffann References: <6EBC0E51-51B2-4749-AD05-BCF4CAC8213B@steffann.nl> In-Reply-To: <6EBC0E51-51B2-4749-AD05-BCF4CAC8213B@steffann.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Feb 2013 15:13:39 -0800 Cc: Leo Baltus Subject: Re: [v6ops] Source address selection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Feb 2013 18:50:31 -0000 On 2/11/13 9:23 AM, Sander Steffann wrote: > Now the incoming requests are no problem at all. The problem is with the source address selection when the boxes initiate a connection. We want outgoing connections to always use the iron address as default source address. Using one of the service addresses is undesirable for several reasons: > - If the address is load balanced then initiating outbound connections from that address will break as return traffic might be load balanced to one of the other boxes I'm surprised that you want to use the common iron address for outbound connections. Where I've though about this it seems more natural for service A to use the A address as a source address for outbound connections. FWIW the second problem can be solved by using things like LXC. > Based on this it seems that making all service addresses deprecated immediately and leaving the iron address as the only preferred address would be the only way to solve this. It does feel like a hack though. RFC 4862 says that "an address becomes "deprecated" in anticipation that its current interface binding will become invalid". These addresses are not anticipated to become invalid for a very long time (= indefinite). I can already imagine a kernel deciding to free up some resources by dropping addresses that are marked as deprecated for example. I'd stay away from overloading the preferred/deprecated notions for these purposes. That information is typically under the control of the protocols, be it DHCPv6 or stateless address autoconfig. Even if you use static IPv6 address assignment today (hence can "borrow" the deprecated state), you'd loose the option to use DHCPv6 or SLAAC tomorrow. And there is a risk that implementations have issues where even static addresses might be affected by the router advertisements. Hence I think you should use something different. > So: does anybody have any advice on this? Is it safe/future-proof/etc to mark addresses as deprecated to avoid them being used as default source addresses? Do we need some other way to steer the default source address selection procedure? Or is the only 'official' way to give each and every /128 its own label (so that rule 6 becomes equal to rule 1 for service addresses)? How many applications need to do the right thing for outbound connections? Do they all need to do the same (use the iron address), or do some need to use the iron address and others the service address? Depending on the above it may or may not make sense to tweak the applications and not rely on the stack to pick the source address. Regards, Erik From markzzzsmith@yahoo.com.au Wed Feb 13 22:15: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 047AF21F84D3 for ; Wed, 13 Feb 2013 22:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.014 X-Spam-Level: *** X-Spam-Status: No, score=3.014 tagged_above=-999 required=5 tests=[AWL=-1.287, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCK7oG7aZJ0T for ; Wed, 13 Feb 2013 22:15:44 -0800 (PST) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by ietfa.amsl.com (Postfix) with ESMTP id DCCE621F84CC for ; Wed, 13 Feb 2013 22:15:43 -0800 (PST) Received: from [98.139.212.145] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 14 Feb 2013 06:15:43 -0000 Received: from [98.139.212.249] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 14 Feb 2013 06:15:42 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 14 Feb 2013 06:15:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 980143.59156.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 4886 invoked by uid 60001); 14 Feb 2013 06:15:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1360822542; bh=bbbtI+HC/6fSSiaIvwmR27yZrzKb6I6g6F4y+KxveK0=; 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=k2MeIVHOZEaDlyETFGZEIIXNfC7kyRu8WfFbLnUXBxCw7vq1FDbfEZx8XQh8PziwTWYaRn3J4f0u76PeALwy9I8pDzo1qft/IhByax736HzW8kEw55eDiOJYn0C85V3lk+nfLaS/iPceJdAaGUWnzsEfH4hwVqUm0P3NXie29I4= 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=GGYQJytqbIjDqKgf+lQ5sdcE27LQdvMtH2Td/VYwYgJOvp99xtZ5WPAZIDsmQUXfgR/y3y77if2FN2PcsDI799x/Y8wzwpkxqp0DsmIO43X6/jbZcg1m8I7SdN7zynfESNJWkpJdR60nnloxnuuTBtVMopCjbdVEL3yrGxTufN4=; X-YMail-OSG: 3TVREy0VM1n.z.LOr1B9IoEZNpEzy59QFHixdQy8QdbY38b aAPtV_Iiuc2DlcNY5Oxqo3_zTl8i8xJ08olP7wZXcWccdr02x7IXzmRapTi4 btWJPDLznF.Fa9HB98vEo5rPJpxVD9dMU61CDEzyRROBd1_QxGM8aRxcOGOk QNYF5.eVO3Gk6NN9Gbcr7OemzY.sV3pkhj1FcDF4TTsqZ8xeJ83HiXl2HSAs IdjAtHK6VUSkjoS0DxGlAeyQMKH.CeBcjEOA8UcyhOjGiB.ll56SN_WaNCge 2oCrM1eEUYDOo7qNezUS47dPCfw0R5rbzigjHDMlnfDSm6MosnDCSMaHay2q rrf39gUc5.gR5deqMBJqiRNA66UT7xZd8ETqpFPHi1kwG9DA.nSeDy_F_.SY TQbmWfevJFaKigXRXMTE_OkEKL1TEscrcCzWT6aH0Vb3RKJPWaaO823JeG3y WuMXRK4FwaXxhe30tgHtDj.z1GIFrexES3Wj1utkJv46H.rBIMcaaWxIZ4eM Yf0rrZVqjFCG5qE65Cy4OPL3NmtQi5Z.ZHqNJ7zsX3n0Z8kEoJ2Yg.oHp2eI ii6qiQnXtDfP26mlnXv_KdEbDdgXnSuYk7bAbFq2ib6xgJTjAX5Ja1YEsT1T 42tybL3yYW76MXGrN7fxF_WQ1lethq_NkA_eypoFbshocIosxOZJDlEnSeGY - Received: from [121.200.231.211] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 13 Feb 2013 22:15:42 PST X-Rocket-MIMEInfo: 001.001, U28geW91J3ZlIHJlc29ydGVkIHRvIGluc3VsdHMuIEkgaWdub3JlIHBlb3BsZSB3aG8gcmVzb3J0IHRvIGluc3VsdHMsIGJlY2F1c2UgdGhleSd2ZSBjbGVhcmx5IHJ1biBvdXQgb2YgYWN0dWFsIHBvaW50cyBvZiBhcmd1bWVudCwgYW5kIHdvbid0IGFjY2VwdCB0aGF0IG90aGVyIHBlb3BsZSBoYXZlIGFuZCBjYW4gaGF2ZSBkaWZmZXJlbnQgb25lcy4KCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbT4KPiBUbzogTWFyayBTbWl0aCA8bWEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> <1360742992.43052.YahooMailNeo@web142505.mail.bf1.yahoo.com> <7CF3EA92-AEB2-42C2-949E-951E2C471686@delong.com> Message-ID: <1360822542.4513.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 13 Feb 2013 22:15:42 -0800 (PST) From: Mark Smith To: Owen DeLong In-Reply-To: <7CF3EA92-AEB2-42C2-949E-951E2C471686@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 06:15:47 -0000 So you've resorted to insults. I ignore people who resort to insults, becau= se they've clearly run out of actual points of argument, and won't accept t= hat other people have and can have different ones.=0A=0A=0A----- Original M= essage -----=0A> From: Owen DeLong =0A> To: Mark Smith =0A> Cc: v6ops v6ops WG =0A> Sent: = Wednesday, 13 February 2013 8:57 PM=0A> Subject: Re: [v6ops] New Version No= tification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A> =0A= > =0A> On Feb 13, 2013, at 12:09 AM, Mark Smith = =0A> wrote:=0A> =0A>>> ________________________________=0A>>> From: Owen= DeLong =0A>>> To: Mark Smith = =0A>>> Cc: "v6ops@ietf.org" =0A>>> Sent: Wednesday, 13 = February 2013 12:46 PM=0A>>> Subject: Re: [v6ops] New Version Notification= for =0A> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A>>> =0A>>>= =0A>>> I had actually read it, but, since you insist=E2=80=A6=0A>>> =0A>>= > =0A>> =0A>> I think it is an obligation of being a member of this mailin= g list if you =0A> are going to disagree with parts of an ID publicly. =0A>= > =0A> =0A> As I said, I had actually read it. In spite of your claim that = I hadn't. =0A> While my subsequent post was more detailed than my previous = arguments, I do not =0A> think any of my previous arguments were in any way= inconsistent with the =0A> subsequent more=0A> detailed post.=0A> =0A>>> = =0A>>> 1.=0A>>> Under IPv4, the 127/8 loopback prefix [RFC1122] provides = many=0A>>> addresses that can be used to run multiple instances of an appl= ication =0A> on the same port, while also limiting access to the local host= .=0A>>> =0A>>> =0A>>> RFC1122 provides that 127/8 cannot appear outside of= a host. It does =0A> not require that the host process all addresses withi= n 127/8 as you describe.=0A>>> =0A>> =0A>> You're right it doesn't say tha= t. It is common convention to do so, =0A> and has been a useful one to me a= nd others. I will change the text to reflect =0A> that it is a common conve= ntion.=0A>> =0A> =0A> I don't know how common that convention is. We've ide= ntified only 2 =0A> operating systems that actually do so as yet. I don't k= now what the behavior =0A> in other BSD derivatives, embedded operating sys= tems, etc. is. Certainly it is =0A> not common enough that I would consider= counting on it a good strategy for =0A> portable code.=0A> =0A>>> =0A>>> = 2.=0A>>> Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a= =0A> single address.=C2=A0 Multiple application instances using the same p= ort, bound to =0A> different loopback addresses, is not possible. =0A>>> = =0A>>> =0A>>> Is not true. You can configure additional addresses on to th= e loopback =0A> interface as desired and use them just as you would additio= nal addresses from =0A> the 127/8 address range. Since RFC1122 does not req= uire that the host treat all =0A> these addresses identically as you assume= , there is no difference between the =0A> current standards in IPv6 and the= current standards in IPv4 except that IPv4 =0A> sets aside a dedicated 16.= 7 million host addresses for this purpose (of which =0A> only one is utiliz= ed in most cases) and IPv6 sets=C2=A0 aside 1. However, you are =0A> free t= o assign any GUA or ULA prefix to the IPv6 loopback and use it in the same = =0A> manner as you are currently using the other 127/8 addresses.=0A>>> =0A= >> =0A>> I think you're choosing to misread this two sentence paragraph. N= ormal =0A> English convention is that sentences subsequent to the first in = a paragraph are =0A> in the context of the topic described by the first sen= tence. Specifying the =0A> topic of a paragraph in each sentence is redunda= nt. The second sentence is =0A> describing a limitation with the ::1/128 lo= opback prefix, which I'm =0A> confident is obvious to most English speakers= . One of my past reviewers =0A> isn't a native English speaker, and they ha= ve had no trouble with that =0A> paragraph.=0A>> =0A>> GUAs and ULAs aren'= t loopback prefixes (see RFC4291 and RFC4193), so my =0A> statement is true= .=0A>> =0A> =0A> Your statement is not true. Multiple application instances= using the same port =0A> bound to different loopback addresses is possible= . The fact that the loopback =0A> addresses in question must be pulled from= the ULA or GUA pools is irrelevant to =0A> the truth or falsehood of the s= tatement. Once you assign an address to a =0A> loopback interface, it is by= definition a loopback address whether or not it =0A> came from a "loopback= prefix".=0A> =0A>>> =0A>>> 3.=0A>>> A Unique Local IPv6 Unicast Address = (ULA) prefix [RFC4193] could be =0A> used to increase the number of address= es available on the local host. However =0A> this prefix would need to be m= anually generated and configured at least once by =0A> a system administrat= or or operator. Without additonal configuration, traffic =0A> towards addre= sses not assigned to the local host would not be prevented from =0A> leavin= g the host, and access may not be limited to the local host.=C2=A0 A ULA pr= efix =0A> would not be well known, and would not be convenient to remember = and type =0A> without violating the randomness requirements of the Global I= D component of a =0A> ULA prefix.=0A>>> =0A>>> =0A>>> Since the communicat= ion of this prefix in this case would not be =0A> expected to extend beyond= the host, the=0A>>> only requirement is that the ULA prefix chosen not co= nflict with one =0A> that the host is expected to need to reach outside of = the host. As such, =0A> fd00::/48 is a perfectly viable candidate in the va= st majority of cases as it is =0A> very unlikely to conflict with a randoml= y chosen routable prefix that follows =0A> the standards in RFC4193.=0A>>> = =0A>>> =0A>>> The Global ID component of=C2=A0 a ULA prefix is intended to= avoid conflicts =0A> in the results of M&A, etc. Since this would be host-= local addressing and =0A> not even have site-scope, use of a known non-conf= licting ULA address is =0A> perfectly feasible. fd00::/48 is very unlikely = to conflict (1 in 2^40 or < =0A> 0.000,000,000,1% or=C2=A0 <1 in 1e12).=0A>= >> =0A>> =0A>> So what would happen if you had an IPv6 CPE that was announ= cing fd00::/64 =0A> in it's RAs (slide 26 =E2=80=A6), and you configured fd= 00::/48 or fd00::/64 on one =0A> of your loopback interfaces?=0A>> =0A> =0A= > You'd be unable to reach the other hosts using that prefix most likely. = =0A> However, one wouldn't expect that you would do such a thing. If your r= outer =0A> is actually using fd00::/64, you'd want to use something else fo= r the =0A> loopback. Fortunately, you have 40 bits worth (more than a trill= ion) other =0A> prefixes to choose from.=0A> =0A>>> =0A>>> 4.=0A>>> 2.=C2= =A0 Larger Loopback Prefix Requirements A new larger loopback prefix =0A> s= hould attempt to satisfy all of the following requirements.=C2=A0 It should= : o=C2=A0 be a =0A> well known prefix, o=C2=A0 be within an existing specia= l purpose prefix, such as =0A> 0000::/8 (the parent prefix of the current I= Pv6 loopback address), o=C2=A0 be easy =0A> for a human to remember, o=C2= =A0 be easy for a human to type, o=C2=A0 cover the existing =0A> loopback p= refix, o=C2=A0 support 64 bit Interface Identifiers, o=C2=A0 provide a larg= e =0A> number of /64 subnets. =0A>>> =0A>>> =0A>>> I believe that fd00::/4= 8 could do what you describe:=0A>>> =0A>>> =0A>>> 1.I question the need fo= r it to be well known. As long as it is well =0A> known within=0A>>> the s= cope of the intended use, I think that suffices for the use cases =0A> you = have=0A>>> described.=0A>>> =0A>> =0A>> Well known makes it easy to add t= o ACLs. Well known makes it easy to =0A> remember. Well known means it is t= he same on all hosts.=0A>> =0A> =0A> If it's a loopback, what's the point o= f putting it in ACLs? Since the =0A> packets shouldn't leave the host, ther= e's not much utility to ACLs.=0A> =0A> As long as it's well known within th= e context (i.e. workgroup, company, =0A> site, whatever administrative boun= dary you=0A> decide is appropriate under the circumstances) it still meets = those requirements =0A> anyway.=0A> =0A>> People will even turn an "unusab= le definition of the loopback =0A> address", used to "encourage use=C2=A0= =C2=A0=C2=A0 of officially-assigned =0A> addresses", into the well known lo= opback address.=0A>> =0A>> http://www-mice.cs.ucl.ac.uk/multimedia/misc/tc= p_ip/8603.mm.www/0184.html=0A>> =0A> =0A> That URL leads to a rather length= y rant about bugs in 4.2 (and 4.3) BSD which I =0A> believe were fixed many= years ago.=0A> =0A> It talks about software mistakenly choosing the loopba= ck address as a source =0A> address when creating a reply packet in UDP. I = fail to see any relevance to the =0A> current proposal other than as a poss= ible further indication of just how bad an =0A> idea this actually is, sinc= e the closest connection that comes to mind is the =0A> probability of impl= ementing this draft leading to the introduction of similar =0A> bugs.=0A>> = =0A>> =0A>>> =0A>>> fd00::/48 could easily meet that test.=0A>>> =0A>> =0A= >> And fails to comply with the RFC that defines the address space it fall= s =0A> within. From RFC4193:=0A>> " The allocation of Global IDs is pseudo= -random [RANDOM].=C2=A0 They MUST =0A> NOT be assigned sequentially or with= well-known numbers."=0A>> "Locally assigned Global IDs MUST be generated = with a pseudo-random=0A>> =0A>> algorithm consistent with [RANDOM]."=0A>> = =0A>> So your proposal violates that RFC, and therefore you would need to = write =0A> an ID changing it to support your use of the Global ID zero valu= e.=0A>> =0A> =0A> Or you sanely realize that the reason for that is the ass= umption that the =0A> addresses would be applied to routable interfaces and= not loopbacks. Certainly =0A> an ID using fd00::/48 would be preferable to= this debacle as it doesn't =0A> require any software updates and provides = the same functionality.=0A> =0A> However, as I pointed out, fd00::/48 was j= ust an easy example. You could use a =0A> truly random ULA if you were so i= nclined, but you lose out on the easy to =0A> type/easy to remember feature= s.=0A> =0A>>> =0A>>> 2.fd00::/48 is within the existing ULA special purpos= e prefix.=0A>>> 3.fd00::/48 is very easy for a human to remember.=0A>>> 4= .fd00::/48 is very easy for a human to type.=0A>>> 5.Please justify your c= laim that it should encompass the existing =0A> loopback address.=0A>> =0A>= > I'd have thought it'd be obvious that expanding the existing prefix =0A>= would have been better if possible. I'd have thought this text would conve= y =0A> that.=0A> =0A> Better in what way. You still haven't actually justif= ied this claim, =0A> you've merely told me it should be obvious.=0A> =0A> C= ertainly, if it's so obvious, it shouldn't be hard to explain.=0A> =0A>> = =0A>> "Ideally, the prefix length of ::1/128 could be shortened, resulting= =0A> in a larger loopback prefix such as ::/48.=C2=A0 However, if the exis= ting loopback =0A> prefix length is shortened enough to satisfy all of the = larger loopback prefix =0A> requirements, it would then cover the IPv4 Mapp= ed IPv6 Address prefix, =0A> ::ffff:0.0.0.0/96, and prevent its use describ= ed in [RFC4038]."=0A>> =0A> =0A> Yes, I read that. Restating it adds nothin= g to the discussion. You still =0A> haven't said anything which supports yo= ur claim that this would somehow be =0A> ideal."=0A> =0A>> =0A>> =0A>>> 6.= fd00::/48 supports 64 bit IIDs.=0A>>> 7.fd00::/48 provides 65,536 /64 subn= ets. Is there some reason you think =0A> this is insufficient?=0A>>> This = is a total of 4 billion times 16.7 million times as many host =0A> addresse= s as were provided=0A>>> in the IPv4 loopback.=0A>>> =0A>> =0A>> It is qu= ite adequate, and the size I proposed in the first two drafts. =0A> However= , under 0000::/8, it's possible to make it a /32, because their are =0A> 16= million of them. Since this draft is revisiting the original ::1/128 =0A> = decision, why not make every attempt that can be easily afforded to avoid = =0A> revisiting the IPv6 loopback prefix the 3rd time. "More than enough" = =0A> is better than "just enough" when cheap enough, as it saves coming =0A= > back for more. =0A>> =0A> =0A> For that matter, it's possible to make it = a /16 or a /64, but I don't =0A> see any justification for those numbers, e= ither.=0A> =0A> I would argue that if you can't do it in 65,536 times 18 qu= intillion =0A> loopback addresses, it probably won't fit in any host ever l= ikely to be =0A> manufactured within the useful lifetime of IPv6.=0A> =0A> = OTOH, given how much we wish we could have revisited the absolutely moronic= =0A> choice to waste an entire /8 on IPv4 loopbacks, going to a /32 seems = likely to =0A> be equally moronic. While I personally think this is a boond= oggle to begin with, =0A> if it is to be adopted, I certainly thin a /48 is= so much more than enough that =0A> multiplying that mistake by 65,536 make= s no sense whatsoever.=0A> =0A>>> =0A>>> It is 1/256th as many networks as= IPv4 provided loopback hosts.=0A>>> =0A>>> =0A>>> 5.=0A>>> 3.=C2=A0 Prop= osed Larger Loopback Prefix Ideally, the prefix length of =0A> ::1/128 coul= d be shortened, resulting in a larger loopback prefix such as =0A> ::/48.= =C2=A0 However, if the existing loopback prefix length is shortened enough = to =0A> satisfy all of the larger loopback prefix requirements, it would th= en cover the =0A> IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and p= revent its use =0A> described in [RFC4038]. Giving up the requirement of co= vering the existing =0A> loopback prefix, the proposed larger loopback pref= ix is: =0A>>> =0A>>> =0A>>> =0A>>> So why not simply delete this from the = requirements list as you've =0A> failed to=0A>>> provide any justification= for said requirement anyway.=0A>> =0A>> Requirementlists define both want= s and needs. It's there because more =0A> than once people have asked why n= ot just shorten the prefix length of the =0A> existing prefix.=0A> =0A> Int= eresting=E2=80=A6 That was the part I considered obvious. I still don't see= any =0A> advantage to doing so vs. using space somewhere else.=0A> =0A>> = =0A>>> Smith=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Expires August 15, 2013=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Page =0A> 4] =0A>>> Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2= =A0 A Larger IPv6 Loopback Prefix=C2=A0 =C2=A0 =C2=A0 =C2=A0 February =0A> = 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 This p= refix =0A> satisfies all remaining larger loopback prefix requirements.=0A>= >> =0A>>> =0A>>> I think this is a terrible choice of location. It pretty = much maximizes =0A> the fragmentation damage that can be done by the choice= of prefix. :1::/32 would =0A> at least be the first /32 available. As I've= stated, a locally chosen =0A> address such as fd00::/48 (or whatever selec= tion of chosen ULA space meets local =0A> requirements) is equally viable I= MHO.=0A>>> =0A>> =0A>> The goal was the shortest thing to type, and I don'= t think =0A> fragmentation matters within 0000::/8. I think people will com= monly forget the =0A> colon on the front of :1::/32, or mix up where the tw= o contiguous colons are =0A> e.g. they'll type ::1:/32.=0A>> =0A> =0A> Good= arguments against using 1::/32 as well.=0A> =0A>>> =0A>>> 6.=0A>>> Alloc= ating a /32 prefix for the loopback function may seem excessive, =0A> as a = /48 length prefix would satisfy the larger loopback prefix requirements.=C2= =A0 =0A> However, within the parent 0000::/8 special purpose prefix, there = are =0A> approximately 16 million /32 prefixes, so a single /32 for the lar= ger loopback =0A> prefix is easily afforded.=C2=A0 A /32 larger loopback pr= efix will satisfy all =0A> current and likely future uses of the loopback f= unction.=0A>>> =0A>>> =0A>>> Allocating a /32 is absurdly excessive and ju= st because we can does not =0A> strike me as anything remotely resembling a= n argument that we should.=0A>>> =0A>> =0A>> So you're saying that you can= think of better uses for the 16 million =0A> /32s within 0000::/8, such th= at just one can't be used for this purpose? =0A> What are some of your bett= er uses?=0A>> =0A> =0A> No, but I am saying I'm willing to bet that other b= etter uses for the other =0A> 65,535 /48s in 1::/32 are not at all unlikely= to come along.=0A> =0A>>> =0A>>> 4.=C2=A0 Address Assignment and Configur= ation =0A>>> =0A>>> =0A>>> Consistent with the IPv6 addressing model [RFC4= 291], each address =0A> within the larger loopback prefix is associated wit= h one of the node's =0A> interfaces, although not necessarily the same inte= rface for all addresses.=C2=A0 This =0A> means that the node acts as though= all addresses within the larger loopback =0A> prefix have been configured = on one or more interfaces.=C2=A0 Applications will accept =0A> packets dest= ined to any of the larger loopback prefix addresses, unless the =0A> applic= ation is bound to specific larger loopback addresses.=C2=A0 Typically the = =0A> addresses will be logically assigned to one or more virtual "loopback"= =0A> interfaces, which locally returns or loops outgoing packets back to t= he same =0A> node that originated the packets.=0A>>> =0A>>> =0A>>> =0A>>> = =0A>>> =0A>>> =0A>>> I believe you have misread and conflated RFC4291 and = RFC1122 with =0A> regards to how loopback=0A>>> addresses function.=0A>>> = =0A>> =0A>> This is specifying the address assignment and configuration sc= heme for the =0A> proposed larger loopback prefix. You have misread and mis= understood this text.=0A>> =0A> =0A> No, I didn't. However, you claim "Cons= istent with=E2=80=A6" and follow it =0A> with a description which is not co= nsistent.=0A> =0A>>> =0A>>> Unless I am mistaken, there is no requirement = in RFC1122 that a node =0A> answer all addresses within 127/8.=0A>>> =0A>>>= =0A>>> Some nodes may support more than one loopback interface.=C2=A0 The= se =0A> subsequent loopback interfaces, when initialised, should be assigne= d Smith=C2=A0 =C2=A0 =C2=A0 =0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Expires August 15, 2013=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 5] =0A>>> Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 A Lar= ger IPv6 Loopback Prefix=C2=A0 =C2=A0 =C2=A0 =C2=A0 February =0A> 2013 a la= rger loopback /64 prefix locally unique within the node.=C2=A0 All addresse= s =0A> within the assigned /64 are logically assigned to the interface.=C2= =A0 Additionally, =0A> the ":1" address for the subnet should be configured= on the loopback =0A> interface, making it visible to a system operator or = user.=0A>>> =0A>>> =0A>>> This would, indeed, be new functionality. I am n= ot convinced of any =0A> value to having that functionality and it is radic= ally different from any =0A> required functionality in IPv4 today. In IPv4,= hosts which support multiple =0A> loopbacks have no default address or ran= ge on the subsequent loopback =0A> interfaces.=0A>>> =0A>> =0A>> Right. Th= e goal here is to take something useful in IPv4 that doesn't =0A> exist in = IPv6, and then to also see if there are opportunities to make further =0A> = improvements. This is not a literal copy of IPv4 functionality into IPv6. = =0A> Changes to fix limitations are also opportunities to make improvements= .=0A>> =0A> =0A> My point is that the capability that exists in IPv4 today = also exists in IPv6 =0A> already. The only difference is the pool of addres= ses you have to choose from =0A> for that purpose. In IPv4, you have, in ad= dition to the global unicast, =0A> RFC-1918, and in some circumstances, lin= k local addresses the normally unused =0A> addresses within 127/8. In IPv6,= you are limited to the ULA and GUA in addition =0A> to ::1/128.=0A> =0A>>>= =0A>>> If you cannot justify a need for this functionality, I see no poin= t in =0A> advancing it as a standard.=0A>>> =0A>> =0A>> I have justified i= t, in Abstract and the Introduction. You might not =0A> believe there is a = problem to solve, but that doesn't mean that other people =0A> don't, and t= hat they haven't experienced a problem. In addition to =0A> myself, Erik Kl= ine and Vijayrajan Ranganathan have encountered situations where =0A> more = IPv6 loopback addresses would be useful:=0A>> =0A> =0A> Your justification = isn't. The problem statements you have presented so far =0A> can be solved = without requiring software modifications to every IPv6 stack.=0A> =0A>> ht= tp://www.ietf.org/mail-archive/web/v6ops/current/msg14815.html=0A>> =0A>> = =0A>> http://www.ietf.org/mail-archive/web/ipv6/current/msg10882.html=0A>>= =0A>> =0A>> Here is Erik, back in 2009, describing the exact scenario tha= t I've =0A> described in the Abstract and Intro.=0A>> =0A>> http://www.iet= f.org/mail-archive/web/ipv6/current/msg11018.html=0A>> =0A> =0A> I'm not sa= ying your problem shouldn't be solved. I'm saying that it =0A> already has = been.=0A> =0A>> =0A>> =0A>> =0A>>> =0A>>> It should be possible for an ope= rator to remove these automatically =0A> configured loopback addresses.=C2= =A0 It should also be possible for an operator to =0A> configure further lo= opback addresses from within the assigned /64, or addresses =0A> from other= parts of the larger loopback prefix, including other /64s assigned to =0A>= other loopback interfaces. Other addresses within the assigned /64(s) woul= d =0A> continue to be logically assigned to the subsequent loopback interfa= ce. =0A> Configuration of addresses is for operational visibility and conve= nience, and =0A> does not change the behaviour of non-visible logically ass= igned addresses.=0A>>> =0A>>> =0A>>> If you're going to do this, then I wo= uld argue that it =0A> "must" be possible for an operator to remove=E2=80= =A6=0A>>> =0A>> =0A>> ok. I've tried to avoid being too absolute in this a= rea because =0A> it's describing operator/system interface functionality, r= ather than things =0A> a compliant implementation must do.=0A>> =0A> =0A> B= ut you don't say that a compliant implementation must. As written, your =0A= > draft would allow a compliant implementation which did not allow operator= =0A> removal. I consider this highly undesirable.=0A> =0A>> =0A>>> =0A>>> = The rest of what you suggest strikes me as being a kernel routing =0A> hai= rball of unnecessarily large=0A>>> proportion and likely to engender more = bugs than functionality.=0A>>> =0A>> =0A>> I'm curious as to what experien= ce you have to be able to make that =0A> judgement. Using Linux as an examp= le IPv6 implementation, I know enough about =0A> the Linux kernel networkin= g code that I'm pretty sure it shouldn't be =0A> too hard to make these cha= nges.=0A>> =0A> =0A> I know that most hosts today do not behave well and mo= st routers won't even =0A> allow you to configure overlapping prefixes=0A> = and addresses on multiple interfaces. Admittedly, some of that is due to th= e =0A> fact that the desired behavior is not defined anywhere, which admitt= edly is =0A> addressed to some extent in your draft. However, even with tho= se definitions it =0A> still strikes=0A> me as being quite a mess both from= a principle-of-least-surprise perspective as =0A> well as a complexity for= the sake of=0A> complexity perspective.=0A> =0A> Owen=0A> =0A>> =0A>>> =0A= >>> ------=0A>>> =0A>>> =0A>>> This covers the first 6 pages (approximate= ly half of the draft). =0A> I'm not going to take the time to write up the = problems in the rest of the =0A> draft at this point because the above are,= IMHO, more than sufficient reason to =0A> oppose adoption.=0A>>> =0A>>> = =0A>>> Owen=0A>>> =0A>>> =0A>>> On Feb 12, 2013, at 4:18 PM, Owen DeLong = wrote:=0A>>> =0A>>> =0A>>>> On Feb 12, 2013, at 12:33 PM= , Mark Smith =0A> wrote:=0A>>>> =0A>>>> =0A>>>>= =0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> ----- Original Message -----=0A>>>>> = =0A>>>>> From: Owen DeLong =0A>>>>>> To: Mark Smith =0A>>>>>> Cc: Doug Barton ; = =0A> "v6ops@ietf.org" =0A>>>>>> Sent: Wednesday, 13 Februa= ry 2013 6:59 AM=0A>>>>>> Subject: Re: [v6ops] New Version Notification for= =0A> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt=0A>>>>>> =0A>>>>= >> =0A>>>>>> =0A>>>>>>>> ?? I don't see how it gets easier to remember =0A= > than fd00::/8=0A>>>>>>>> =0A>>>>>>> The random bit is the hard bit to re= member and type. I =0A> don't think =0A>>>>>>> you're thinking enough abou= t how it is to use, =0A> you're only thinking =0A>>>>>> about how hard it = is to configure. The time and effort to =0A> configure something is =0A>>>>= >> usually minimal compared to the amount of time and effort =0A> spent wh= ile it is =0A>>>>>> being used.=0A>>>>>> =0A>>>>>> =0A>>>>>>> =0A>>>>>> N= othing requires you to use random for this purpose. Use =0A> fd00::/64 for = all =0A>>>>>> anyone cares.=0A>>>>>> =0A>>>>>> =0A>>>>> RFC4193 does. It'= s not a ULA if it doesn't, it's =0A> been made a site-local. See RFC3879 fo= r the problems with them and your =0A> non-random ULA.=0A>>>>> =0A>>>>> =0A= >>>> Which is irrelevant to the loopback scenario you have described=E2=80= =A6=0A>>>> =0A>>>> =0A>>>> =0A>>>>> =0A>>>>> and you can use =0A>>>>>>>> = =0A>>>>>>> =0A>>>>>>> anything you want inside of that to provide a /64 fo= r =0A> your development =0A>>>>>>>> purpose.=0A>>>>>> =0A>>>>>> =0A>>>>>>>= > What's more cumbersome about picking something =0A> (even fd00::/64, if = =0A>>>>>>>> you want) =0A>>>>>> =0A>>>>>> =0A>>>>>>> No, that's bad, as i= t is a ULA prefix which =0A> doesn't have a random =0A>>>>>>> component. A= dd the random component (if you aren't =0A> lazy), and it then =0A>>>>>> b= ecomes hard to remember and type.=0A>>>>>> =0A>>>>>> =0A>>>>>>> =0A>>>>>> = Why is it bad that it doesn't have a random component? =0A> If it's in a = =0A>>>>>> development test lab, it's not like it's at risk of =0A> corpora= te merger =0A>>>>>> conflicts, etc.=0A>>>>>> =0A>>>>>> =0A>>>>> See slide= 26.=0A>>>>> =0A>>>>> http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf= =0A>>>>> =0A>>>>> =0A>>>> Which does not apply to use on a loopback interf= ace.=0A>>>> =0A>>>> =0A>>>> =0A>>>>> =0A>>>>> for development than having = some other prefix you have to =0A> configure =0A>>>>>>>> assigned by =0A>>= >>>> =0A>>>>>> =0A>>>>>>> =0A>>>>>>> the IETF.=0A>>>>>>>> =0A>>>>>>> I'm = starting to wonder if you've actually read =0A> the draft. The =0A>>>>>>> = intention is that it is that the larger loopback prefix =0A> automatically = configured =0A>>>>>> at system initialisation, as ::1/128 and 127/8 curren= tly =0A> are. There is a whole =0A>>>>>> section on automatic address assi= gnment and configuration.=0A>>>>>> =0A>>>>>> 127/8 isn't auto-assigned. 12= 7.0.0.1/8 is.=0A>>>>>> =0A>>>>>> =0A>>>>> That's incorrect.=0A>>>>> =0A>>>= >> RFC1122, "Requirements for Internet Hosts -- Communication =0A> Layers"= , specifically the in=0A>>>>> =0A>>>>> "(g) { 127, }=0A>>>>> = Internal host loopback address.=C2=A0 Addresses of this form MUST =0A> NOT = appear outside a host."=0A>>>>> =0A>>>>> =0A>>>> Yes, it requires that you= not have addresses within 127.0.0.0/8 =0A> appear outside of the host. It = does=0A>>>> not require the host to answer or auto configure all of the = =0A> 127.0.0.0/8 addresses on its loopback=0A>>>> interface and, indeed, m= ost hosts do NOT auto configure other than =0A> 127.0.0.1.=0A>>>> =0A>>>> = =0A>>>> =0A>>>>>>> =0A>>>>> =0A>>>>> =0A>>>>>>>> Sorry, but I just don't g= et it.=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>>> =0A>>>>>>>> =0A>>>>>= >>> This proposal also takes the opportunity to =0A> introduce IPv4-like = =0A>>>>>>>>> handling of =0A>>>>>> =0A>>>>>> loopback IPv6 packets so tha= t future functions similar to =0A> the use in =0A>>>>>>>> RFC4379 =0A>>>>>= > =0A>>>>>> have a native IPv6 address space to use, rather than using =0A= > 127/8 within =0A>>>>>>>> an IPv6 =0A>>>>>> =0A>>>>>> prefix.=0A>>>>>>>>= =0A>>>>>>>> In my (admittedly limited) testing, putting a /64 =0A> of ULA= on the =0A>>>>>>>> loopback =0A>>>>>> =0A>>>>>> interface did just that,= so I'm not sure what it is =0A> that you feel =0A>>>>>>>> is =0A>>>>>> = =0A>>>>>> missing.=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>> All addresses within= 127/8 are valid and available on =0A> the host, where as =0A>>>>>>> with = your ULA, only 1 is.=0A>>>>>> =0A>>>>>> =0A>>>>>>> e.g.=0A>>>>>>> =0A>>>>>= >> =0A>>>>>>> [root@opy mark]# ip addr show dev lo=0A>>>>>>> 1: lo: mtu 65536 qdisc =0A> noqueue state UNKNOWN =0A>>>>>>> =C2= =A0 =C2=A0 link/loopback 00:00:00:00:00:00 brd =0A> 00:00:00:00:00:00=0A>>= >>>>> =C2=A0 =C2=A0 inet 127.0.0.1/8 scope host lo=0A>>>>>>> =C2=A0 =C2=A0= inet6 fd00:db8::1/64 scope global =0A>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = valid_lft forever preferred_lft forever=0A>>>>>>> =C2=A0 =C2=A0 inet6 1::1= /64 scope global =0A>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid_lft forever p= referred_lft forever=0A>>>>>>> =C2=A0 =C2=A0 inet6 ::1/128 scope host =0A>= >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid_lft forever preferred_lft forever= =0A>>>>>>> =0A>>>>>>> [root@opy mark]# ping -c 1 127.1.2.3=0A>>>>>>> PING= 127.1.2.3 (127.1.2.3) 56(84) bytes of data.=0A>>>>>>> 64 bytes from 127.1= .2.3: icmp_req=3D1 ttl=3D64 time=3D0.053 =0A> ms=0A>>>>>>> =0A>>>>>>> --- = 127.1.2.3 ping statistics ---=0A>>>>>>> 1 packets transmitted, 1 received,= 0% packet loss, time =0A> 0ms=0A>>>>>>> rtt min/avg/max/mdev =3D 0.053/0.= 053/0.053/0.000 ms=0A>>>>>>> [root@opy mark]# =0A>>>>>>> =0A>>>>>>> =0A>>>= >>> Interesting=E2=80=A6 I get this behavior on MacOS.=0A>>>>>> =0A>>>>>> = [tc01-dhcp153:~] owen% ifconfig lo0=0A>>>>>> lo0: flags=3D8049 mtu =0A> 16384=0A>>>>>> =C2=A0 =C2=A0 options=3D3=0A>>>>>> =C2=A0 =C2=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x= 1 =0A>>>>>> =C2=A0 =C2=A0 inet 127.0.0.1 netmask 0xff000000 =0A>>>>>> =C2= =A0 =C2=A0 inet6 ::1 prefixlen 128 =0A>>>>>> =0A>>>>>> [tc01-dhcp153:~] ow= en% ping 127.1.2.3=0A>>>>>> PING 127.1.2.3 (127.1.2.3): 56 data bytes=0A>>= >>>> Request timeout for icmp_seq 0=0A>>>>>> Request timeout for icmp_seq= 1=0A>>>>>> Request timeout for icmp_seq 2=0A>>>>>> Request timeout for i= cmp_seq 3=0A>>>>>> ^C=0A>>>>>> --- 127.1.2.3 ping statistics ---=0A>>>>>>= 5 packets transmitted, 0 packets received, 100.0% packet =0A> loss=0A>>>>= >> =0A>>>>>> =0A>>>>> So MacOS isn't compliant with RFC1122.=0A>>>>> =0A>>= >>> =0A>>>> How do you figure that? You'll need to be more specific.=0A>>>= > =0A>>>> =0A>>>> =0A>>>>> =0A>>>>> Admittedly, Linux does this:=0A>>>>>> = =0A>>>>>> owen.delong.com:owen /home4/owen (22) % ifconfig lo=0A>>>>>> lo= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Link encap:Local Loopback=C2=A0 =0A>>>>>> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet addr:127.0.0.1=C2=A0 Mask:255.0.0.0=0A= >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 addr: ::1/128 Scope:Host=0A= >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP LOOPBACK RUNNING=C2=A0 MTU:164= 36=C2=A0 Metric:1=0A>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX packets:45= 816328 errors:0 dropped:0 overruns:0 =0A> frame:0=0A>>>>>> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 TX packets:45816328 errors:0 dropped:0 overruns:0 =0A>= carrier:0=0A>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 txqueue= len:0 =0A>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:578712867 (551.= 9 MiB)=C2=A0 TX bytes:578712867 =0A> (551.9 MiB)=0A>>>>>> =0A>>>>>> owen.d= elong.com:owen /home4/owen (23) % ping 127.1.2.3=0A>>>>>> PING 127.1.2.3 (= 127.1.2.3) 56(84) bytes of data.=0A>>>>>> 64 bytes from 127.1.2.3: icmp_se= q=3D1 ttl=3D64 time=3D0.043 ms=0A>>>>>> 64 bytes from 127.1.2.3: icmp_seq= =3D2 ttl=3D64 time=3D0.032 ms=0A>>>>>> 64 bytes from 127.1.2.3: icmp_seq= =3D3 ttl=3D64 time=3D0.019 ms=0A>>>>>> ^C=0A>>>>>> --- 127.1.2.3 ping sta= tistics ---=0A>>>>>> 3 packets transmitted, 3 received, 0% packet loss, ti= me =0A> 2000ms=0A>>>>>> rtt min/avg/max/mdev =3D 0.019/0.031/0.043/0.010 m= s=0A>>>>>> owen.delong.com:owen /home4/owen (24) % =0A>>>>>> =0A>>>>>> =0A= >>>>>> =0A>>>>>> =0A>>>>>> [root@opy mark]# ping6 -c 1 fd00:db8::2=0A>>>>>= >> =0A>>>>>>> connect: Network is unreachable=0A>>>>>>> [root@opy mark]#= =0A>>>>>>> =0A>>>>>>> [mark@opy ~]$ ssh 127.1.2.3=0A>>>>>>> The authentic= ity of host '127.1.2.3 =0A> (127.1.2.3)' can't be =0A>>>>>>> established.= =0A>>>>>> =0A>>>>>> =0A>>>>>>> [mark@opy ~]$ ssh -6 fd00:db8::2=0A>>>>>>> = ssh: connect to host fd00:db8::2 port 22: Network is =0A> unreachable=0A>>= >>>>> [mark@opy ~]$=0A>>>>>>> =0A>>>>>>> =0A>>>>>> From what I can see, t= his seems to depend on a pathology =0A> not universally =0A>>>>>> availabl= e even in IPv4.=0A>>>>>> =0A>>>>>> =0A>>>>>> Another test you should do to= measure the usefulness of =0A> this proposal is =0A>>>>>>> see how long i= t takes and your opinion afterwards of =0A> how hard or easy it is to =0A>>= >>>> type or cut and paste "fd00:db8::1" vs =0A> "1::1" a reasonable =0A>>= >>>> number of times e.g. 6 times.=0A>>>>>> =0A>>>>>> =0A>>>>>>> =0A>>>>>>= I'm fine with it. If you're doing it more than 6 =0A> times, that's what = =0A>>>>>> DNS is for.=0A>>>>>> =0A>>>>>> =0A>>>>> That's an option, for a= pplications that use DNS to resolve =0A> addresses. There are applications = that need to deal with addresses directly, =0A> such as mine, due to their = nature and purpose.=0A>>>>> =0A>>>> Then use a configuration file or whate= ver. There are lots of =0A> alternatives to repeatedly typing in addresses.= =0A>>>> (command-line aliases come to mind as an example).=0A>>>> =0A>>>> = =0A>>>> =0A>>>>> =0A>>>>> =0A>>>>>>> Using a ULA doesn't really work at al= l. It only =0A> adds another address to =0A>>>>>>> the host, rather than m= any. A properly formed ULA is =0A> hard to type and remember. =0A>>>>>> It= 's far less user friendly than the short larger =0A> loopback prefix I'm = =0A>>>>>> proposing. This is based on my experience, as I've used =0A> a U= LA for the =0A>>>>>> purpose of trying to increase the number of loopback = IPv6 =0A> addresses.=0A>>>>>> =0A>>>>>> =0A>>>>>>> =0A>>>>>> The same is t= rue with loopback except on Linux as near as I =0A> can tell.=0A>>>>>> =0A>= >>>>> =0A>>>>> Windows 7 also behaves this way, as it complies with RFC112= 2.=0A>>>>> =0A>>>>> =0A>>>> Nothing I found in RFC 1122 requires this, so = if you think =0A> something does, you'll=0A>>>> need to point it out.=0A>>= >> =0A>>>> I know for a fact that several Cisco switches did not. For exam= ple, =0A> they used to use=0A>>>> 127.0.0. as a convenient ha= ck for connections =0A> across the backplane=0A>>>> to the IP stack runnin= g on IP-aware blades such as RSMs.=0A>>>> =0A>>>> =0A>>>> =0A>>>>>>>>> =0A>= >>>>>> =0A>>>>>>> Note, I don't know the answer, but I'm leaning =0A> heav= ily =0A>>>>>>>>>> towards, =0A>>>>>> =0A>>>>>> =0A>>>>>>>> =0A>>>>>>>> "n= o."=0A>>>>>>>>>> =0A>>>>>>>>>> Primarily because we're asking people =0A> = to deploy this =0A>>>>>>>>>> protocol for =0A>>>>>> =0A>>>>>> real-world = scenarios, and we already have a pretty wide =0A>>>>>>>>>> divergence in = =0A>>>>>> =0A>>>>>> the latest state of the standards vs. the oldest worki= ng =0A>>>>>>>>>> deployed base. =0A>>>>>> =0A>>>>>> =0A>>>>>>>> =0A>>>>>>>= > Widening that gap should only be done for truly =0A> critical =0A>>>>>>>= >>> changes, and =0A>>>>>> =0A>>>>>> I'm not sure you've made your case s= ufficiently.=0A>>>>>>>>>> =0A>>>>>>>>>> Put more simply, at some point we = have to =0A> stop tinkering with =0A>>>>>>>>>> the plane =0A>>>>>> =0A>>>>= >> =0A>>>>>>>> =0A>>>>>>>> while it's in the air.=0A>>>>>>>>>> =0A>>>>>>>>= >> =0A>>>>>>>>> So I think the implication of that analogy is =0A> that de= ploying this =0A>>>>>>>>> enhancement will somehow interrupt the existing = =0A> operation of IPv6 =0A>>>>>>>> implementations ("the plane") causing = =0A> them to fail =0A>>>>>>>> ("fall out of =0A>>>>>> =0A>>>>>> the sky")= . I don't see how that will be the case. =0A> Deploying a =0A>>>>>>>> new = =0A>>>>>> =0A>>>>>> loopback prefix would leverage many of the existing ad= dress =0A> =0A>>>>>>>> configuration and =0A>>>>>> =0A>>>>>> loopback rel= ated functions of existing IPv6 =0A> implementations. It is not =0A>>>>>>>>= much more =0A>>>>>> =0A>>>>>> than a larger version of ::1/128.=0A>>>>>>= >> =0A>>>>>>>> The implication is that you are requesting to once =0A> aga= in obsolete all =0A>>>>>>>> existing =0A>>>>>> =0A>>>>>> implementations = in favor of requiring deploying another =0A> fundamentally =0A>>>>>>>> cha= nged =0A>>>>>> =0A>>>>>> IPv6 stack.=0A>>>>>>>> =0A>>>>>>> Can you define= the threshold of "fundamentally =0A> changed" for me?=0A>>>>>>> =0A>>>>>>>= =0A>>>>>> Requiring a modification to every existing IPv6 stack in =0A> t= he wild which could be=0A>>>>>> incorporated into software dependencies wh= ich would render =0A> existing stacks =0A>>>>>> unexpectedly=0A>>>>>> obs= olete.=0A>>>>>> =0A>>>>>> =0A>>>>>> I don't consider this to be a fundamen= tal change. It is =0A> adding another =0A>>>>>>> loopback prefix, which op= erates the same as the =0A> existing one, just with a =0A>>>>>> shorter pr= efix length. It is adding values to the source =0A> and destination address= =0A>>>>>> selection policy, which is already possible to do because =0A> = it's been designed =0A>>>>>> that way. I'm quite confident that it is goin= g to be no =0A> more than 10 lines, =0A>>>>>> and probably closer to 5 add= itional lines of code in a =0A> stack for a host =0A>>>>>> implementation = that only supports a single loopback =0A> interface. That's code =0A>>>>>> = change size closer to the size of bug fixes than additional =0A> functiona= lity.=0A>>>>>> =0A>>>>>> =0A>>>>>>> =0A>>>>>> So you want to force everyon= e to update their IPv6 stack on =0A> every host, router, =0A>>>>>> switch,= etc. just so you can save some typing?=0A>>>>>> =0A>>>>>> =0A>>>>> The IE= TF (and I) can't force anything. If it's useful, =0A> it'll be implemented.= =0A>>>>> =0A>>>>> =0A>>>> IMHO, it's not all that useful and making it a s= tack =0A> requirement would lead to one of two bad situations:=0A>>>> =0A>>= >> 1.Development resources would be taken away from tasks that matter.=0A>= >>> or=0A>>>> 2.Increasing divergence between the implemented stacks and = the =0A> documented standards.=0A>>>> =0A>>>> =0A>>>> =0A>>>> You're doing= a very good job cementing my opposition here.=0A>>>>>> =0A>>>>>> =0A>>>>> = You seem to like doing things the hard way. My view is =0A> computers shou= ld do things automatically for people so that people can get on =0A> with m= ore valuable things. Developers should be cutting code instead of setting = =0A> up development environments, or waiting for system administrators to s= et up the =0A> development environment for them.=0A>>>>> =0A>>>>> =0A>>>> = Actually, I do not. However, I do not believe in using the entire =0A> IP s= tack development community as a workforce to save me a little bit of typing= =0A> which, as near as I can tell is all that this proposal would accompli= sh.=0A>>>> =0A>>>> The functionality you seek is available using ULA. The = issues you =0A> cite with ULA would not apply to loopback usage. The functi= onality that you =0A> attribute to RFC 1122 isn't (as near as I can tell) a= ctually codified into =0A> RFC 1122 (I don't see how requiring that an addr= ess range not appear outside =0A> of a host requires that host to accept al= l packets to any address in said range, =0A> which is what you are claiming= ).=0A>>>> =0A>>>> =0A>>>> My definition of a fundamental change would be t= o do something like =0A> change =0A>>>>>>> the change the size of the IPv6= address, or reorder the =0A> fields in the IPv6 =0A>>>>>> header.=0A>>>>>= > =0A>>>>>> =0A>>>>>>> =0A>>>>>> That would be a drastic change, indeed. T= his is less =0A> drastic, but it would make =0A>>>>>> current IPv6 stacks = incompatible with the protocol =0A> definition.=0A>>>>>> =0A>>>>>> =0A>>>>>= I don't get this. 1::/32 is not currently used for =0A> anything, so usin= g it is not going to make it incompatible with anything. Using =0A> other p= refixes for purposes that they weren't designed for, such as a ULA as =0A> = a loopback, has far greater risk of creating incompatibility. =0A>>>>> =0A>= >>> If you add this as a required stack feature, stacks which don't =0A> i= mplement the feature are no longer compliant.=0A>>>> =0A>>>> =0A>>>> =0A>>>= >> =0A>>>>> The question is whether there is enough value in the change to= =0A>>>>>>>> justify such a decision and IMHO, at this point, =0A> just to= make it =0A>>>>>>>> "less =0A>>>>>> =0A>>>>>> cumbersome" than putting (= a) ULA address(es) on the =0A> loopback =0A>>>>>>>> interface =0A>>>>>> = =0A>>>>>> strikes me as not having much value.=0A>>>>>>>> =0A>>>>>>>> =0A>= >>>> You don't seem to be placing any value convenience. Does =0A> your ca= r have an automatic transmission? Do you have a dishwasher? Do you go to = =0A> restaurants? All of those things only exist because humans place value= on the =0A> convenience of not manually changing gears, not manually washi= ng dishes, and not =0A> cooking at home when we could. Why have to do somet= hing manually when a computer =0A> could do it automatically for you?=0A>>>= >> =0A>>>>> =0A>>>> I place tremendous value on convenience. My car does n= ot have a =0A> traditional automatic transmission, my car has an ECVT trans= mission. If I were =0A> buying a car, I would actually prefer a manual tran= smission because I prefer the =0A> greater control flexibility and shifting= precision afforded by a manual =0A> transmission.=0A>>>> =0A>>>> Yes, I g= o to restaurants.=0A>>>> =0A>>>> There are many equally automatic solution= s to your problem already =0A> available without involving the entire body = of protocol developers and the IETF =0A> in the process.=0A>>>> =0A>>>> Ow= en=0A>>>> =0A>>>> =0A>>>> Owen=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> =0A>>>>>= >>>> =0A>>>>>>>>> Regards,=0A>>>>>>>>> Mark.=0A>>>>>>>>> =0A>>>>>>>>> =0A= >>>>>>>>> =0A>>>>>>>>> Doug=0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>> On 0= 2/11/2013 01:37 PM, David Farmer wrote:=0A>>>>>>>>>> =0A>>>>>>>>>> On 2/11= /13 14:28 , Owen DeLong wrote:=0A>>>>>>>>>>> =0A>>>>>>>>>>> Perhaps I'm no= t very bright, but is =0A> there any =0A>>>>>>>>>>>> reason ULA =0A>>>>>> = =0A>>>>>> couldn't be=0A>>>>>>>>>> =0A>>>>>>>>>> used on the LO interface= to=0A>>>>>>>>>>>> satisfy this corner case?=0A>>>>>>>>>>>> =0A>>>>>>>>>>>= The Draft does cover why ULA is thought =0A> to not be a =0A>>>>>>>>>>> = sufficient =0A>>>>>> =0A>>>>>> solution,=0A>>>>>>>> =0A>>>>>>>> do you di= sagree with the reasoning in the draft?=0A>>>>>>>>>>> =0A>>>>>>>>>>> from = Section 1;=0A>>>>>>>>>>> =0A>>>>>>>>>>> =C2=A0 =C2=A0 =C2=A0 A Unique Loca= l IPv6 Unicast =0A> Address (ULA) prefix =0A>>>>>>>>>>> [RFC4193] =0A>>>>>= > =0A>>>>>> could be=0A>>>>>>>> =0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 used to = increase the number of addresses =0A> available on =0A>>>>>>>>>>> the =0A>= >>>>> =0A>>>>>> local host.=0A>>>>>>>> =0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 H= owever this prefix would need to be manually =0A> =0A>>>>>>>>>>> generated= and=0A>>>>>> =0A>>>>>> =C2=A0 =C2=A0 =C2=A0 configured at least once by a= system administrator or =0A> =0A>>>>>>>>>>> =0A>>>>>> =0A>>>>>> operator.= =0A>>>>>>>> =0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 Without additonal configurati= on, traffic =0A> towards =0A>>>>>>>>>>> addresses not=0A>>>>>> =0A>>>>>> = =C2=A0 =C2=A0 =C2=A0 assigned to the local host would not be prevented =0A= >>>>>>>>>>> from leaving =0A>>>>>> =0A>>>>>> the=0A>>>>>>>> =0A>>>>>>>> = =C2=A0 =C2=A0 =C2=A0 host, and access may not be limited to the =0A> local= =0A>>>>>>>>>>> host.=C2=A0 A ULA =0A>>>>>> =0A>>>>>> prefix=0A>>>>>>>> = =0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 would not be well known, and would not be= =0A> convenient =0A>>>>>>>>>>> to =0A>>>>>> =0A>>>>>> remember and=0A>>>= >>>>> =0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 type without violating the randomne= ss =0A> requirements of =0A>>>>>>>>>>> the =0A>>>>>> =0A>>>>>> Global ID= =0A>>>>>>>> =0A>>>>>>>> =C2=A0 =C2=A0 =C2=A0 component of a ULA prefix.=0A= >>>>>>>>>>> =0A>>>>>>>>>>> =0A>>>>>>>>>>> Owen=0A>>>>>>>>>>>> =0A>>>>>>>>>= >>> On Feb 11, 2013, at 12:20 , Mark =0A> Smith =0A>>>>>>>>>>>> =0A> wrote:=0A>>>>>>>>>> =0A>>>>>>>>>> =0A>>>>>>>>>>>> = =0A>>>>>>>>>>>> Hi,=0A>>>>>>>>>>>>> =0A>>>>>>>>>>>>> Here is a new versio= n of my =0A> IPv6 larger loopback =0A>>>>>>>>>>>>> prefix =0A>>>>>> =0A>>>= >>> draft.=0A>>>>>>>> =0A>>>>>>>> Changes since the previous version:=0A>= >>>>>>>>>>>> =0A>>>>>>>>>>>>> o=C2=A0 default address selection =0A> prece= dence and label =0A>>>>>>>>>>>>> values=0A>>>>>> =0A>>>>>> o=C2=A0 commen= t about other IPv4 in IPv6 address forms=0A>>>>>>>>>>>>> =0A>>>>>>>>>>>>> = o=C2=A0 more clarifications=0A>>>>>>>>>>>>> =0A>>>>>>>>>>>>> o=C2=A0 gramm= ar corrections=0A>>>>>>>>>>>>> =0A>>>>>>>>>>>>> =0A>>>>>>>>>>>>> My thanks= to Bill Atwood, Matts =0A> Kallioniemi and =0A>>>>>>>>>>>>> Tina Tsou =0A= >>>>>> =0A>>>>>> for their=0A>>>>>>>> =0A>>>>>>>> review and comments on = this revision.=0A>>>>>>>>>>>>> =0A>>>>>>>>>>>>> Further review and comment= s =0A> would be most =0A>>>>>>>>>>>>> appreciated.=0A>>>>>> =0A>>>>>> =0A>= >>>>>>>>>>>> Thanks,=0A>>>>>>>>>>>>> Mark.=0A>>>>>>>>>>>>> =0A>>>>>>>>>>>= =0A>>>>>>>>>>> =0A>>>>>>>>>>> =0A>>>>>>>>>> =0A> _________________________= ______________________=0A>>>>>>>>>> v6ops mailing list=0A>>>>>>>>>> v6ops= @ietf.org=0A>>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops=0A>>>>>= >>>>> =0A>>>>>>>>>> =0A> _______________________________________________=0A= >>>>>>>>> v6ops mailing list=0A>>>>>>>>> v6ops@ietf.org=0A>>>>>>>>> http= s://www.ietf.org/mailman/listinfo/v6ops=0A>>>>>>>>> =0A>>>>>>>> =0A>>>>>> = =0A>>>> _______________________________________________=0A>>>> v6ops mail= ing list=0A>>>> v6ops@ietf.org=0A>>>> https://www.ietf.org/mailman/listin= fo/v6ops=0A>>>> =0A>>> =0A>>> =0A>>> =0A> From joelja@bogus.com Wed Feb 13 22:39: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 09A2321F858E for ; Wed, 13 Feb 2013 22:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.199 X-Spam-Level: X-Spam-Status: No, score=-96.199 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, SARE_RAND_1=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEvZNQRIjLIc for ; Wed, 13 Feb 2013 22:39:42 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6878121F8721 for ; Wed, 13 Feb 2013 22:39:42 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1E6daYS022914 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 14 Feb 2013 06:39:36 GMT (envelope-from joelja@bogus.com) Message-ID: <511C86A4.90903@bogus.com> Date: Wed, 13 Feb 2013 22:39:32 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Mark Smith , Owen DeLong References: <20130211201224.30400.1936.idtracker@ietfa.amsl.com> <1360614005.94432.YahooMailNeo@web142501.mail.bf1.yahoo.com> <255CAE42-6678-4248-B81A-653FA4B95FEF@delong.com> <51196486.9030007@umn.edu> <511974BE.80001@dougbarton.us> <1360652761.32530.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1360698215.11634.YahooMailNeo@web142501.mail.bf1.yahoo.com> <340BD66E-7C12-4557-8DF3-F8E2E1E73BF1@delong.com> <1360701239.40460.YahooMailNeo@web142506.mail.bf1.yahoo.com> <4246F179-FE1D-43F6-B984-4C3099F69402@delong.com> <1360742992.43052.YahooMailNeo@web142505.mail.bf1.yahoo.com> <7CF3EA92-AEB2-42C2-949E-951E2C471686@delong.com> <1360822542.4513.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1360822542.4513.YahooMailNeo@web142505.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Feb 2013 06:39:37 +0000 (UTC) Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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, 14 Feb 2013 06:39:45 -0000 On 2/13/13 10:15 PM, Mark Smith wrote: > So you've resorted to insults. I ignore people who resort to insults, because they've clearly run out of actual points of argument, and won't accept that other people have and can have different ones. > This branch of the thread can stop now. > ----- Original Message ----- >> From: Owen DeLong >> To: Mark Smith >> Cc: v6ops v6ops WG >> Sent: Wednesday, 13 February 2013 8:57 PM >> Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >> >> >> On Feb 13, 2013, at 12:09 AM, Mark Smith >> wrote: >> >>>> ________________________________ >>>> From: Owen DeLong >>>> To: Mark Smith >>>> Cc: "v6ops@ietf.org" >>>> Sent: Wednesday, 13 February 2013 12:46 PM >>>> Subject: Re: [v6ops] New Version Notification for >> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>>> >>>> I had actually read it, but, since you insist… >>>> >>>> >>> I think it is an obligation of being a member of this mailing list if you >> are going to disagree with parts of an ID publicly. >> As I said, I had actually read it. In spite of your claim that I hadn't. >> While my subsequent post was more detailed than my previous arguments, I do not >> think any of my previous arguments were in any way inconsistent with the >> subsequent more >> detailed post. >> >>>> 1. >>>> Under IPv4, the 127/8 loopback prefix [RFC1122] provides many >>>> addresses that can be used to run multiple instances of an application >> on the same port, while also limiting access to the local host. >>>> >>>> RFC1122 provides that 127/8 cannot appear outside of a host. It does >> not require that the host process all addresses within 127/8 as you describe. >>> You're right it doesn't say that. It is common convention to do so, >> and has been a useful one to me and others. I will change the text to reflect >> that it is a common convention. >> I don't know how common that convention is. We've identified only 2 >> operating systems that actually do so as yet. I don't know what the behavior >> in other BSD derivatives, embedded operating systems, etc. is. Certainly it is >> not common enough that I would consider counting on it a good strategy for >> portable code. >> >>>> 2. >>>> Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a >> single address. Multiple application instances using the same port, bound to >> different loopback addresses, is not possible. >>>> >>>> Is not true. You can configure additional addresses on to the loopback >> interface as desired and use them just as you would additional addresses from >> the 127/8 address range. Since RFC1122 does not require that the host treat all >> these addresses identically as you assume, there is no difference between the >> current standards in IPv6 and the current standards in IPv4 except that IPv4 >> sets aside a dedicated 16.7 million host addresses for this purpose (of which >> only one is utilized in most cases) and IPv6 sets aside 1. However, you are >> free to assign any GUA or ULA prefix to the IPv6 loopback and use it in the same >> manner as you are currently using the other 127/8 addresses. >>> I think you're choosing to misread this two sentence paragraph. Normal >> English convention is that sentences subsequent to the first in a paragraph are >> in the context of the topic described by the first sentence. Specifying the >> topic of a paragraph in each sentence is redundant. The second sentence is >> describing a limitation with the ::1/128 loopback prefix, which I'm >> confident is obvious to most English speakers. One of my past reviewers >> isn't a native English speaker, and they have had no trouble with that >> paragraph. >>> GUAs and ULAs aren't loopback prefixes (see RFC4291 and RFC4193), so my >> statement is true. >> Your statement is not true. Multiple application instances using the same port >> bound to different loopback addresses is possible. The fact that the loopback >> addresses in question must be pulled from the ULA or GUA pools is irrelevant to >> the truth or falsehood of the statement. Once you assign an address to a >> loopback interface, it is by definition a loopback address whether or not it >> came from a "loopback prefix". >> >>>> 3. >>>> A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be >> used to increase the number of addresses available on the local host. However >> this prefix would need to be manually generated and configured at least once by >> a system administrator or operator. Without additonal configuration, traffic >> towards addresses not assigned to the local host would not be prevented from >> leaving the host, and access may not be limited to the local host. A ULA prefix >> would not be well known, and would not be convenient to remember and type >> without violating the randomness requirements of the Global ID component of a >> ULA prefix. >>>> >>>> Since the communication of this prefix in this case would not be >> expected to extend beyond the host, the >>>> only requirement is that the ULA prefix chosen not conflict with one >> that the host is expected to need to reach outside of the host. As such, >> fd00::/48 is a perfectly viable candidate in the vast majority of cases as it is >> very unlikely to conflict with a randomly chosen routable prefix that follows >> the standards in RFC4193. >>>> >>>> The Global ID component of a ULA prefix is intended to avoid conflicts >> in the results of M&A, etc. Since this would be host-local addressing and >> not even have site-scope, use of a known non-conflicting ULA address is >> perfectly feasible. fd00::/48 is very unlikely to conflict (1 in 2^40 or < >> 0.000,000,000,1% or <1 in 1e12). >>> So what would happen if you had an IPv6 CPE that was announcing fd00::/64 >> in it's RAs (slide 26 …), and you configured fd00::/48 or fd00::/64 on one >> of your loopback interfaces? >> You'd be unable to reach the other hosts using that prefix most likely. >> However, one wouldn't expect that you would do such a thing. If your router >> is actually using fd00::/64, you'd want to use something else for the >> loopback. Fortunately, you have 40 bits worth (more than a trillion) other >> prefixes to choose from. >> >>>> 4. >>>> 2. Larger Loopback Prefix Requirements A new larger loopback prefix >> should attempt to satisfy all of the following requirements. It should: o be a >> well known prefix, o be within an existing special purpose prefix, such as >> 0000::/8 (the parent prefix of the current IPv6 loopback address), o be easy >> for a human to remember, o be easy for a human to type, o cover the existing >> loopback prefix, o support 64 bit Interface Identifiers, o provide a large >> number of /64 subnets. >>>> >>>> I believe that fd00::/48 could do what you describe: >>>> >>>> >>>> 1.I question the need for it to be well known. As long as it is well >> known within >>>> the scope of the intended use, I think that suffices for the use cases >> you have >>>> described. >>>> >>> Well known makes it easy to add to ACLs. Well known makes it easy to >> remember. Well known means it is the same on all hosts. >> If it's a loopback, what's the point of putting it in ACLs? Since the >> packets shouldn't leave the host, there's not much utility to ACLs. >> >> As long as it's well known within the context (i.e. workgroup, company, >> site, whatever administrative boundary you >> decide is appropriate under the circumstances) it still meets those requirements >> anyway. >> >>> People will even turn an "unusable definition of the loopback >> address", used to "encourage use of officially-assigned >> addresses", into the well known loopback address. >>> http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8603.mm.www/0184.html >>> >> That URL leads to a rather lengthy rant about bugs in 4.2 (and 4.3) BSD which I >> believe were fixed many years ago. >> >> It talks about software mistakenly choosing the loopback address as a source >> address when creating a reply packet in UDP. I fail to see any relevance to the >> current proposal other than as a possible further indication of just how bad an >> idea this actually is, since the closest connection that comes to mind is the >> probability of implementing this draft leading to the introduction of similar >> bugs. >>> >>>> fd00::/48 could easily meet that test. >>>> >>> And fails to comply with the RFC that defines the address space it falls >> within. From RFC4193: >>> " The allocation of Global IDs is pseudo-random [RANDOM]. They MUST >> NOT be assigned sequentially or with well-known numbers." >>> "Locally assigned Global IDs MUST be generated with a pseudo-random >>> >>> algorithm consistent with [RANDOM]." >>> >>> So your proposal violates that RFC, and therefore you would need to write >> an ID changing it to support your use of the Global ID zero value. >> Or you sanely realize that the reason for that is the assumption that the >> addresses would be applied to routable interfaces and not loopbacks. Certainly >> an ID using fd00::/48 would be preferable to this debacle as it doesn't >> require any software updates and provides the same functionality. >> >> However, as I pointed out, fd00::/48 was just an easy example. You could use a >> truly random ULA if you were so inclined, but you lose out on the easy to >> type/easy to remember features. >> >>>> 2.fd00::/48 is within the existing ULA special purpose prefix. >>>> 3.fd00::/48 is very easy for a human to remember. >>>> 4.fd00::/48 is very easy for a human to type. >>>> 5.Please justify your claim that it should encompass the existing >> loopback address. >>> I'd have thought it'd be obvious that expanding the existing prefix >> would have been better if possible. I'd have thought this text would convey >> that. >> >> Better in what way. You still haven't actually justified this claim, >> you've merely told me it should be obvious. >> >> Certainly, if it's so obvious, it shouldn't be hard to explain. >> >>> "Ideally, the prefix length of ::1/128 could be shortened, resulting >> in a larger loopback prefix such as ::/48. However, if the existing loopback >> prefix length is shortened enough to satisfy all of the larger loopback prefix >> requirements, it would then cover the IPv4 Mapped IPv6 Address prefix, >> ::ffff:0.0.0.0/96, and prevent its use described in [RFC4038]." >> Yes, I read that. Restating it adds nothing to the discussion. You still >> haven't said anything which supports your claim that this would somehow be >> ideal." >> >>> >>>> 6.fd00::/48 supports 64 bit IIDs. >>>> 7.fd00::/48 provides 65,536 /64 subnets. Is there some reason you think >> this is insufficient? >>>> This is a total of 4 billion times 16.7 million times as many host >> addresses as were provided >>>> in the IPv4 loopback. >>>> >>> It is quite adequate, and the size I proposed in the first two drafts. >> However, under 0000::/8, it's possible to make it a /32, because their are >> 16 million of them. Since this draft is revisiting the original ::1/128 >> decision, why not make every attempt that can be easily afforded to avoid >> revisiting the IPv6 loopback prefix the 3rd time. "More than enough" >> is better than "just enough" when cheap enough, as it saves coming >> back for more. >> For that matter, it's possible to make it a /16 or a /64, but I don't >> see any justification for those numbers, either. >> >> I would argue that if you can't do it in 65,536 times 18 quintillion >> loopback addresses, it probably won't fit in any host ever likely to be >> manufactured within the useful lifetime of IPv6. >> >> OTOH, given how much we wish we could have revisited the absolutely moronic >> choice to waste an entire /8 on IPv4 loopbacks, going to a /32 seems likely to >> be equally moronic. While I personally think this is a boondoggle to begin with, >> if it is to be adopted, I certainly thin a /48 is so much more than enough that >> multiplying that mistake by 65,536 makes no sense whatsoever. >> >>>> It is 1/256th as many networks as IPv4 provided loopback hosts. >>>> >>>> >>>> 5. >>>> 3. Proposed Larger Loopback Prefix Ideally, the prefix length of >> ::1/128 could be shortened, resulting in a larger loopback prefix such as >> ::/48. However, if the existing loopback prefix length is shortened enough to >> satisfy all of the larger loopback prefix requirements, it would then cover the >> IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use >> described in [RFC4038]. Giving up the requirement of covering the existing >> loopback prefix, the proposed larger loopback prefix is: >>>> >>>> >>>> So why not simply delete this from the requirements list as you've >> failed to >>>> provide any justification for said requirement anyway. >>> Requirementlists define both wants and needs. It's there because more >> than once people have asked why not just shorten the prefix length of the >> existing prefix. >> >> Interesting… That was the part I considered obvious. I still don't see any >> advantage to doing so vs. using space somewhere else. >> >>>> Smith Expires August 15, 2013 [Page >> 4] >>>> Internet-Draft A Larger IPv6 Loopback Prefix February >> 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 This prefix >> satisfies all remaining larger loopback prefix requirements. >>>> >>>> I think this is a terrible choice of location. It pretty much maximizes >> the fragmentation damage that can be done by the choice of prefix. :1::/32 would >> at least be the first /32 available. As I've stated, a locally chosen >> address such as fd00::/48 (or whatever selection of chosen ULA space meets local >> requirements) is equally viable IMHO. >>> The goal was the shortest thing to type, and I don't think >> fragmentation matters within 0000::/8. I think people will commonly forget the >> colon on the front of :1::/32, or mix up where the two contiguous colons are >> e.g. they'll type ::1:/32. >> Good arguments against using 1::/32 as well. >> >>>> 6. >>>> Allocating a /32 prefix for the loopback function may seem excessive, >> as a /48 length prefix would satisfy the larger loopback prefix requirements. >> However, within the parent 0000::/8 special purpose prefix, there are >> approximately 16 million /32 prefixes, so a single /32 for the larger loopback >> prefix is easily afforded. A /32 larger loopback prefix will satisfy all >> current and likely future uses of the loopback function. >>>> >>>> Allocating a /32 is absurdly excessive and just because we can does not >> strike me as anything remotely resembling an argument that we should. >>> So you're saying that you can think of better uses for the 16 million >> /32s within 0000::/8, such that just one can't be used for this purpose? >> What are some of your better uses? >> No, but I am saying I'm willing to bet that other better uses for the other >> 65,535 /48s in 1::/32 are not at all unlikely to come along. >> >>>> 4. Address Assignment and Configuration >>>> >>>> >>>> Consistent with the IPv6 addressing model [RFC4291], each address >> within the larger loopback prefix is associated with one of the node's >> interfaces, although not necessarily the same interface for all addresses. This >> means that the node acts as though all addresses within the larger loopback >> prefix have been configured on one or more interfaces. Applications will accept >> packets destined to any of the larger loopback prefix addresses, unless the >> application is bound to specific larger loopback addresses. Typically the >> addresses will be logically assigned to one or more virtual "loopback" >> interfaces, which locally returns or loops outgoing packets back to the same >> node that originated the packets. >>>> >>>> >>>> >>>> >>>> >>>> I believe you have misread and conflated RFC4291 and RFC1122 with >> regards to how loopback >>>> addresses function. >>>> >>> This is specifying the address assignment and configuration scheme for the >> proposed larger loopback prefix. You have misread and misunderstood this text. >> No, I didn't. However, you claim "Consistent with…" and follow it >> with a description which is not consistent. >> >>>> Unless I am mistaken, there is no requirement in RFC1122 that a node >> answer all addresses within 127/8. >>>> >>>> Some nodes may support more than one loopback interface. These >> subsequent loopback interfaces, when initialised, should be assigned Smith >> Expires August 15, 2013 [Page 5] >>>> Internet-Draft A Larger IPv6 Loopback Prefix February >> 2013 a larger loopback /64 prefix locally unique within the node. All addresses >> within the assigned /64 are logically assigned to the interface. Additionally, >> the ":1" address for the subnet should be configured on the loopback >> interface, making it visible to a system operator or user. >>>> >>>> This would, indeed, be new functionality. I am not convinced of any >> value to having that functionality and it is radically different from any >> required functionality in IPv4 today. In IPv4, hosts which support multiple >> loopbacks have no default address or range on the subsequent loopback >> interfaces. >>> Right. The goal here is to take something useful in IPv4 that doesn't >> exist in IPv6, and then to also see if there are opportunities to make further >> improvements. This is not a literal copy of IPv4 functionality into IPv6. >> Changes to fix limitations are also opportunities to make improvements. >> My point is that the capability that exists in IPv4 today also exists in IPv6 >> already. The only difference is the pool of addresses you have to choose from >> for that purpose. In IPv4, you have, in addition to the global unicast, >> RFC-1918, and in some circumstances, link local addresses the normally unused >> addresses within 127/8. In IPv6, you are limited to the ULA and GUA in addition >> to ::1/128. >> >>>> If you cannot justify a need for this functionality, I see no point in >> advancing it as a standard. >>> I have justified it, in Abstract and the Introduction. You might not >> believe there is a problem to solve, but that doesn't mean that other people >> don't, and that they haven't experienced a problem. In addition to >> myself, Erik Kline and Vijayrajan Ranganathan have encountered situations where >> more IPv6 loopback addresses would be useful: >> Your justification isn't. The problem statements you have presented so far >> can be solved without requiring software modifications to every IPv6 stack. >> >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg14815.html >>> >>> >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg10882.html >>> >>> >>> Here is Erik, back in 2009, describing the exact scenario that I've >> described in the Abstract and Intro. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg11018.html >>> >> I'm not saying your problem shouldn't be solved. I'm saying that it >> already has been. >> >>> >>> >>>> It should be possible for an operator to remove these automatically >> configured loopback addresses. It should also be possible for an operator to >> configure further loopback addresses from within the assigned /64, or addresses >> from other parts of the larger loopback prefix, including other /64s assigned to >> other loopback interfaces. Other addresses within the assigned /64(s) would >> continue to be logically assigned to the subsequent loopback interface. >> Configuration of addresses is for operational visibility and convenience, and >> does not change the behaviour of non-visible logically assigned addresses. >>>> >>>> If you're going to do this, then I would argue that it >> "must" be possible for an operator to remove… >>> ok. I've tried to avoid being too absolute in this area because >> it's describing operator/system interface functionality, rather than things >> a compliant implementation must do. >> But you don't say that a compliant implementation must. As written, your >> draft would allow a compliant implementation which did not allow operator >> removal. I consider this highly undesirable. >> >>>> The rest of what you suggest strikes me as being a kernel routing >> hairball of unnecessarily large >>>> proportion and likely to engender more bugs than functionality. >>>> >>> I'm curious as to what experience you have to be able to make that >> judgement. Using Linux as an example IPv6 implementation, I know enough about >> the Linux kernel networking code that I'm pretty sure it shouldn't be >> too hard to make these changes. >> I know that most hosts today do not behave well and most routers won't even >> allow you to configure overlapping prefixes >> and addresses on multiple interfaces. Admittedly, some of that is due to the >> fact that the desired behavior is not defined anywhere, which admittedly is >> addressed to some extent in your draft. However, even with those definitions it >> still strikes >> me as being quite a mess both from a principle-of-least-surprise perspective as >> well as a complexity for the sake of >> complexity perspective. >> >> Owen >> >>>> ------ >>>> >>>> >>>> This covers the first 6 pages (approximately half of the draft). >> I'm not going to take the time to write up the problems in the rest of the >> draft at this point because the above are, IMHO, more than sufficient reason to >> oppose adoption. >>>> >>>> Owen >>>> >>>> >>>> On Feb 12, 2013, at 4:18 PM, Owen DeLong wrote: >>>> >>>> >>>>> On Feb 12, 2013, at 12:33 PM, Mark Smith >> wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> >>>>>> From: Owen DeLong >>>>>>> To: Mark Smith >>>>>>> Cc: Doug Barton ; >> "v6ops@ietf.org" >>>>>>> Sent: Wednesday, 13 February 2013 6:59 AM >>>>>>> Subject: Re: [v6ops] New Version Notification for >> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt >>>>>>> >>>>>>> >>>>>>>>> ?? I don't see how it gets easier to remember >> than fd00::/8 >>>>>>>> The random bit is the hard bit to remember and type. I >> don't think >>>>>>>> you're thinking enough about how it is to use, >> you're only thinking >>>>>>> about how hard it is to configure. The time and effort to >> configure something is >>>>>>> usually minimal compared to the amount of time and effort >> spent while it is >>>>>>> being used. >>>>>>> >>>>>>> >>>>>>> Nothing requires you to use random for this purpose. Use >> fd00::/64 for all >>>>>>> anyone cares. >>>>>>> >>>>>>> >>>>>> RFC4193 does. It's not a ULA if it doesn't, it's >> been made a site-local. See RFC3879 for the problems with them and your >> non-random ULA. >>>>>> >>>>> Which is irrelevant to the loopback scenario you have described… >>>>> >>>>> >>>>> >>>>>> and you can use >>>>>>>> anything you want inside of that to provide a /64 for >> your development >>>>>>>>> purpose. >>>>>>> >>>>>>>>> What's more cumbersome about picking something >> (even fd00::/64, if >>>>>>>>> you want) >>>>>>> >>>>>>>> No, that's bad, as it is a ULA prefix which >> doesn't have a random >>>>>>>> component. Add the random component (if you aren't >> lazy), and it then >>>>>>> becomes hard to remember and type. >>>>>>> >>>>>>> >>>>>>> Why is it bad that it doesn't have a random component? >> If it's in a >>>>>>> development test lab, it's not like it's at risk of >> corporate merger >>>>>>> conflicts, etc. >>>>>>> >>>>>>> >>>>>> See slide 26. >>>>>> >>>>>> http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf >>>>>> >>>>>> >>>>> Which does not apply to use on a loopback interface. >>>>> >>>>> >>>>> >>>>>> for development than having some other prefix you have to >> configure >>>>>>>>> assigned by >>>>>>> >>>>>>>> the IETF. >>>>>>>> I'm starting to wonder if you've actually read >> the draft. The >>>>>>>> intention is that it is that the larger loopback prefix >> automatically configured >>>>>>> at system initialisation, as ::1/128 and 127/8 currently >> are. There is a whole >>>>>>> section on automatic address assignment and configuration. >>>>>>> >>>>>>> 127/8 isn't auto-assigned. 127.0.0.1/8 is. >>>>>>> >>>>>>> >>>>>> That's incorrect. >>>>>> >>>>>> RFC1122, "Requirements for Internet Hosts -- Communication >> Layers", specifically the in >>>>>> "(g) { 127, } >>>>>> Internal host loopback address. Addresses of this form MUST >> NOT appear outside a host." >>>>>> >>>>> Yes, it requires that you not have addresses within 127.0.0.0/8 >> appear outside of the host. It does >>>>> not require the host to answer or auto configure all of the >> 127.0.0.0/8 addresses on its loopback >>>>> interface and, indeed, most hosts do NOT auto configure other than >> 127.0.0.1. >>>>> >>>>> >>>>>> >>>>>>>>> Sorry, but I just don't get it. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This proposal also takes the opportunity to >> introduce IPv4-like >>>>>>>>>> handling of >>>>>>> loopback IPv6 packets so that future functions similar to >> the use in >>>>>>>>> RFC4379 >>>>>>> have a native IPv6 address space to use, rather than using >> 127/8 within >>>>>>>>> an IPv6 >>>>>>> prefix. >>>>>>>>> In my (admittedly limited) testing, putting a /64 >> of ULA on the >>>>>>>>> loopback >>>>>>> interface did just that, so I'm not sure what it is >> that you feel >>>>>>>>> is >>>>>>> missing. >>>>>>>>> >>>>>>>> All addresses within 127/8 are valid and available on >> the host, where as >>>>>>>> with your ULA, only 1 is. >>>>>>> >>>>>>>> e.g. >>>>>>>> >>>>>>>> >>>>>>>> [root@opy mark]# ip addr show dev lo >>>>>>>> 1: lo: mtu 65536 qdisc >> noqueue state UNKNOWN >>>>>>>> link/loopback 00:00:00:00:00:00 brd >> 00:00:00:00:00:00 >>>>>>>> inet 127.0.0.1/8 scope host lo >>>>>>>> inet6 fd00:db8::1/64 scope global >>>>>>>> valid_lft forever preferred_lft forever >>>>>>>> inet6 1::1/64 scope global >>>>>>>> valid_lft forever preferred_lft forever >>>>>>>> inet6 ::1/128 scope host >>>>>>>> valid_lft forever preferred_lft forever >>>>>>>> >>>>>>>> [root@opy mark]# ping -c 1 127.1.2.3 >>>>>>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>>>>>>> 64 bytes from 127.1.2.3: icmp_req=1 ttl=64 time=0.053 >> ms >>>>>>>> --- 127.1.2.3 ping statistics --- >>>>>>>> 1 packets transmitted, 1 received, 0% packet loss, time >> 0ms >>>>>>>> rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms >>>>>>>> [root@opy mark]# >>>>>>>> >>>>>>>> >>>>>>> Interesting… I get this behavior on MacOS. >>>>>>> >>>>>>> [tc01-dhcp153:~] owen% ifconfig lo0 >>>>>>> lo0: flags=8049 mtu >> 16384 >>>>>>> options=3 >>>>>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >>>>>>> inet 127.0.0.1 netmask 0xff000000 >>>>>>> inet6 ::1 prefixlen 128 >>>>>>> >>>>>>> [tc01-dhcp153:~] owen% ping 127.1.2.3 >>>>>>> PING 127.1.2.3 (127.1.2.3): 56 data bytes >>>>>>> Request timeout for icmp_seq 0 >>>>>>> Request timeout for icmp_seq 1 >>>>>>> Request timeout for icmp_seq 2 >>>>>>> Request timeout for icmp_seq 3 >>>>>>> ^C >>>>>>> --- 127.1.2.3 ping statistics --- >>>>>>> 5 packets transmitted, 0 packets received, 100.0% packet >> loss >>>>>>> >>>>>> So MacOS isn't compliant with RFC1122. >>>>>> >>>>>> >>>>> How do you figure that? You'll need to be more specific. >>>>> >>>>> >>>>> >>>>>> Admittedly, Linux does this: >>>>>>> owen.delong.com:owen /home4/owen (22) % ifconfig lo >>>>>>> lo Link encap:Local Loopback >>>>>>> inet addr:127.0.0.1 Mask:255.0.0.0 >>>>>>> inet6 addr: ::1/128 Scope:Host >>>>>>> UP LOOPBACK RUNNING MTU:16436 Metric:1 >>>>>>> RX packets:45816328 errors:0 dropped:0 overruns:0 >> frame:0 >>>>>>> TX packets:45816328 errors:0 dropped:0 overruns:0 >> carrier:0 >>>>>>> collisions:0 txqueuelen:0 >>>>>>> RX bytes:578712867 (551.9 MiB) TX bytes:578712867 >> (551.9 MiB) >>>>>>> owen.delong.com:owen /home4/owen (23) % ping 127.1.2.3 >>>>>>> PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data. >>>>>>> 64 bytes from 127.1.2.3: icmp_seq=1 ttl=64 time=0.043 ms >>>>>>> 64 bytes from 127.1.2.3: icmp_seq=2 ttl=64 time=0.032 ms >>>>>>> 64 bytes from 127.1.2.3: icmp_seq=3 ttl=64 time=0.019 ms >>>>>>> ^C >>>>>>> --- 127.1.2.3 ping statistics --- >>>>>>> 3 packets transmitted, 3 received, 0% packet loss, time >> 2000ms >>>>>>> rtt min/avg/max/mdev = 0.019/0.031/0.043/0.010 ms >>>>>>> owen.delong.com:owen /home4/owen (24) % >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> [root@opy mark]# ping6 -c 1 fd00:db8::2 >>>>>>>> connect: Network is unreachable >>>>>>>> [root@opy mark]# >>>>>>>> >>>>>>>> [mark@opy ~]$ ssh 127.1.2.3 >>>>>>>> The authenticity of host '127.1.2.3 >> (127.1.2.3)' can't be >>>>>>>> established. >>>>>>> >>>>>>>> [mark@opy ~]$ ssh -6 fd00:db8::2 >>>>>>>> ssh: connect to host fd00:db8::2 port 22: Network is >> unreachable >>>>>>>> [mark@opy ~]$ >>>>>>>> >>>>>>>> >>>>>>> From what I can see, this seems to depend on a pathology >> not universally >>>>>>> available even in IPv4. >>>>>>> >>>>>>> >>>>>>> Another test you should do to measure the usefulness of >> this proposal is >>>>>>>> see how long it takes and your opinion afterwards of >> how hard or easy it is to >>>>>>> type or cut and paste "fd00:db8::1" vs >> "1::1" a reasonable >>>>>>> number of times e.g. 6 times. >>>>>>> >>>>>>> >>>>>>> I'm fine with it. If you're doing it more than 6 >> times, that's what >>>>>>> DNS is for. >>>>>>> >>>>>>> >>>>>> That's an option, for applications that use DNS to resolve >> addresses. There are applications that need to deal with addresses directly, >> such as mine, due to their nature and purpose. >>>>> Then use a configuration file or whatever. There are lots of >> alternatives to repeatedly typing in addresses. >>>>> (command-line aliases come to mind as an example). >>>>> >>>>> >>>>> >>>>>> >>>>>>>> Using a ULA doesn't really work at all. It only >> adds another address to >>>>>>>> the host, rather than many. A properly formed ULA is >> hard to type and remember. >>>>>>> It's far less user friendly than the short larger >> loopback prefix I'm >>>>>>> proposing. This is based on my experience, as I've used >> a ULA for the >>>>>>> purpose of trying to increase the number of loopback IPv6 >> addresses. >>>>>>> >>>>>>> The same is true with loopback except on Linux as near as I >> can tell. >>>>>>> >>>>>> Windows 7 also behaves this way, as it complies with RFC1122. >>>>>> >>>>>> >>>>> Nothing I found in RFC 1122 requires this, so if you think >> something does, you'll >>>>> need to point it out. >>>>> >>>>> I know for a fact that several Cisco switches did not. For example, >> they used to use >>>>> 127.0.0. as a convenient hack for connections >> across the backplane >>>>> to the IP stack running on IP-aware blades such as RSMs. >>>>> >>>>> >>>>> >>>>>>>> Note, I don't know the answer, but I'm leaning >> heavily >>>>>>>>>>> towards, >>>>>>> >>>>>>>>> "no." >>>>>>>>>>> Primarily because we're asking people >> to deploy this >>>>>>>>>>> protocol for >>>>>>> real-world scenarios, and we already have a pretty wide >>>>>>>>>>> divergence in >>>>>>> the latest state of the standards vs. the oldest working >>>>>>>>>>> deployed base. >>>>>>> >>>>>>>>> Widening that gap should only be done for truly >> critical >>>>>>>>>>> changes, and >>>>>>> I'm not sure you've made your case sufficiently. >>>>>>>>>>> Put more simply, at some point we have to >> stop tinkering with >>>>>>>>>>> the plane >>>>>>> >>>>>>>>> while it's in the air. >>>>>>>>>>> >>>>>>>>>> So I think the implication of that analogy is >> that deploying this >>>>>>>>>> enhancement will somehow interrupt the existing >> operation of IPv6 >>>>>>>>> implementations ("the plane") causing >> them to fail >>>>>>>>> ("fall out of >>>>>>> the sky"). I don't see how that will be the case. >> Deploying a >>>>>>>>> new >>>>>>> loopback prefix would leverage many of the existing address >>>>>>>>> configuration and >>>>>>> loopback related functions of existing IPv6 >> implementations. It is not >>>>>>>>> much more >>>>>>> than a larger version of ::1/128. >>>>>>>>> The implication is that you are requesting to once >> again obsolete all >>>>>>>>> existing >>>>>>> implementations in favor of requiring deploying another >> fundamentally >>>>>>>>> changed >>>>>>> IPv6 stack. >>>>>>>> Can you define the threshold of "fundamentally >> changed" for me? >>>>>>>> >>>>>>> Requiring a modification to every existing IPv6 stack in >> the wild which could be >>>>>>> incorporated into software dependencies which would render >> existing stacks >>>>>>> unexpectedly >>>>>>> obsolete. >>>>>>> >>>>>>> >>>>>>> I don't consider this to be a fundamental change. It is >> adding another >>>>>>>> loopback prefix, which operates the same as the >> existing one, just with a >>>>>>> shorter prefix length. It is adding values to the source >> and destination address >>>>>>> selection policy, which is already possible to do because >> it's been designed >>>>>>> that way. I'm quite confident that it is going to be no >> more than 10 lines, >>>>>>> and probably closer to 5 additional lines of code in a >> stack for a host >>>>>>> implementation that only supports a single loopback >> interface. That's code >>>>>>> change size closer to the size of bug fixes than additional >> functionality. >>>>>>> >>>>>>> So you want to force everyone to update their IPv6 stack on >> every host, router, >>>>>>> switch, etc. just so you can save some typing? >>>>>>> >>>>>>> >>>>>> The IETF (and I) can't force anything. If it's useful, >> it'll be implemented. >>>>>> >>>>> IMHO, it's not all that useful and making it a stack >> requirement would lead to one of two bad situations: >>>>> 1.Development resources would be taken away from tasks that matter. >>>>> or >>>>> 2.Increasing divergence between the implemented stacks and the >> documented standards. >>>>> >>>>> >>>>> You're doing a very good job cementing my opposition here. >>>>>>> >>>>>> You seem to like doing things the hard way. My view is >> computers should do things automatically for people so that people can get on >> with more valuable things. Developers should be cutting code instead of setting >> up development environments, or waiting for system administrators to set up the >> development environment for them. >>>>>> >>>>> Actually, I do not. However, I do not believe in using the entire >> IP stack development community as a workforce to save me a little bit of typing >> which, as near as I can tell is all that this proposal would accomplish. >>>>> The functionality you seek is available using ULA. The issues you >> cite with ULA would not apply to loopback usage. The functionality that you >> attribute to RFC 1122 isn't (as near as I can tell) actually codified into >> RFC 1122 (I don't see how requiring that an address range not appear outside >> of a host requires that host to accept all packets to any address in said range, >> which is what you are claiming). >>>>> >>>>> My definition of a fundamental change would be to do something like >> change >>>>>>>> the change the size of the IPv6 address, or reorder the >> fields in the IPv6 >>>>>>> header. >>>>>>> >>>>>>> >>>>>>> That would be a drastic change, indeed. This is less >> drastic, but it would make >>>>>>> current IPv6 stacks incompatible with the protocol >> definition. >>>>>>> >>>>>> I don't get this. 1::/32 is not currently used for >> anything, so using it is not going to make it incompatible with anything. Using >> other prefixes for purposes that they weren't designed for, such as a ULA as >> a loopback, has far greater risk of creating incompatibility. >>>>> If you add this as a required stack feature, stacks which don't >> implement the feature are no longer compliant. >>>>> >>>>> >>>>>> The question is whether there is enough value in the change to >>>>>>>>> justify such a decision and IMHO, at this point, >> just to make it >>>>>>>>> "less >>>>>>> cumbersome" than putting (a) ULA address(es) on the >> loopback >>>>>>>>> interface >>>>>>> strikes me as not having much value. >>>>>>>>> >>>>>> You don't seem to be placing any value convenience. Does >> your car have an automatic transmission? Do you have a dishwasher? Do you go to >> restaurants? All of those things only exist because humans place value on the >> convenience of not manually changing gears, not manually washing dishes, and not >> cooking at home when we could. Why have to do something manually when a computer >> could do it automatically for you? >>>>>> >>>>> I place tremendous value on convenience. My car does not have a >> traditional automatic transmission, my car has an ECVT transmission. If I were >> buying a car, I would actually prefer a manual transmission because I prefer the >> greater control flexibility and shifting precision afforded by a manual >> transmission. >>>>> Yes, I go to restaurants. >>>>> >>>>> There are many equally automatic solutions to your problem already >> available without involving the entire body of protocol developers and the IETF >> in the process. >>>>> Owen >>>>> >>>>> >>>>> Owen >>>>>>>>> >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Mark. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Doug >>>>>>>>>>> >>>>>>>>>>> On 02/11/2013 01:37 PM, David Farmer wrote: >>>>>>>>>>> >>>>>>>>>>> On 2/11/13 14:28 , Owen DeLong wrote: >>>>>>>>>>>> Perhaps I'm not very bright, but is >> there any >>>>>>>>>>>>> reason ULA >>>>>>> couldn't be >>>>>>>>>>> used on the LO interface to >>>>>>>>>>>>> satisfy this corner case? >>>>>>>>>>>>> >>>>>>>>>>>> The Draft does cover why ULA is thought >> to not be a >>>>>>>>>>>> sufficient >>>>>>> solution, >>>>>>>>> do you disagree with the reasoning in the draft? >>>>>>>>>>>> from Section 1; >>>>>>>>>>>> >>>>>>>>>>>> A Unique Local IPv6 Unicast >> Address (ULA) prefix >>>>>>>>>>>> [RFC4193] >>>>>>> could be >>>>>>>>> used to increase the number of addresses >> available on >>>>>>>>>>>> the >>>>>>> local host. >>>>>>>>> However this prefix would need to be manually >>>>>>>>>>>> generated and >>>>>>> configured at least once by a system administrator or >>>>>>> operator. >>>>>>>>> Without additonal configuration, traffic >> towards >>>>>>>>>>>> addresses not >>>>>>> assigned to the local host would not be prevented >>>>>>>>>>>> from leaving >>>>>>> the >>>>>>>>> host, and access may not be limited to the >> local >>>>>>>>>>>> host. A ULA >>>>>>> prefix >>>>>>>>> would not be well known, and would not be >> convenient >>>>>>>>>>>> to >>>>>>> remember and >>>>>>>>> type without violating the randomness >> requirements of >>>>>>>>>>>> the >>>>>>> Global ID >>>>>>>>> component of a ULA prefix. >>>>>>>>>>>> >>>>>>>>>>>> Owen >>>>>>>>>>>>> On Feb 11, 2013, at 12:20 , Mark >> Smith >>>>>>>>>>>>> >> wrote: >>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> Here is a new version of my >> IPv6 larger loopback >>>>>>>>>>>>>> prefix >>>>>>> draft. >>>>>>>>> Changes since the previous version: >>>>>>>>>>>>>> o default address selection >> precedence and label >>>>>>>>>>>>>> values >>>>>>> o comment about other IPv4 in IPv6 address forms >>>>>>>>>>>>>> o more clarifications >>>>>>>>>>>>>> >>>>>>>>>>>>>> o grammar corrections >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> My thanks to Bill Atwood, Matts >> Kallioniemi and >>>>>>>>>>>>>> Tina Tsou >>>>>>> for their >>>>>>>>> review and comments on this revision. >>>>>>>>>>>>>> Further review and comments >> would be most >>>>>>>>>>>>>> appreciated. >>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Mark. >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>> v6ops mailing list >>>>>>>>>>> v6ops@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>>>> >>>>>>>>>>> >> _______________________________________________ >>>>>>>>>> v6ops mailing list >>>>>>>>>> v6ops@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> >>>> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Wed Feb 13 23:11: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 C2F7921F88A9 for ; Wed, 13 Feb 2013 23:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[AWL=3.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54yEZtAszdz5 for ; Wed, 13 Feb 2013 23:11:40 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1993B21E8034 for ; Wed, 13 Feb 2013 23:11:40 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1E7BcqN023723 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 14 Feb 2013 07:11:38 GMT (envelope-from joelja@bogus.com) Message-ID: <511C8E26.3050709@bogus.com> Date: Wed, 13 Feb 2013 23:11:34 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs , Ronald Bonica References: <51100E9D.6050803@bogus.com> <5119B305.9000404@bogus.com> In-Reply-To: <5119B305.9000404@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Feb 2013 07:11:39 +0000 (UTC) Subject: Re: [v6ops] Consensus call, Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.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, 14 Feb 2013 07:11:40 -0000 On 2/11/13 7:12 PM, joel jaeggli wrote: > This call is closed, > > Fred and I will theoretically be able to close the loop on the input > by sometime tomorrow. > > Thank you all for weighing in on this important topic. In terms of results. By my tally 1108 messages or our lists since 1/9/2012 From the point of Ron's question to the list 1/10. Folks, Draft-ietf-v6ops-464xlat is nearly ready for IESG approval. However, several IESG members, including me, are concerned that the WG has not yet considered the IPR declaration attached to this document. So, I will wait one more week before approving this document. If you are concerned about the IPR declaration, please post a message describing your concerns to the list. If no such concerns are posted, I will approve the draft on January 17. to the point of close of deadline we've reviewed roughly 158 Germain messages from 39 participants Not all messages addressed the question and I excluded participants that didn't address the issue. 2 participants expressed a preference for both publication as a bcp and publication at a lower status, I counted them in the later category. I consider this equivalent to a show of hands in the meeting publish 9 lower status 14 don't publish 4 no preference 1 regarding the last category, one participant directly addressed the issue but declined explicitly to state a preference. This represents a similar set of participants as the on list WGLC. but fewer than in the meeting. Generally I interpret the input as indicating that the IPR cliam/terms are not an insurmountable barrier to publication. also that notwithstanding the narrow applicability statement that a plurality if not consensus input would be to reduce the requested status to informational. > > joel > > On 2/4/13 11:40 AM, joel jaeggli wrote: >> To emphasize Fred's request, please share you opinion on whether this >> document should be published intact (as a BCP), with with a lower >> state (informational), or not at all, given the IPR disclosure >> associated with it. >> >> The document can be reviewed here: >> >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-09 >> >> the known IPR disclosure is here: >> >> https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-v6ops-464xlat >> >> >> if you have registered your opinion on this subject already you will >> be counted. >> >> The deadline for commentary is Monday Feb 11th 2012. >> > From joelja@bogus.com Wed Feb 13 23:13: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 460A021E8034 for ; Wed, 13 Feb 2013 23:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.699 X-Spam-Level: X-Spam-Status: No, score=-100.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIg3qmEl99Fa for ; Wed, 13 Feb 2013 23:13:41 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D31A221F88A3 for ; Wed, 13 Feb 2013 23:13:41 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1E7DfA1023765 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 14 Feb 2013 07:13:41 GMT (envelope-from joelja@bogus.com) Message-ID: <511C8EA0.2070708@bogus.com> Date: Wed, 13 Feb 2013 23:13:36 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG , "draft-binet-v6ops-cellular-host-requirements@tools.ietf.org" References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> In-Reply-To: <5109723D.4090905@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Feb 2013 07:13:41 +0000 (UTC) Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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, 14 Feb 2013 07:13:42 -0000 On 1/30/13 11:19 AM, joel jaeggli wrote: > Greetings, > > This kicks of a request for adoption as a working group document on > draft-binet-v6ops-cellular-host-requirements-02.txt > > This document and a similar one were discussed during IETF 85 and were > updated accordingly. Support was far from unanimous at the time and > we're interested in seeing how far it has progressed. > > The deadline for this discussion phase is two weeks from today, 2/13. This test is completed. Thanks joel > thanks > joelja > > On 1/30/13 4:28 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Internet Protocol Version 6 (IPv6) Requirements >> for Cellular Hosts >> Author(s) : David Binet >> Mohamed Boucadair >> Ales Vizdal >> Cameron Byrne >> Gang Chen >> Filename : >> draft-binet-v6ops-cellular-host-requirements-02.txt >> Pages : 17 >> Date : 2013-01-30 >> >> Abstract: >> This document lists a set of IPv6-related requirements to be >> supported by cellular hosts. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-02 >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-host-requirements-02 >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From philip_matthews@magma.ca Thu Feb 14 11:04: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 0071E21F88B5 for ; Thu, 14 Feb 2013 11:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytsRIgjufeYx for ; Thu, 14 Feb 2013 11:04:00 -0800 (PST) Received: from mail-02.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1419321F88B4 for ; Thu, 14 Feb 2013 11:04:00 -0800 (PST) Received: from [24.114.22.111] (helo=[172.20.10.4]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1U646B-0002CN-0Q for v6ops@ietf.org; Thu, 14 Feb 2013 14:03:59 -0500 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Feb 2013 14:03:52 -0500 Message-Id: To: "v6ops@ietf.org 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.22.111] Subject: [v6ops] draft-ietf-v6ops-design-choices-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, 14 Feb 2013 19:04:01 -0000 Folks: I have just submitted draft-ietf-v6ops-design-choices-00, which is a = renamed version of the Design Guidelines draft = (draft-matthews-v6ops-design-guidelines). It should be appearing in the = online drafts repository shortly. Though I had hoped to get a more substantial revision out, work = intervened and I was only able to make a few smaller changes. I have been working on adding more design choices, but ran out of time. = Sorry. Comments on the new version are most welcome. - Philip= From rbonica@juniper.net Thu Feb 14 11:39: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 8677621F85ED for ; Thu, 14 Feb 2013 11:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoukBXZ+Ul3q for ; Thu, 14 Feb 2013 11:39:18 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id B2CDC21F85DF for ; Thu, 14 Feb 2013 11:39:18 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUR09ZsKatwiNmcJn3XQFFNS/EmD6kq4v@postini.com; Thu, 14 Feb 2013 11:39:18 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Feb 2013 11:37:11 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 14 Feb 2013 11:37:10 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 14 Feb 2013 11:39:50 -0800 Received: from mail14-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Feb 2013 19:37:10 +0000 Received: from mail14-tx2 (localhost [127.0.0.1]) by mail14-tx2-R.bigfish.com (Postfix) with ESMTP id 299F2160100 for ; Thu, 14 Feb 2013 19:37:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dh18602ehz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail14-tx2 (localhost.localdomain [127.0.0.1]) by mail14-tx2 (MessageSwitch) id 1360870628516488_32291; Thu, 14 Feb 2013 19:37:08 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.238]) by mail14-tx2.bigfish.com (Postfix) with ESMTP id 7072F180058 for ; Thu, 14 Feb 2013 19:37:08 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Feb 2013 19:37:06 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.49]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0263.000; Thu, 14 Feb 2013 19:37:05 +0000 From: Ronald Bonica To: IPv6 Operations Thread-Topic: Management Changes Thread-Index: Ac4K6qqgGNGLU6YOTUCStYFGnHdFWQ== Date: Thu, 14 Feb 2013 19:37:04 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [v6ops] Management Changes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2013 19:39:19 -0000 Folks, I would like to congratulate Joel Jaeggli on his new role as OPS Area Direc= tor and announce that Joel will be stepping down as V6OPS chair. Please joi= n me in welcoming John Brosowski who, along with Fred Baker, will co-chair = V6OPS. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From fred@cisco.com Thu Feb 14 11:49: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 B30BC21F84F4 for ; Thu, 14 Feb 2013 11:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.103 X-Spam-Level: X-Spam-Status: No, score=-110.103 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6Wn2zdGlQ+7 for ; Thu, 14 Feb 2013 11:49:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 57BE721F84E6 for ; Thu, 14 Feb 2013 11:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=708; q=dns/txt; s=iport; t=1360871388; x=1362080988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u2l8FM6MSDcRx+4uRvPk3r+uW6t85rJO8cAxjamu758=; b=iHlWSi6FX3Fj1Fxzm8jTjIJDle4qbiC7SK1VN2XhLIsGsr8V480CO0Lq 4CLMxhHUfH1daqEsV/frK7rPCmvW2oBJol1uGAwZwNo0beUnSWS2NcgdW 4SbZVkPEkyrIy4KDlPUPYhtjdkmSiGqeuPhs6v9CYqOoxyUW9t9Iytoa6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFANI+HVGtJV2c/2dsb2JhbABEhgK6ZBZzgh8BAQEDAQEBATcPJQsFCwIBCCIUECcLJQIEAQ0FCAGIAwYMvTyRI2EDpneDB4In X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; d="scan'208";a="177020255" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 14 Feb 2013 19:49:47 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1EJnlGv011547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Feb 2013 19:49:47 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 13:49:47 -0600 From: "Fred Baker (fred)" To: John Brzozowski , joel jaeggli Thread-Topic: [v6ops] Management Changes Thread-Index: AQHOCuxx823vIIwmI0iBeK4u/hy41A== Date: Thu, 14 Feb 2013 19:49:46 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B78F3BC@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.150.52] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] Management Changes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2013 19:49:49 -0000 Congratulations and welcome to Joel and John. Ron, thanks for your guidance and help over the past several years.=20 On Feb 14, 2013, at 11:37 AM, Ronald Bonica wrote: > Folks, >=20 > I would like to congratulate Joel Jaeggli on his new role as OPS Area Dir= ector and announce that Joel will be stepping down as V6OPS chair. Please j= oin me in welcoming John Brosowski who, along with Fred Baker, will co-chai= r V6OPS. >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From warren@kumari.net Thu Feb 14 11:52: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 B65D821F84FB for ; Thu, 14 Feb 2013 11:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuXe+iXm1e-i for ; Thu, 14 Feb 2013 11:52:01 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A200421F8419 for ; Thu, 14 Feb 2013 11:51:58 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 6A8491B40402; Thu, 14 Feb 2013 14:51:56 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Thu, 14 Feb 2013 14:51:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations Subject: Re: [v6ops] Management Changes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2013 19:52:02 -0000 On Feb 14, 2013, at 2:37 PM, Ronald Bonica wrote: > Folks, >=20 > I would like to congratulate Joel Jaeggli on his new role as OPS Area = Director and announce that Joel will be stepping down as V6OPS chair. = Please join me in welcoming John Brosowski who, along with Fred Baker, = will co-chair V6OPS. Hang on a tick=85=20 This makes it sounds like John is starting as v6ops chair now, but Joel = only starts as new Ops AD at the new meeting, right? So, what exactly will Joel be doing for the next many weeks? Twiddling = his thumbs? What are we paying him for again?! Seriously though congratulations John=85=20 W >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From alejandroacostaalamo@gmail.com Thu Feb 14 13:19: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 A7F1E21F888A; Thu, 14 Feb 2013 13:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.138 X-Spam-Level: * X-Spam-Status: No, score=1.138 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, MIME_BASE64_TEXT=1.753, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb0suLMbWOJ6; Thu, 14 Feb 2013 13:19:12 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2744F21F8881; Thu, 14 Feb 2013 13:19:11 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id c12so3875364ieb.6 for ; Thu, 14 Feb 2013 13:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-rim-org-msg-ref-id:message-id :content-transfer-encoding:reply-to:x-priority:sensitivity :importance:subject:to:cc:from:date:content-type:mime-version; bh=GCoxx86OGd0zDAVn6ZC50PXRpTB5xWOG22+2Kn3T1zA=; b=DrN97NkrMTwgDBRyuA9ML7pVqGe/dh2JU41quI7PVXDtFu8gbFEQf4ueB0vFEh//8u uXTH3IdhN3Fpjamz39aSeo3Xx6pxUUpemjzhNssqPh/g91zs9zk6XtGiLkZblMcwwGEz LGv/vO0wiyMOqmoSIrkWaUvQ2ZukDwUGRuIuI89H8HQh8YsKrrA89VqPhF6tChS8WBza gybTd0TSKWyEpc7HDSLMBw5/zUqULUBC2m0j4NtsPpl8pb6+dj5Q7aYOVRMs+HXtU3i9 dSrQK1rWJGrxgOIXxMl/5J8NCjseydB6rIDDYqFEteFDQyi+KzDI6wPlhyHDYzrF1Off J9JQ== X-Received: by 10.50.150.167 with SMTP id uj7mr946787igb.1.1360876750736; Thu, 14 Feb 2013 13:19:10 -0800 (PST) Received: from 172.29.196.186 (bda-74-82-80-88.bis6.us.blackberry.com. [74.82.80.88]) by mx.google.com with ESMTPS id as6sm1131956igc.8.2013.02.14.13.19.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Feb 2013 13:19:10 -0800 (PST) X-rim-org-msg-ref-id: 1112848294 Message-ID: <1112848294-1360876745-cardhu_decombobulator_blackberry.rim.net-1471505904-@b14.c3.bise6.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal To: "Diego R. Lopez" , v6ops-bounces@ietf.org, "Roque Gagliano (rogaglia)" From: alejandroacostaalamo@gmail.com Date: Thu, 14 Feb 2013 21:19:03 +0000 Content-Type: text/plain MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt 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: Thu, 14 Feb 2013 21:19:12 -0000 SGkgQWxsLAogICBJIGhhdmUgZm9sbG93ZWQgdGhlIGNoYW5nZXMgb2YgdGhpcyBJLUQgYW5kIEkg cmVhbGx5IGxpa2UgdGhpcyB2ZXJzaW9uLiBJTUhPIEkgdGhpbmsgaXQgY2FuIGhlbHAgdGhlIElQ djYgYWRvcHRpb24uCgpBbGVqYW5kcm8sCgoKLS0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tLQpE ZTogRGllZ28gUi4gTG9wZXoKUmVtaXRlbnRlOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnClBhcmE6 IFJvcXVlIEdhZ2xpYW5vIChyb2dhZ2xpYSkKQ0M6IDx2Nm9wc0BpZXRmLm9yZz4KQXN1bnRvOiBS ZTogW3Y2b3BzXSBOZXcgVmVyc2lvbglOb3RpZmljYXRpb24JZm9yCWRyYWZ0LWxvcGV6LXY2b3Bz LWRjLWlwdjYtMDQudHh0CkVudmlhZG86IDcgZmViLCAyMDEzIDA1OjQ3CgpIaSBSb3F1ZSwKCllv dSBhcmUgdG90YWxseSByaWdodC4gSSB0aGluayBpdCBpcyBteSBmYXVsdCBmcm9tIHRoZSBvcmln aW5hbCB2ZXJzaW9uLCBhbmQgaGFzIGJlZW4gcHJvcGFnYXRpbmcgdGhyb3VnaCB0aGUgc3VjY2Vz c2l2ZSBvbmVzLgoKQmUgZ29vZGUsCgpPbiA2IEZlYiAyMDEzLCBhdCAyMzoyNyAsIFJvcXVlIEdh Z2xpYW5vIChyb2dhZ2xpYSkgd3JvdGU6Cgo+IEhpIEFydHVybywKPgo+IFRoYW5rcyBmb3IgdGhl IHVwZGF0ZS4KPgo+IFdpdGhvdXQgcmVhZGluZyB0aGUgZG9jdW1lbnQgaW4gZGV0YWlsLCBJIHdh cyB3b25kZXJpbmcgd2h5IGRvIHlvdSB0aGluayBpdCBzaG91bGQgYmUgcHVibGlzaGVkIGFzICJT dGFuZGFyZHMgVHJhY2siLiBUaGlzIFdHIHB1Ymxpc2hlZCBzaW1pbGFyIGRvY3VtZW50cyAoc3Vj aCBhcyBSRkMgNTk2MykgYXMgSW5mb3JtYXRpb25hbC4KPgo+IFJlZ2FyZHMsCj4gUm9xdWUKPgo+ Cj4gT24gRmViIDYsIDIwMTMsIGF0IDE6NDMgQU0sIEFydHVybyBTZXJ2aW4gPGFzZXJ2aW5AbGFj bmljLm5ldD4gd3JvdGU6Cj4KPj4gSGksCj4+Cj4+ICAgICAgV2UgaGF2ZSBzdWJtaXR0ZWQgYSBu ZXcgdmVyc2lvbiBvZiBkcmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2LTA0LiBTb21lCj4+IG9mIHRo ZSBjaGFuZ2VzIHdlIG1hZGU6Cj4+Cj4+IC0gV2UgZXhwYW5kZWQgdGhlIHNlY3VyaXR5IHNlY3Rp b24gYXMgc3VnZ2VzdGVkIGluIHRoZSBsaXN0LiBXZSBpbmNsdWRlZAo+PiB0aGUgYXR0YWNrcyBh bmQgc2VjdXJpdHkgaXNzdWVzIHRoYXQgd2UgY29uc2lkZXJlZCBtb3JlIGltcG9ydGFudCBpbiBE Qwo+PiBpbmZyYXN0cnVjdHVyZS4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSB3YW50ZWQgdG8g c2VlIG1vcmUsIG9yIGlmIHNvbWUKPj4gbmVlZCB0byBiZSBleHBhbmRlZC4KPj4gLSBXZSBhZGRl ZCBhIG5ldyBzZWN0aW9uICJPdGhlciBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyIgYW5kIHdl Cj4+IGluY2x1ZGVkIHRvcGljcyBzdWNoIGFzIEFkZHJlc3NpbmcsIENvc3QgYW5kIE1vbml0b3Jp bmcvTWFuYWdlbWVudC4gSWYKPj4gaXQgd2FudCB0byBpbmNsdWRlIG1vcmUgdG9waWNzIGxldCB1 cyBrbm93Lgo+PiAtIFdlIHJlLW9yZ2FuaXplZCBzb21lIHRleHQgaW4gdGhlIGludHJvZHVjdGlv biB0byBiZSBub3cgdW5kZXIgYQo+PiByZW5hbWVkIHNlY3Rpb24gIkFyY2hpdGVjdHVyZSBhbmQg VHJhbnNpdGlvbiBTdGFnZXMiCj4+IC0gV2UgYWRkZWQgdGV4dCBzdWdnZXN0aW5nIGhvdyB0byBz dGFydCBtb3ZpbmcgYXBwbGljYXRpb25zIHRvIElQdjYKPj4gd2l0aGluIHRoZSBEQwo+PiAtIFdl IGFkZGVkIHNvbWUgdGV4dCB0byBleHBsYWluaW5nIHRoZSBtb3RpdmF0aW9ucyBmcm9tIG1vdmlu ZyBmcm9tCj4+IER1YWwtc3RhY2sgdG8gSVB2Ni1vbmx5IGFzIHN1Z2dlc3RlZCBpbiB0aGUgbGlz dAo+PiAtIFdlIGNoYW5nZWQgc29tZSB0ZXh0IHRvIGltcHJvdmUgcmVhZGluZyBhcyBzdWdnZXN0 ZWQgYnkgc29tZSBwZW9wbGUKPj4gb2ZmLWxpc3QKPj4gLSBXZSBmaXhlZCBzb21lIHR5cG9zCj4+ IC0gV2UgdXBkYXRlZCBzb21lIHJlZmVyZW5jZXMKPj4gLSBBbmQgd2UgYWRkZWQgYSBuZXcgYXV0 aG9yCj4+Cj4+ICAgICAgQW5kIEkgdGhpbmsgdGhhdCBpcyBhbGwuCj4+Cj4+ICAgICAgUGxlYXNl IGxldCB1cyBrbm93IHlvdXIgY29tbWVudHMuCj4+Cj4+IEJlc3QgcmVnYXJkcwo+PiBhcwo+Pgo+ Pgo+PiAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tCj4+IFN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ni0wNC50eHQK Pj4gRGF0ZTogVHVlLCAwNSBGZWIgMjAxMyAxMzo1Nzo0MyAtMDgwMAo+PiBGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcKPj4gVG86IGFzZXJ2aW5AbGFjbmljLm5ldAo+PiBDQzogdGluYS50 c291LnpvdXRpbmdAaHVhd2VpLmNvbSwgZGllZ29AdGlkLmVzLCBjYXRoeS56aG91QGh1YXdlaS5j b20sCj4+IDE4OTE4NTg4ODk3QDE4OS5jbgo+Pgo+Pgo+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ni0wNC50eHQKPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBBcnR1cm8gU2VydmluIGFuZCBwb3N0ZWQgdG8gdGhlCj4+IElFVEYgcmVw b3NpdG9yeS4KPj4KPj4gRmlsZW5hbWU6ICAgICBkcmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2Cj4+ IFJldmlzaW9uOiAgICAgMDQKPj4gVGl0bGU6ICAgICAgICAgICAgICAgIElQdjYgT3BlcmF0aW9u YWwgR3VpZGVsaW5lcyBmb3IgRGF0YWNlbnRlcnMKPj4gQ3JlYXRpb24gZGF0ZTogICAgICAgIDIw MTMtMDItMDUKPj4gV0cgSUQ6ICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbgo+ PiBOdW1iZXIgb2YgcGFnZXM6IDIwCj4+IFVSTDoKPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ni0wNC50eHQKPj4gU3RhdHVzOiAg ICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvcGV6LXY2b3Bz LWRjLWlwdjYKPj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2LTA0Cj4+IERpZmY6Cj4+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxvcGV6LXY2b3BzLWRjLWlwdjYtMDQKPj4KPj4gQWJzdHJh Y3Q6Cj4+ICBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIHByb3ZpZGUgb3BlcmF0aW9uYWwg Z3VpZGVsaW5lcyBmb3IKPj4gIGRhdGFjZW50ZXIgb3BlcmF0b3JzIHBsYW5uaW5nIHRvIGRlcGxv eSBJUHY2IGluIHRoZWlyCj4+ICBpbmZyYXN0cnVjdHVyZXMuICBJdCBhaW1zIHRvIG9mZmVyIGEg cmVmZXJlbmNlIGZyYW1ld29yayBmb3IKPj4gIGV2YWx1YXRpbmcgZGlmZmVyZW50IHByb2R1Y3Rz IGFuZCBhcmNoaXRlY3R1cmVzLCBhbmQgdGhlcmVmb3JlIGl0IGlzCj4+ICBhbHNvIGFkZHJlc3Nl ZCB0byBtYW51ZmFjdHVyZXJzIGFuZCBzb2x1dGlvbiBwcm92aWRlcnMsIHNvIHRoZXkgY2FuCj4+ ICB1c2UgaXQgdG8gZ2F1Z2UgdGhlaXIgc29sdXRpb25zLiAgV2UgYmVsaWV2ZSB0aGlzIHdpbGwg dHJhbnNsYXRlIGluIGEKPj4gIHNtb290aGVyIGFuZCBmYXN0ZXIgSVB2NiB0cmFuc2l0aW9uIGZv ciBkYXRhY2VudGVycyBvZiB0aGVzZQo+PiAgaW5mcmFzdHVjdHVyZXMuCj4+Cj4+ICBUaGUgZG9j dW1lbnQgZm9jdXNlcyBvbiB0aGUgREMgaW5mcmFzdHJ1Y3R1cmUgaXRzZWxmLCBpdHMgb3BlcmF0 aW9uLAo+PiAgYW5kIHRoZSBhc3BlY3RzIHJlbGF0ZWQgdG8gREMgaW50ZXJjb25uZWN0aW9uIHRo cm91Z2ggSVB2Ni4gIEl0IGRvZXMKPj4gIG5vdCBjb25zaWRlciB0aGUgcGFydGljdWxhciBtZWNo YW5pc21zIGZvciBtYWtpbmcgSW50ZXJuZXQgc2VydmljZXMKPj4gIHByb3ZpZGVkIGJ5IGFwcGxp Y2F0aW9ucyBob3N0ZWQgaW4gdGhlIERDIGF2YWlsYWJsZSB0aHJvdWdoIElQdjYKPj4gIGJleW9u ZCB0aGUgc3BlY2lmaWMgYXNwZWN0cyByZWxhdGVkIHRvIGhvdyB0aGVpciBkZXBsb3ltZW50IG9u IHRoZSBEQwo+PiAgaW5mcmFzdHJ1Y3R1cmUuCj4+Cj4+ICBBcGFydCBmcm9tIGZhY2lsaXRhdGlu ZyB0aGUgdHJhbnNpdGlvbiB0byBJUHY2LCB0aGUgbWVjaGFuaXNtcwo+PiAgb3V0bGluZWQgaGVy ZSBhcmUgaW50ZW5kZWQgdG8gbWFrZSB0aGlzIHRyYW5zaXRpb24gYXMgdHJhbnNwYXJlbnQgYXMK Pj4gIHBvc3NpYmxlIChpZiBub3QgY29tcGxldGVseSB0cmFuc3BhcmVudCkgdG8gYXBwbGljYXRp b25zIGFuZCBzZXJ2aWNlcwo+PiAgcnVubmluZyBvbiB0aGUgREMgaW5mcmFzdHJ1Y3R1cmUsIGFz IHdlbGwgYXMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YKPj4gIElQdjYgZmVhdHVyZXMgdG8gc2ltcGxp ZnkgREMgb3BlcmF0aW9ucywgaW50ZXJuYWxseSBhbmQgYWNyb3NzIHRoZQo+PiAgSW4KDQpFc3Rl IG1lbnNhamUgaGEgc2lkbyBlbnZpYWRvIGdyYWNpYXMgYWwgc2VydmljaW8gQmxhY2tCZXJyeSBk ZSBNb3ZpbG5ldA== From iljitsch@muada.com Fri Feb 15 00:44:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2721F88E6 for ; Fri, 15 Feb 2013 00:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ4iCuAD5tuM for ; Fri, 15 Feb 2013 00:44:10 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 0580B21F866F for ; Fri, 15 Feb 2013 00:44:09 -0800 (PST) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r1F8dYgW099751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 Feb 2013 09:39:35 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Feb 2013 09:44:03 +0100 References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> To: IPv6 Ops WG Message-Id: <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [v6ops] draft-steffann-tunnels-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: Fri, 15 Feb 2013 08:44:11 -0000 Hi all, Three of us were asked by the Dutch academic network Surfnet to write an = overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider = community, we did so in the form of a draft, that we intend to submit to = the RFC Editor as an independent submission. However, we would very much appreciate reviews and comments from within = the IETF. These are the mechanisms we discuss: 3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 6 3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 7 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 8 3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 9 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 9 3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 10 3.7. Intra-site Automatic Tunnel Addressing (ISATAP) . . . . . 11 3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 12 3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 13 3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 14 3.11. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 15 3.12. The Locator/ID Separation Protocol (LISP) . . . . . . . . 16 4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Tunnel Information and Control protocol (TIC) . . . . . . 17 4.2. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 18 4.3. Dual-Stack Lite (Softwire) . . . . . . . . . . . . . . . . 19 Thanks! Iljitsch Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-steffann-tunnels-00.txt > Date: 15 februari 2013 9:34:07 CET > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : A comparison of IPv6 tunneling mechanisms > Author(s) : S.J.M. Steffann > Iljitsch van Beijnum > Rick van Rein > Filename : draft-steffann-tunnels-00.txt > Pages : 37 > Date : 2013-02-15 >=20 > Abstract: > This document provides an overview of various ways to to tunnel IPv6 > packets over IPv4 networks. It covers mechanisms in contemporary > use, touches on several mechanisms that are now only of historic > interest, and discusses some newer tunneling mechanisms that are not > (yet) widely used at the time of publication. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-steffann-tunnels >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-steffann-tunnels-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From iljitsch@muada.com Fri Feb 15 00:48: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 524D621F866F for ; Fri, 15 Feb 2013 00:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06nlYSo4lxh4 for ; Fri, 15 Feb 2013 00:48:24 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 759BB21F8984 for ; Fri, 15 Feb 2013 00:48:24 -0800 (PST) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r1F8hpu5099783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 Feb 2013 09:43:51 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> Date: Fri, 15 Feb 2013 09:48:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B4F610F-B75E-46AC-A534-97C097C5CBB9@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1499) Subject: Re: [v6ops] draft-steffann-tunnels-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: Fri, 15 Feb 2013 08:48:25 -0000 On 15 feb 2013, at 9:44, Iljitsch van Beijnum = wrote: > Three of us were asked by the Dutch academic network Surfnet to write = an overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider = community, we did so in the form of a draft, that we intend to submit to = the RFC Editor as an independent submission. Lest I forget: please note that we're 98% done with the document, there = are still a few things we need to look at. But we wanted to get the = document submitted well before Monday's cutoff.= From nfiumarelli@lacnic.net Fri Feb 15 04:53: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 87EB021F85CC for ; Fri, 15 Feb 2013 04:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd3dEeGS3PXR for ; Fri, 15 Feb 2013 04:53:08 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB021F85CB for ; Fri, 15 Feb 2013 04:53:08 -0800 (PST) Received: from [IPv6:2001:13c7:7001:2128:a986:9bd:e62a:4829] (unknown [IPv6:2001:13c7:7001:2128:a986:9bd:e62a:4829]) by mail.lacnic.net.uy (Postfix) with ESMTP id 42207308454 for ; Fri, 15 Feb 2013 10:52:59 -0200 (UYST) Message-ID: <511E2FB0.4000203@lacnic.net> Date: Fri, 15 Feb 2013 10:53:04 -0200 From: =?ISO-8859-1?Q?Nicol=E1s_Fiumarelli_-_Ingenieria_-_LACNIC?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <511E2E3F.80803@lacnic.net> In-Reply-To: <511E2E3F.80803@lacnic.net> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <511E2E3F.80803@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: nfiumarelli@lacnic.net Subject: [v6ops] Fwd: Re: New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 12:53:08 -0000 Hola, Me parecio muy interesante el draft, sobre todo las consideraciones importantes de seguridad en V6 DC relacionados con direccionamiento y el enfoque de los costos, sin duda que facilita la transicion. Espero que proceda, Nicolas Fiumarelli - Ingeniería - LACNI From leo.baltus@tech.omroep.nl Fri Feb 15 05:18: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 32F1A21F8628 for ; Fri, 15 Feb 2013 05:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.904 X-Spam-Level: X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSGmhjY2zAm3 for ; Fri, 15 Feb 2013 05:18:58 -0800 (PST) Received: from out1a.mail.omroep.nl (out1a.mail.omroep.nl [145.58.30.184]) by ietfa.amsl.com (Postfix) with ESMTP id CC3BB21F8626 for ; Fri, 15 Feb 2013 05:18:57 -0800 (PST) Received: from localhost (ou1aclean [10.10.30.156]) by out1a.mail.omroep.nl (Postfix MTA - NPO ICT) with ESMTP id 3CB298004B3; Fri, 15 Feb 2013 14:18:49 +0100 (CET) X-Virus-Scanned: NPO ICT Received: from tech1a.mail.omroep.nl (tech1a.mail.omroep.nl [IPv6:2a02:458:101:71::6c]) by out1a.mail.omroep.nl (Postfix MTA - NPO ICT) with ESMTP id 2488B8000B4; Fri, 15 Feb 2013 14:18:49 +0100 (CET) Received: from localhost (unknown [IPv6:2a02:458:101:13:21f:29ff:fe39:5d45]) by tech1a.mail.omroep.nl (Postfix MTA - NPO ICT) with ESMTPSA id 0A30A2015AC7; Fri, 15 Feb 2013 14:18:49 +0100 (CET) Date: Fri, 15 Feb 2013 14:18:48 +0100 From: Leo Baltus To: Erik Nordmark Message-ID: <20130215131848.GD15101@omroep.nl> References: <6EBC0E51-51B2-4749-AD05-BCF4CAC8213B@steffann.nl> <511BE070.3000607@acm.org> <511CA5A7.3070500@gmail.com> <7E9CF6B3-C8C6-45A6-8BBA-B2C3CBAAE6F6@steffann.nl> <511D939D.5050608@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511D939D.5050608@acm.org> X-Disclaimer: Geregistreerd bij Kamer van Koophandel Gooi & Eemland onder nr 32043579 Registered at the Chamber of Commerce User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Source address selection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2013 13:18:59 -0000 Op 14/02/2013 om 17:47:09 -0800, schreef Erik Nordmark: > On 2/14/13 4:01 AM, Sander Steffann wrote: > >>>I'm surprised that you want to use the common iron address for outbound > >>>connections. Where I've though about this it seems more natural for > >>>service A to use the A address as a source address for outbound > >>>connections. > >> > >>That was my thought too. Sander did write > >>"- If the address is load balanced then initiating outbound connections from that address will break as return traffic might be > >>load balanced to one of the other boxes" > >>but that suggests a strange and stateless load balancer, that is attempting > >>to balance return packets for sessions initiated from behind the load balancer, > >>which is broken anyway. It's only incoming sessions for which the LB can > >>pick a target. > > > >It's direct routing, where the outbound traffic does not pass > >through the load balancer at all. It scales much better than pushing > >all traffic through the load balancer, especially when the outbound > >traffic is 99% of the total (content, streaming etc). The downside > >is that multiple boxes have the same IP address configured and the > >load balancer balances between them using layer-2. Which is why the > >boxes must not use the load balanced addresses as source address for > >their own connections, which is one of the reasons why I asked the > >question :-) > > Are you doing some live migration of the applications? > Or just stopping one and restarting it on a different box? > > If you want outbound traffic to work well I'd assert you'd want one > IP address for every instance of your application. Thus if service A > is load balanced to 3 servers, and service B to 4, you'd have 7 IP > addresses that are unique per service instance. (In addition you'd > have 2 for the services - A and B, plus one for each physical > server.) > > I think you can do that using LXC (or your favorite server > virtualization technology) by assigning the service (e.g., B) > address to the loopback interface in the container/VM, and the > instance address to eth0 in the container/VM. > Let me jump in here and try to explain what we are doing. This is a lengthy post sorry for that. We are Dutch Public Braodcasting, we host all sort of (web)applications which more or less are are associated with national tv and radio shows. We also host application during events like Tour de France, Olympics, World Cup Soccer etc. At very unpredictable moments we can serve >30.000hits/sec on webtraffic streaming content exceeds 100Gb/sec. In order to accommodate this, each application, be that php, java, ruby-on-rails etc, is hosted behind a loadbalancer, a minimum of 4 apache reverse front-proxies and a minimum of 4 backends running said php's java's etc. Not every application needs to take the full load constantly so there are a lots of vhosts in each apache instance. The hosts are running a fairly run of the mill linux, but all instances are started by our own scripts and each instance bring up its own ipadress. We have several groups of hosts we call clusters (not HA) a cluster can consist of some >30 servers. Each OS is configured identical apart from its hostname and its IPv4adress we call this its iron-address. Storage is either nfs-based or iscsi, in the latter case if a service requires iscsi it mounts its own storage on startup. On such a cluster we run about 400 apache instances and some 300 other instances like tomcat, mysql, memcached, postfix etc. serving some 700+ applications. As each host is identical the configuration of all instances is on every host and we use rsync to keep it that way. The information of what instance is running where is kept on nfs-storage. The nice thing of this setup is that we can take an instance of, say, php away from busy hardware en start it elsewhere with minimal impact. Also we can easily deploy extra instance when needed. Needless to say that we often need more capacity than a single host can offer so virtualization is not an option. As Sander has pointed out there is an issue with source address selection in IPv6 because it defaults to using the most recently added address. In our case, were are not using SLAAC, this is always an address of some service that is started last. That becomes an issue if we move a service to some other hardware. Long running tcp connections break and also all traffic initiated from this host appears to come from another IPv6 address, so that a change of service A has impact for service B,C,D. This is not acceptable. Of course there are applications like postfix which can bind() we use that whenever possible. But things like ruby-on-rails, java, php or even mod_balancer need to have this information from the instance running it, as far as I know there is no facility to globally bind() on every outgoing connection, and there will always be some application which do not so we have to have a plan. The only way we have found is to bring up each service address with preferred_lft 0 so it will not be chosen, the only one left is its iron- address which is exactly what we want and we have been using this for the last 2 years. So far so good. The thing that bothers me however is that this use of 'preferred_lft 0' is not very known and accepted and in linux at least if you list ip addresses it shows up 'deprecated': $ ip a inet6 2a02:458:101:28:100:28:0:72/128 scope global deprecated This is what Sander means with 'feels like a hack'. I can live with the fact that this may just be a wording issue and if we could developers to persuade to call it 'preferred_lft 0' that may take some of this feeling away. On the other side I would also feel a bit better if the use 'preferred_lft 0' would be documented better, indeed seeing pages like http://biplane.com.au/blog/?p=30 (thanks for the link BTW) do help but this is just a page. I would feel much more comfortable if the use of this option would be part of some BCP or so, so I could refer to it to others, like the developers of keepalived which I have sent a patch but never got accepted http://marc.info/?l=keepalived-devel&m=130200733315039 Keepalived keeps track of members of an IPVS loadbalanced setup, when using direct routing you either must bind() or use preferred_lft 0 to avoid the loadbalanced address to be used as source address. Buts this is just an example. Then there is another issue. If we set-up a ipv4 and ipv6-with-preferred_lft-0 and on the same host an connection is initiated to a 'name' which resolves to both addresses, it seems on linux that it is falling back to IPv4. We think this is a bug, but in order to discuss this isssue we need to have a firm reference to the use of preferred_lft 0 in order to make any chance of have it accepted as a bug. I hope this explains a little bit more, please shoot :) -- Leo Baltus, internetbeheerder /\ NPO ICT Internet Services /NPO/\ Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/ servicedesk@omroep.nl, 035-6773555 \/ From nfiumarelli@lacnic.net Fri Feb 15 05:25: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 97EE621F88B6 for ; Fri, 15 Feb 2013 05:25:58 -0800 (PST) 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=-1.384, BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkKAvgEXlwEj for ; Fri, 15 Feb 2013 05:25:58 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9002621F8795 for ; Fri, 15 Feb 2013 05:25:56 -0800 (PST) Received: from [IPv6:2001:13c7:7001:2128:a986:9bd:e62a:4829] (unknown [IPv6:2001:13c7:7001:2128:a986:9bd:e62a:4829]) by mail.lacnic.net.uy (Postfix) with ESMTP id A559D308432 for ; Fri, 15 Feb 2013 11:25:44 -0200 (UYST) Message-ID: <511E375E.8050307@lacnic.net> Date: Fri, 15 Feb 2013 11:25:50 -0200 From: =?UTF-8?B?Tmljb2zDoXMgRml1bWFyZWxsaSAtIEluZ2VuaWVyaWEgLSBMQUNOSUM=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <511E2E3F.80803@lacnic.net> <511E2FB0.4000203@lacnic.net> <57D0F9E8-D8EA-4E09-80DF-D94C0C5FE75B@lacnic.net> In-Reply-To: <57D0F9E8-D8EA-4E09-80DF-D94C0C5FE75B@lacnic.net> X-Enigmail-Version: 1.4.2 Content-Type: multipart/alternative; boundary="------------080002000709050706010400" 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: nfiumarelli@lacnic.net Subject: Re: [v6ops] Fwd: Re: New Version Notification for draft-lopez-v6ops-dc-ipv6-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:25:58 -0000 This is a multi-part message in MIME format. --------------080002000709050706010400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello, sorry for that, here in English: The draft was very interesting, especially the safety considerations related to DC V6 routing and costs approach certainly facilitates the transition. I think it would be good to proceed, regards --- Nicolas Fiumarelli - Engineering - LACNIC El 15/02/13 11:12, Arturo Servin escribió: > In the IETF lists you have to write in English. > > > > :) > > .as > > Sent from my iPad > > On 15 Feb 2013, at 12:53, Nicolás Fiumarelli - Ingenieria - LACNIC wrote: > >> Hola, Me parecio muy interesante el draft, sobre todo las >> consideraciones importantes de seguridad en V6 DC relacionados con >> direccionamiento y el enfoque de los costos, sin duda que facilita la >> transicion. Espero que proceda, Nicolas Fiumarelli - Ingeniería - LACNI >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops -- Embedded Image *Nicolás Fiumarelli* Analista de Software Software Developer Embedded Image *Casa de Internet de Latinoamérica y el Caribe* *Rambla Rep. de México 6125 11400 Montevideo-Uruguay +598 2604 22 22 www.lacnic.net * --------------080002000709050706010400 Content-Type: multipart/related; boundary="------------010001070501000105030102" --------------010001070501000105030102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello, sorry for that, here in English:

The draft was very interesting, especially the safety considerations related to DC V6 routing and costs approach certainly facilitates the transition. I think it would be good to proceed, regards
---

Nicolas Fiumarelli - Engineering - LACNIC

El 15/02/13 11:12, Arturo Servin escribió: 
In the IETF lists you have to write in English.



:)

.as

Sent from my iPad

On 15 Feb 2013, at 12:53, Nicolás Fiumarelli - Ingenieria - LACNIC <nfiumarelli@lacnic.net> wrote:


Hola, Me parecio muy interesante el draft, sobre todo las
consideraciones importantes de seguridad en V6 DC relacionados con
direccionamiento y el enfoque de los costos, sin duda que facilita la
transicion. Espero que proceda, Nicolas Fiumarelli - Ingeniería - LACNI
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--
Embedded Image
Nicolás Fiumarelli
Analista de Software
Software Developer

Embedded Image
Casa de Internet de
Latinoamérica y el Caribe
Rambla Rep. de México 6125
11400 Montevideo-Uruguay
+598 2604 22 22 www.lacnic.net
--------------010001070501000105030102 Content-Type: image/png; name="bdibcgic.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bdibcgic.png" iVBORw0KGgoAAAANSUhEUgAAAIgAAABICAYAAAAtUr3mAAAACXBIWXMAAAsTAAALEwEAmpwY AAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUI IFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuj a9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMB APh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCd mCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgw ABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88Suu EOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHg g/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgug dfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7i JIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKS KcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8/ /UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBC CmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHa iAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyG vEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPE bDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKgg HCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmx pFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgX aPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1Qw NzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnU lqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1 gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIp G6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acK pxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsM zhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZL TepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnu trxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFn Yhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPj thPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/u Nu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh 7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7 +Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGL w34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8Yu ZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhO OJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCep kLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0d WOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWF fevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebe LZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ2 7tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHt xwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTra dox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLT k2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86 X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/Xf Ft1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9D BY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl /erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz /GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACwdJ REFUeNrsXUtsG8cZ/oarty17RcM1JFswDUeFUSYwg6IGWqA1haCRTw15qNFLYKnqoU2BRsq1 B1GHXPU41O0hqphb4RxI92S3B6/SogVsNGYQsHAgG17DsFRXlrSRZEsiTU4PO0stV7PcB2mX pOYDCJCzs7Pz+OZ/zeyQQKApsRYeiAAIsZ9aMLuo+CmHiK5sOmLIAG4BiFguqQDiwexixkt5 AdGlTYcUhxxg0iQlJMjBlh4hAA87fnUBbfHvAADoVg47f7iN/F/uG9kGvagbIUGaCyHpbLBE DgAgh9vQ8csL5jxRoWIOMMjhNqc0VRDk4CJDt3L7EotPt8ryCIIcUASzi1rhwdpMLvXvUhrd ymHn97eNn4pXL0YYqQ2G3rlUCHvxDSyPxhWOsZoA8CEAmSVpAJIAJoPZRU0QpPlIIQOYADBs GnQzFACTPLJUbdOI7q97ckSgB75kF9mTy6PxkVo+X9gg9Y+US3IAwHDvXComCHJwpMew2d5w iela1qFFDENd4z3zj+7dbfz6n39FLPsvdO9uAwA22zuRDn8Xv/v+j7HZ3gkAod65VGR5NJ4R BGl+lEmPj29ewzv3s7CS5v0v/o6+jXX85idXjGRZSJCDgYjx5eTGeokcUl8BHbEXaDmbR2FJ Qu7zDrxzJ4uTG+t4cqTHuK8mHo2wQeobpZhF38Z6KbFrZBMtZ/MlsnT+7DkCwaI5T6ZWFRAE qW9wBzoQLO5P6ym+kgoIgjQIQTbbO0qJdHt/+IpuEyOPVsuAmSBIfWPW+HLveB/uHe8DAOxc 7yrLlLvTjmy+37ierGUFRCS1zsFiIfMAcG5lCR/fuIZzK0sIBIsI9BRBtwmy+X789tJl3Dve lwEwuDwa1wRBDh5Jpg339dzKErp3d0qqh0mONIARHjnWwgNROxXmtHgnCNI4JJEBxFhs5CJL VgF8CSC9PBpXTYSQoS/sXQF/f6rVzrkOIBnMLqqCIE2OtfDAGPSVX5l3XeorgHTSMuO2sCQZ PyeD2cWEIEjzkmOeSY5yKdBJ0f6jHbT9cKeMHGaS5P7Wgd3PO0C3iQL99QhNEKS5yDENYIxH jkMfbEDqK5SlZ/P92Cjq3tCRwAuEWx+jsCTh+dUjoNskHcwuxgGAUEoj2L8CmCGEjItubxhy RKHvGdmHrpEttL6ZKyPGR+s/RzbfX5Yv3PoYUz1/xLe/fooX84fBpEg6wHRV1PKJiG5vKEzw EgPBYhk5AHDJYSZO65s5Q9pMAyJQ1gzSIwSbd12s5Mjm+7nksF5vfSsHAKG18EBEEKTxEbON YVgMUsPmqISNYhfI3rpOTBCk8XHe7oJ09qWvAk2LgRcFQRofIbsLhSdS2e/+llXHwvpbVlFc 26OFIEgzY6c8inFKeoahjru22Yc67uKU9Ax0fY8WVe8oo5TKzOuJAjhtYbQK4BEAhRCi+Cjb KFfGXnjZwAL0DTUKISRToYyo1YgjhCRM5ceYmJbZZQ16+DrDytbclgtAJYQkHdpk3HfU4i0a z1XZc9Vqxyb/VRva390uS5vumcfU5iquvfhBWRzkctc/8FH3n0v3lfqKVdjqQyuEkEEXgzdR yUiydh6AWULIjAtiRJmb5dbdzgAY55GQUprguIFxVn7IoVyN1TnhslzbfqOUDrP8IZdtSrM2 qQ5ezC1UeGP/0Ad7u8/c4OWDVjy/2l1qT8Cn1EgAuOuBHIaunKaUzjuUPQz+CTmVEAFwi93r BimXAyUDmHCqs4v+moe+ZB/ycFsMwF02EZ0mnr2WSXdxNxhx67lNsJMu93QCPhobswvMuMQw pXSsguSoZjDmWRm1xrDfctlkGvb5XJkRX66Q58tKBRSWJGxNHcXLB62OkmNr6qh54Q4AFvzY IB9WYHLGVOHTbGbzZsAEAJ6qmXeYKapFasg29fNq7yimAYlUaLfikRyyw2TKwLQx2UZVyIxg Mw51t0VxLYDnV7sh9RXQ8kZ+32ruy/utVmKU6ueHILxGJAkhIxVsFeu7pTKlNGq2GVi+kE0n xnm6mEmiaRf1s7Mvxq1GJRtUnorzI0HsJEeSPVvjPHuac99FO4IEs4uZtfCA6kZ9FZYkOyJw +8dYi4HP2WY2zGxfGGYeRtrGbnAaAA3AoJ2hxgxelTPj3GCc53GwQYvbzGSvuMjrP0LICM87 YmmTPp49+QrU6qzfOEiczQCNkcXNqu8jF43mdULazs10a6TZzY5K7qgdIV0YjG4G9tNKN/hx b4PZxSRq9KKUIbWNjUOeVQwbsBEAI0YcgVLqtLUt5HO2PXLJdLP0mXHTAVUYjdWqYzcEmEH5 3o5ZlxPXq/dnp3rjVQXKmCczDe9vnvuprBNh05TSM6wuWqWgWaOAEDJOKf2UEVJ1I1WC2UVt LTwwyAz9mM9HKzDtJvNFEBZrmH9NfZVx2aGqT1Xz/4DbNnkmOhvYONtANOHBsM4AmGWqqgwt Hskho8bnTwjUHuygXMW0VyQE/nKCCv1gO9vJ5VWCDNvo4Qz0rfOV7As/bmKkxsZXPeC1tYkN fLKaMrwS5KKNpxF3kDwJnwSRG5wMWqO3oaUGA3a9RnVZ4JDodIMTJMNp06s27I2D72IctbIA y0tWTgi8ppl7xafHEnNYhwCl9CG1oI4IonrtC0qpTPfjlktiyL1zqRT0hVRjpT3KPobn+bB3 LjXthSA8azlCKR3jDI7mo8FuVzHTNkSdp5SGbMoe45St1RFBFnixEUppgkf8GjgBt1y6uGOM SM4qhhCiUUoVjiichr48b15nWeBUIEopfcgG+BtT+lHsvUvqylW1qUeMSZKMZfAjsD9Utl6Q humlaxMmoG8jsNbVzk677kJ6JOAtSBbrnUsNL4/Gk25skMkKlQtxGszLM1aDDq1UD7eNn60X drDJNwv7FV03hrvm0hO5AgBHWgv4xek1vHtiE+Fu/QSAm//txmdPZNx82m295z2nsgOsIQr0 8LnjLHeTr4oOVaosf9LP1sZXTJJEFa6mBmDEaT2KvfkfAoBrFx5h/I2VEjkAYOhbm/jk7ccY OrEJjnR2Z6Syxau3nUQ0yzfiQdcrAAY9dGiS5Vc9dKQKfUtAoh5dGaaixz22SYG+kp12GVvB EJMaZFkB+WpK/3z9CbCzAgBInPtPdW4uC+8OMqMwwj6qzSAm2ZpMhBMfUaFH6kobiimlk25t BSYFzpg2LZ/n2DIq9MW8tENYWnHpXfDUXaX7PJXLtibMmDYtn+fYJhlTm1Svgxnu3tHJ8OyL vcTcBsjjG6AD7+NUZ746glhUiWrjWZjzpZ3yWESt15mXQZVHOjKyKT7uS7yicn3d5zpEUNjd f5VJED8Q78U0Adix29o3LyVAat+foe2I3a0ZQZCDg/TNp91Ax3GgJ7yXKrWD9urO0mdPZM/u szhApknA/onq7k9PavLUW0u6qtlZAQ6dAgBkNztw+fZpbOQls1o643QioiBIc5EkBmD+VGde HjqxiaMthRI5LDEQDfpxmRkhQQ6mJDHWYWSOl5WG/vdlrsIUgiDNTxYjPJCp5QG7AgJCgjQj CjeORc0qRbq0qgqCCKBw41gE/JfSFQBx6dKqL/Ui4iDNQQ4Z+l6QEOdylBHHF8RfkjUHogDk 7T8dQu6OHkkNBIvoGtk0jrSMFm4ck/1IESFBmgOR3J32EjkA/Y3+3ZudZXmEijnAMJ8rVkrb rn54BUGaAwrh/Gcd6SyladKlVUUQ5IBCurSqtH1vN9NiOhc1ECyifah0gJ3vbZjCzW0uT8Z6 +IwGYFa6tJrwW+7/BgD7hEw3jeIB4gAAAABJRU5ErkJggg== --------------010001070501000105030102 Content-Type: image/png; name="fifehbae.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="fifehbae.png" iVBORw0KGgoAAAANSUhEUgAAAIQAAABICAYAAAA3bl1oAAAACXBIWXMAAAsTAAALEwEAmpwY AAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUI IFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuj a9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMB APh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCd mCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgw ABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88Suu EOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHg g/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgug dfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7i JIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKS KcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8/ /UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBC CmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHa iAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyG vEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPE bDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKgg HCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmx pFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgX aPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1Qw NzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnU lqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1 gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIp G6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acK pxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsM zhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZL TepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnu trxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFn Yhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPj thPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/u Nu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh 7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7 +Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGL w34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8Yu ZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhO OJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCep kLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0d WOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWF fevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebe LZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ2 7tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHt xwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTra dox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLT k2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86 X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/Xf Ft1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9D BY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl /erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz /GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAADbJJ REFUeNrsXV1sI9UV/saZ/QmCxXGF1N1ZWKewLTSgddQ/rYrKRLSUl2ptEBKqtNpYqdS3JlZV +uBKiaX6sY3Thz51FUeVeECiceAFqUXxCqSqottMKqyyhJIBOg1LS3YadrshO7H74DPJzez8 +45/io8UsYxnru8997vnnO/cc8cC+vJ/JYZWTAGYBpACkASg0F9BlPKq1/OCpbE4NQQAEKV8 NaJOJ6mzAKCLUl7p4QmQAcgATjFjMuUSTUZVlPJ6m/qy7PCxDmDUCxQCA4RZAOM2jcyJUn7G YVInCUAy85GJyAUroAi9s5b7zWeyvQIM0tcUjT/u87Gy31XaQr9W2AVt1wdRymf9AMKroQIL CkMrzpJCvKQKIGOuDkMrrtusIhZ8w+1YSRxM8qLLOLwkK0r5soulAQCVrIoasG8Nj1tUUcoP uwLC0IppGqCb6KKUH6IvnbexJG6iABijwS6GUVZEEzsF4AIthCpZwooPMCwHsAqe4/QAmHUh mpbpMYt+5+jf615fLEp5we3zmIdlMCVuaMUUoXg84OBTNAg/35NsExhkcl1mn2QAi+QG3WSR AxgAYJ6AAA9rM019NV30OgWMMvM3BWDFZ788LU4swCDi5DPDyCSHSVw3tGLD0IozHCZEDgpI sig8ATtLoEj61N2sy6SbMaBXDFblCQjdRZF+wHTK53d4WY8zHQofJjm3J5PL8qM7AEj7aK/g oduCH0BU/EwUMYBWzOWqx4TDoy8ZGlCBw2RUHRSmusQOUbizNOf2dIrXKpZrZT+UEwBEUcor hlaseqx+HpMQB5ADMO8SaKkuwVDFJ3g9RZTyVUMrZmjVywQQN0qYisjqJH1Osl9RaQyh80ci s/rc8hAlHugVpXyZwJdmTP97xI+j5OdxJl9SBaCwACOmNW1oxWUmcl8CUCIaHFWwW6W23dpf YPqU8tBvyzoUacXoALKGViywneOcqVSoTRVAKaKJN/MjiijlRx2o4jQA3dCKY2Qdp2gxWC1C iujdWIRxSYrad6KyJYYKFzxo+xwX62kxpaoHNfFyLZ6AiFhSNqbYjirG6fowAcQxUCPrEZXE CZTDZDXNfp+imEsh2qmKUr5iaMWsDdswrfgMd0D4kIWQgKi0KQOZI8UqDHd3MsdJsg5xnyCL QkyrqZMrnab+x22sn0r6H0aE+02BAEExwGRAJek0UZELMSElQNAWR2dFp8ke98gzmGOZpkB4 LKp9H8HDJ7MrTCEkx8nnpXwOOBPVrqnPuMItvz8M73RvgVzlcgTdK1HwuhwCSKNRBOKiAwhs TReZrQqxknFKrCQdOlxBxLt7LjmDeQKs4hL3lEQpr9KY3CxJme6LoruXXGi4l2WbBpCN1EL4 NF17CRAKiJKk8HN0faHDFsG6c1uhVchmBZdMKu2xYZVj7gu6qefLerZoeYYIzHGbUgPzuhIK EKSYlYADGiZFsmZ3j/J1iYuoilJ+zIdrTBPNjDPJoFViXRVS/ArHrhYYGtxKEG1S5gM7xYZW vEZjyQXJI7F7GZMhzZZ11Zi7op2SiuX/PV2WKOVVUcqXRCmfISXLBJBpMukr1A6v/IlCNPFU i+085gLweJjAmY0hwpjDNPYzabdFzx2SLH1/kmKIoGl3uyqoJIApUcrnKKhuxXUoTLIr2eJY V82ElOkyaDGmSA/JoCAWGXcRRpJobpywSlQ6WQrHZF1NhpQytKISIA/iNElnqP2soRXfQ7Dy OdZ6ZZm+6BzGa43XlplgOHDQKbbKxykC30uWdCqgpJWbpuBRtvlcJ8axFLIqa5VZPFVyIeew X93sFmtVHILtVbS246k4fF/4+eS4KjvJLFLwrnM0AZM2tOIFMLWeFnHKxuoONaEqnPc7VA/a 3aoltXt+FEAy7MIUmCBkPSQYhA7GC63UOSpEnXWbNsctNHXBg47rCFEgTFZtPeSK9mRPYSRm mn0/0bhdp9B5CVvnmMLtu5wmyMuilB8z/3y41VCBJgEobK1JIQplipZVEJQTL3TYOoy3GKmP G1rRTzbVz3ec8bAEU0QTZWYxLVFQfiYgoLJRxWpsHqIU0KdV21Uy7yLnOLSR5tSXuAsYlrFf LW2KTBZqmXIfOR+sQyU3F5neRdZ8GVrRLNbwoqFVNNOuOH5xcW+QGxOZdrsQmUMbjwEoMWci 05YJWPBJD1cdrs966DNFOY4Z6ofsMK5KO+i84IDqNK2+pMXEqSZ9On5x0e70lg5gbmMiM2Ne 2Bw5nWYCtIVEba3C0WU0ODRTpSSO29mGsg+TPmo3YR6n1WwDRHKF0/RcBc1NwrbkdkIxBAcw sFLamMjkNkdOp4Q7D68M3J9A/cPrqF+9DgDDidqa2mWAUOB9NDHnFITCcsIqTB9NtubA+CqU Vo9cxBBgSJrKe/ydGn5afQnS1jUAwKsPjODXZ7+Dt+45MXX84mIBv3wufTjzZRw5n0Lj+g4+ eep5M0BT0V2S8nGPQvmGc8z9CiW6WnWVukcAK7dLEWESU0kAkLau4VcvLUAYbODwtz6FMNjA d99ZhfTKNTx9fspUstK4vgMAaNzYsRs8OCgy3jZlNSc+6OSrPlyG4gCOvc/JjU8ybeaiKEsM nalM1/4MABh89gYOPdyc7CNP3MTILz6AtHUN2rEhJGprlU2gVH93c2r375s6gHKitsbTF1Y5 sIRLcNg1dFnFQan5tI97TNAphlYsMS5MR3MDy67imnuBTKzVBoTBgy7y0CM7OEEuBAAStbXc sedfE4b+VBtK1NZ411YucWij4qMdtYWgzovOl600UpTyOTSLX0bp1L0eMjfSFkAoAPDWPSea ruDmwbh0c+0Y3jj5Bb1NFLTSoguqilJeoQISxSOgDOtmdCoYypJFM/8qlGDKOj2H5v6J3E63 GJZlzACYfvG3JTx0XcORJ24ilqjDePMQfpI4j8rIV3MbE5lSOwbg8/0WTi7gQKEqleWfs/j/ uU5t5zNVT2VLCkAnMFW6AhAMKC48/k4t+eC//gkAeG34S+pfP3/fXLvAYOHtswFWkormbidb E5q0gKXS7gJhF0BURCmfoeRZHFQB3zUWwoaGJgEoGxMZfXPkdJySOOZKk2OnBUUYgC7cBaXx CRbufvFtJQLlJeFy0IUBwgL2q4imPfIP5aii+QBjSlOcoVs+M8Gh8gQu163rzZHTB1aq+DUB 4qMCcMRe0Xecv6JHpEiZ4e86xQcH3nZHB3v98PtItpk5u8lhXqAQOYNh74zBwCMCxMebePv5 7vcwv/tNAMAxbONn4svjT21fTiKig7RMoqjq4mL8JntkQyuOd2ojj8k/LDB9SFmzAOBUABzj BIY4LGld8dEmGH5fH9kDAwBs4SieM56BNjgkb/3wi+MdWmRBd0kvdNAgmO+wmHfJiXBjdDFO 7Yxb/bZwd/O/f2sct31AwxBwi/trevyKHPH9PEVhKLZpAUtEhQtmcMzNunZoxVEWK9KT1W4S R48IJaly1mCS00tcIrMQjvJU7DKOYfvAtYeEDXxDeBf194HNkdMp9CUI61gBsEw5E/4AjKrz 9feB2H3ASeEaXj40h9/VvwIAuAvbeHrgMgCg8VGjU6tVQbBXGiifFdBFBgjj1ToOfz8GHGmC 4kcDfzj4+esNNLb3cgPtlmovAoLOwIzC5nBvtwHitnxC/Sqw83wd4qMCYqf30x2Nj5pg2H27 uSnGq1gmoMzZBcIuUuiaFRxxGp0XIJZgsw1dvwrsvNgA4Fg0VOngSnN7RSIr2U6nsNspXDKV lIcIc+BkLFFbq3Zq8A6FtSxYCz32kw3jxPhki/WuwucRRm6payqmDbLrWE7U1rJdpNAkqLyv 1yxCgJ9sUOBwWo07IAgUMplhr44VErW1mS5RpF3p/VxUPD8iy7AC/wUzrnszkZzLpH2NM5ZI XkezXK2cqK3pXaJINzeX6wVQOLx41dNVO7GUSGhnorZW7oHF5cUyJhHRG3c5S5gs8QU47H9w BcTxi4txNOsLbitVR/Osht5FivQqrE2iN0QO8Yzj2GKcwWCeYWRdhemnl+mebpE4+hIdIMgE pwDg5OAtnE381/p5Cnxf69eqXOpPf7SAOAcAL3z9Pfzx7GW8MPI6at++gpFj2636u6jEK/9R 7pE5DEOR9XYAAs9IOs4euQLhym8gvPsC7tYWMf3g1a7UIkXZWRe+nusRQFRDPHPJSr8NrZg2 tGKca1B57+AtCDc+2L9w4wPgru7VpOUHXcyYQomivD1CWQjoinUb62e+kqnMExBq7ZOjaJx8 AMK//wLsfgoMjWDLiLVq3qIGhdoj9NLR0lmO/nlJri2ZSirHX5956ENMnNoEAPzj5iH8YOVe 1LaOmrcNb0xkVPSFu1CCahruRxByrPWjXyBKobn7qwNQuGYqj19cTKOZuo7bmKnsxkSm0p+6 yIGRxu21HlWH32E33929934L7qlryjWkcPDNM0qXJaX6gr1fDkiCORYYyV7G7iufM0GhDDz5 cR8IPSQCZyAkyWXIFlqU6QOjR4JUzu3NN24K8vbSHahvDkAYrGPw2RuyMNiYRQQvt+hL9wNC 3nntKHbe2D/MKSw1MPjsjVRf1b0hkZ/LqG8OAL2zc9gHBOf21NiJ3YMmqPn+qWpf1Z9Nl1E4 9PDO/J0//g+MNw9j4H4D4v23AE4/Q9yXHmMZxDRkYhln0Hzdb3ngyY/Vvqp7Q/43ADNjguJO +r9gAAAAAElFTkSuQmCC --------------010001070501000105030102-- --------------080002000709050706010400-- From joelja@bogus.com Fri Feb 15 10:56: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 170AC21F8853 for ; Fri, 15 Feb 2013 10:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G84sk6M1ZTXT for ; Fri, 15 Feb 2013 10:56:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 917B321F8849 for ; Fri, 15 Feb 2013 10:56:26 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1FIuP5L047912 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 15 Feb 2013 18:56:26 GMT (envelope-from joelja@bogus.com) Message-ID: <511E84D5.2080805@bogus.com> Date: Fri, 15 Feb 2013 10:56:21 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Feb 2013 18:56:26 +0000 (UTC) Subject: [v6ops] reminder on cutoff times. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2013 18:56:27 -0000 v6ops chairs really want to see drafts discussed on this list prior to allocating time for them. that said they have to be submitted first, so if you have initial drafts to submit they need to be in by monday. Thanks joel ... This is a reminder that the Internet Draft Initial Version (-00) cut- off is this coming Monday, February 18th, 2013. Please note that, because the AMS office is closed this Monday, manual submissions will not be processed until Tuesday, February 19th. All Initial Version (-00) submissions are due by UTC 24:00. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 86 can be found at: https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 Thank you for your understanding and cooperation. If you have any questions or concerns please send a message to internet-drafts@ietf.org. From joelja@bogus.com Fri Feb 15 12:56: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 033C521F8671 for ; Fri, 15 Feb 2013 12:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgCAleB0yOB0 for ; Fri, 15 Feb 2013 12:56:28 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E506921F863C for ; Fri, 15 Feb 2013 12:56:26 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1FKuQ4l049117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 20:56:26 GMT (envelope-from joelja@bogus.com) Message-ID: <511EA0F5.6040108@bogus.com> Date: Fri, 15 Feb 2013 12:56:21 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Warren Kumari , Ronald Bonica References: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Feb 2013 20:56:26 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] Management Changes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2013 20:56:29 -0000 On 2/14/13 11:51 AM, Warren Kumari wrote: > On Feb 14, 2013, at 2:37 PM, Ronald Bonica wrote: > >> Folks, >> >> I would like to congratulate Joel Jaeggli on his new role as OPS Area Director and announce that Joel will be stepping down as V6OPS chair. Please join me in welcoming John Brosowski who, along with Fred Baker, will co-chair V6OPS. > Hang on a tick… > > This makes it sounds like John is starting as v6ops chair now, but Joel only starts as new Ops AD at the new meeting, right? > > So, what exactly will Joel be doing for the next many weeks? Twiddling his thumbs? What are we paying him for again?! > > Seriously though congratulations John… Joel has enough to do I'm certain. > > W > >> -------------------------- >> Ron Bonica >> vcard: www.bonica.org/ron/ronbonica.vcf >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > -- > Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Fri Feb 15 12:59: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 B927B21F8671 for ; Fri, 15 Feb 2013 12:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.824 X-Spam-Level: X-Spam-Status: No, score=-101.824 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjRlvhkl5iuW for ; Fri, 15 Feb 2013 12:59:03 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECDC21F8614 for ; Fri, 15 Feb 2013 12:59:03 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1FKx204049169 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 20:59:02 GMT (envelope-from joelja@bogus.com) Message-ID: <511EA191.4060706@bogus.com> Date: Fri, 15 Feb 2013 12:58:57 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Ronald Bonica , IPv6 Operations References: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501EDB227@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Feb 2013 20:59:03 +0000 (UTC) Subject: Re: [v6ops] Management Changes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2013 20:59:03 -0000 On 2/14/13 11:37 AM, Ronald Bonica wrote: > Folks, > > I would like to congratulate Joel Jaeggli on his new role as OPS Area Director and announce that Joel will be stepping down as V6OPS chair. Please join me in welcoming John Brosowski who, along with Fred Baker, will co-chair V6OPS. I would also like to thank everyone that volunteered and/or whom I pigeonholed. One of the great stories about v6ops is the number of people who have enthusiasm for what is not a trivial job. > > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From sowmini05@gmail.com Fri Feb 15 17:46: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 2DEE621F85E7 for ; Fri, 15 Feb 2013 17:46:55 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf5jvoaigGcY for ; Fri, 15 Feb 2013 17:46:55 -0800 (PST) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 100A521F8461 for ; Fri, 15 Feb 2013 17:46:54 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id 6so1701251qeb.25 for ; Fri, 15 Feb 2013 17:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eVY8AoVeRYrI6YRGqEOF9MBw8BQ3WkS3FUa7n5doD7M=; b=k2p9EQS8Ai5h7CTp/90uAvbBQE9GnD/8TOsbk5fx+3SvZB5hi5II2G/NmdaEPvKVr2 AGakW8xLlbIRLp1GlC/shs2Fxel8PvhXDg6GCfn7L8swddK3G3b02ZhDHoqXm0xMWO6T WIG5+Gj/806HIkMwQ45HuxzVjRW0uewKuavMowRvAdKD9moxZ7SsSljEAVKYKEdcgkSL xDMdNwXvBke6K1jzrFaAK0dmZp0Ac8N63USKOn82C9IopLD2PgfIfUalpeYNWiZFYcSp /xRXHp7OYa3gJ2cJkCSJr1XkN2exOV2Y6E8CpgMKb+30ar0rtTzxxnwz5iUmfnYO1MLE Rmyg== MIME-Version: 1.0 X-Received: by 10.224.72.134 with SMTP id m6mr2575345qaj.42.1360979214619; Fri, 15 Feb 2013 17:46:54 -0800 (PST) Received: by 10.49.63.195 with HTTP; Fri, 15 Feb 2013 17:46:54 -0800 (PST) In-Reply-To: <20130215131848.GD15101@omroep.nl> References: <6EBC0E51-51B2-4749-AD05-BCF4CAC8213B@steffann.nl> <511BE070.3000607@acm.org> <511CA5A7.3070500@gmail.com> <7E9CF6B3-C8C6-45A6-8BBA-B2C3CBAAE6F6@steffann.nl> <511D939D.5050608@acm.org> <20130215131848.GD15101@omroep.nl> Date: Fri, 15 Feb 2013 20:46:54 -0500 Message-ID: From: sowmini varadhan To: Leo Baltus Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Source address selection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Feb 2013 01:46:56 -0000 On Fri, Feb 15, 2013 at 8:18 AM, Leo Baltus wrote: > Op 14/02/2013 om 17:47:09 -0800, schreef Erik Nordmark: > > As Sander has pointed out there is an issue with source address > selection in IPv6 because it defaults to using the most recently > added address. In our case, were are not using SLAAC, this is always an > address of some service that is started last. Are you sure this is not just an implementation artifact of whatever OS you are using? There's nothing that I can see in RFC6724 that mandates that the "most recently added address" should be selected first. However Rule 5 does prefer outgoing interface over some other cases that may apply in your use-case (e.g., longest matching prefix), so trying Erik's suggestion of adding service-address on the loopback (and having the services explicitly bind() to that address) might solve your problem? --Sowmini From ipepelnjak@gmail.com Sat Feb 16 09:46: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 9F77D21F8964 for ; Sat, 16 Feb 2013 09:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbYOED2jYvCS for ; Sat, 16 Feb 2013 09:46:37 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55C21F8943 for ; Sat, 16 Feb 2013 09:46:37 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so2402348eei.35 for ; Sat, 16 Feb 2013 09:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=RagHzO/HvSchyGylrNlE5FnCZTqvqjqSKmIaoKiLIGI=; b=TSPbjWVOBrKqJ1cOlXuhF0XcWRBjubt12a9a8M01cL+V9fVOKvoJvtgGze3ki4ztJ0 IcCSRRpYeBkAxe2+VNnSloLDWO8oH8z/Uj5rFIZyTc7t+w8SXz79R+vj5JEY0DlfiUdk ey+gzxldWlutAdtsqX9Yuga30+qNafd1zrRRKAFeoBBzK0P6UccliCQawPTAMLSNeNax S6cw98OjK1inHFHF9hw/dB8vJWEbndpbcn6l3aMUXxqVX+dJ+5Cp9O9AjmnOfAt3+7mm WqlzVd9h8N0jNkLsGYGcGqLPyCdR+rPASfNn/4dLZ/O5Vlz68PFr9rPvBxJ4KvVdLDQb UT5g== X-Received: by 10.14.223.199 with SMTP id v47mr22796225eep.18.1361036796506; Sat, 16 Feb 2013 09:46:36 -0800 (PST) Received: from PIPINB2009 (BSN-61-106-78.dial-up.dsl.siol.net. [86.61.106.78]) by mx.google.com with ESMTPS id m46sm25387232eeo.16.2013.02.16.09.46.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 Feb 2013 09:46:36 -0800 (PST) From: "Ivan Pepelnjak" To: "'Iljitsch van Beijnum'" , "'IPv6 Ops WG'" References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> In-Reply-To: <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> Date: Sat, 16 Feb 2013 18:46:34 +0100 Message-ID: <006201ce0c6d$90d352a0$b279f7e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4LWKvwvPgHUX1hStyjAme1Pbp0qQBFNB1g Content-Language: sl Subject: Re: [v6ops] draft-steffann-tunnels-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: Sat, 16 Feb 2013 17:46:39 -0000 One word: amazing! Great job. Ivan > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Iljitsch van Beijnum > Sent: Friday, February 15, 2013 9:44 AM > To: IPv6 Ops WG > Subject: [v6ops] draft-steffann-tunnels-00.txt > > Hi all, > > Three of us were asked by the Dutch academic network Surfnet to write an > overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider > community, we did so in the form of a draft, that we intend to submit to > the RFC Editor as an independent submission. > > However, we would very much appreciate reviews and comments from within > the IETF. These are the mechanisms we discuss: > > 3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 6 > 3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 7 > 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 8 > 3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 9 > 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 9 > 3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 10 > 3.7. Intra-site Automatic Tunnel Addressing (ISATAP) . . . . . 11 > 3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 12 > 3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 13 > 3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 14 > 3.11. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 15 > 3.12. The Locator/ID Separation Protocol (LISP) . . . . . . . . 16 > 4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 17 > 4.1. Tunnel Information and Control protocol (TIC) . . . . . . 17 > 4.2. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 18 > 4.3. Dual-Stack Lite (Softwire) . . . . . . . . . . . . . . . . 19 > > Thanks! > > Iljitsch > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: I-D Action: draft-steffann-tunnels-00.txt > > Date: 15 februari 2013 9:34:07 CET > > To: i-d-announce@ietf.org > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : A comparison of IPv6 tunneling mechanisms > > Author(s) : S.J.M. Steffann > > Iljitsch van Beijnum > > Rick van Rein > > Filename : draft-steffann-tunnels-00.txt > > Pages : 37 > > Date : 2013-02-15 > > > > Abstract: > > This document provides an overview of various ways to to tunnel IPv6 > > packets over IPv4 networks. It covers mechanisms in contemporary > > use, touches on several mechanisms that are now only of historic > > interest, and discusses some newer tunneling mechanisms that are not > > (yet) widely used at the time of publication. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-steffann-tunnels > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-steffann-tunnels-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sat Feb 16 22:25: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 68A3421F89AF for ; Sat, 16 Feb 2013 22:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilBeDc+6FPF0 for ; Sat, 16 Feb 2013 22:25:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38821F88DB for ; Sat, 16 Feb 2013 22:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1492; q=dns/txt; s=iport; t=1361082357; x=1362291957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cuEqmyWxPhIOtFuYhxSdkcEQ5YUamGfVfn94otosieo=; b=C5Jqr7jJq8DrSkp9qpo0FLZ/9CYpMLurksXFHjJ9JwFcMrVgzSVBPdgd QiITKMcoKBLISofDPAbdA8VKQ5SJZ8r2NohbykHWFK3MQdjap+Fo6aDqo Gd8/fVRpZvX25L2VqES2i0/nZw7VaQtevNtCOoshJwH81/tnzfF4azwkt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHt2IFGtJXG//2dsb2JhbABEwB6BAxZzgh8BAQEDATo/BQsCAQgYChQFCzIlAgQOBQiIBAa9Go1lgR8CMQeCX2EDpwSBUoE1gic X-IronPort-AV: E=Sophos;i="4.84,681,1355097600"; d="scan'208";a="177771285" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 17 Feb 2013 06:25:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1H6Pvga019546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Feb 2013 06:25:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 00:25:56 -0600 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: AQHODNekVZKYhGyOsEuHG0rsd5iCwQ== Date: Sun, 17 Feb 2013 06:25:56 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B795752@xmb-rcd-x09.cisco.com> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <511C8EA0.2070708@bogus.com> In-Reply-To: <511C8EA0.2070708@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E649F412907FC4EB5EBB62FB9BC1481@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-binet-v6ops-cellular-host-requirements@tools.ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Sun, 17 Feb 2013 06:25:58 -0000 On Feb 13, 2013, at 11:13 PM, joel jaeggli wrote: > On 1/30/13 11:19 AM, joel jaeggli wrote: >> Greetings, >>=20 >> This kicks of a request for adoption as a working group document on draf= t-binet-v6ops-cellular-host-requirements-02.txt >>=20 >> This document and a similar one were discussed during IETF 85 and were u= pdated accordingly. Support was far from unanimous at the time and we're in= terested in seeing how far it has progressed. >>=20 >> The deadline for this discussion phase is two weeks from today, 2/13. > This test is completed. Following up from the discussion. In Joel's thread, I saw 27 emails from 18 people. Some comments didn't real= ly take a position on the question, and some argued against adoption. Howev= er, the preponderance of speakers spoke in favor of adoption. So I believe = that the working group consensus, albeit rough, supports that status. As chair, this leaves me puzzled. We already have a working group draft upd= ating RFC 3316: draft-ietf-v6ops-rfc3316bis. If this is also a working grou= p document, and intended to give guidance and RFP air support to operators,= IMHO either it has to merge with draft-ietf-v6ops-rfc3316bis or be obvious= ly different from it, not only during our discussion but to purchasing agen= ts that list it as a requirement in RFPs/RFIs. It will be up to this workin= g group to draw that distinction. I'm hoping for a lot of help in getting t= hat right.= From fred@cisco.com Sun Feb 17 05:45:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E455521F87D5 for ; Sun, 17 Feb 2013 05:45:01 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AyVr0f+4ZyY for ; Sun, 17 Feb 2013 05:45:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0DA21F85C6 for ; Sun, 17 Feb 2013 05:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134; q=dns/txt; s=iport; t=1361108701; x=1362318301; h=date:from:message-id:to:subject:cc; bh=+w6lMHJVRMZ4XQqDW7nokNdXiuFl68P4TdfTPJqHZXU=; b=aeM57xtq3b30guqWoQchDsWir9wWANXAh7iwdWeAjQH6wwfW0627hnJR XXMwkQW7Fry1xeBgXGpZO+XdiVZPZW5dkva14ReH/WvroU1+PH+E3VRtd CMrEkqnp21EkGlfmk/CTdEbM92MkNpGhep3xhHJG4cHxv29MHl8NPjlD9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwFAKLeIFGrRDoJ/2dsb2JhbABEhgKoWwGRNgh/FnODHzwtB4hyDb1ZjzcdgyoDiGeOYo87gyg X-IronPort-AV: E=Sophos;i="4.84,682,1355097600"; d="scan'208";a="72484719" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 17 Feb 2013 13:45:01 +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 r1HDj1BS024641; Sun, 17 Feb 2013 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r1HDj0I02968; Sun, 17 Feb 2013 05:45:00 -0800 (PST) Date: Sun, 17 Feb 2013 05:45:00 -0800 (PST) From: Message-Id: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-sun-v6ops-semantic-usecase@tools.ietf.org Subject: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2013 13:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase. Please take a look at it and comment. From joelja@bogus.com Sun Feb 17 16:23:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A8821F8AED for ; Sun, 17 Feb 2013 16:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X5Kk2v-W7lL for ; Sun, 17 Feb 2013 16:23:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 55D4521F8AEA for ; Sun, 17 Feb 2013 16:23:09 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1I0N5IV079265 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 18 Feb 2013 00:23:06 GMT (envelope-from joelja@bogus.com) Message-ID: <51217464.5030507@bogus.com> Date: Sun, 17 Feb 2013 16:23:00 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> In-Reply-To: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 18 Feb 2013 00:23:07 +0000 (UTC) Cc: draft-sun-v6ops-semantic-usecase@tools.ietf.org Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2013 00:23:10 -0000 On 2/17/13 5:45 AM, fred@cisco.com wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase. Please > take a look at it and comment. I have some serious qualms about specifying something that that you absolutely do not want to honor outside your own domain of control. While this isn't too proscriptive both documents together are headed in that direction. As with draft-jiang-semantic-prefix the notion that host stacks might be modified to treat particular masks of bits differently within applications is an especially expensive form of application network aware-signaling, flies completely in the face of the uniform utility of ipv6 unicast addressing. Generically, the utility for an operator of ascribing meaning to a particular bit mask outside of the host mask is relatively straight forward and consistent with all sorts of addressing plans (I can for example trivially identify all the router loopback(s) in my network due the the addressing scheme, likewise internal site versus external site assignments and so on within given /48 site assignement(s). I think both of these drafts can be made useful but there are limits clearly to the scope in which they can be applied. thanks joel > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From jiangsheng@huawei.com Mon Feb 18 01:28:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BCC21F87A5 for ; Mon, 18 Feb 2013 01:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ1S-69ZfeeP for ; Mon, 18 Feb 2013 01:28:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CBC8621F874C for ; Mon, 18 Feb 2013 01:28:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APV16944; Mon, 18 Feb 2013 09:28:01 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 18 Feb 2013 09:27:24 +0000 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 18 Feb 2013 17:27:53 +0800 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.45]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Mon, 18 Feb 2013 17:27:39 +0800 From: Sheng Jiang To: joel jaeggli , "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-sun-v6ops-semantic-usecase Thread-Index: AQHODRUGSGVThzwNXEi0zYrwFYdM2ph+O/AAgAESIdA= Date: Mon, 18 Feb 2013 09:27:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A009E8D@szxeml545-mbx.china.huawei.com> References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> <51217464.5030507@bogus.com> In-Reply-To: <51217464.5030507@bogus.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: "draft-sun-v6ops-semantic-usecase@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2013 09:28:04 -0000 VGhhbmtzIEpvZWwgZm9yIHlvdXIgY29tbWVudHMgYW5kIHN1cHBvcnQuIFNvbWUgcmVwbGllcyBp biBsaW5lcy4NCg0KDQo+RnJvbTogam9lbCBqYWVnZ2xpIFttYWlsdG86am9lbGphQGJvZ3VzLmNv bV0NCj5PbiAyLzE3LzEzIDU6NDUgQU0sIGZyZWRAY2lzY28uY29tIHdyb3RlOg0KPj4gQSBuZXcg ZHJhZnQgaGFzIGJlZW4gcG9zdGVkLCBhdA0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc3VuLXY2b3BzLXNlbWFudGljLXVzZWNhc2UuIFBsZWFzZQ0KPj4gdGFrZSBhIGxvb2sg YXQgaXQgYW5kIGNvbW1lbnQuDQo+DQo+SSBoYXZlIHNvbWUgc2VyaW91cyBxdWFsbXMgYWJvdXQg c3BlY2lmeWluZyBzb21ldGhpbmcgdGhhdCB0aGF0IHlvdQ0KPmFic29sdXRlbHkgZG8gbm90IHdh bnQgdG8gaG9ub3Igb3V0c2lkZSB5b3VyIG93biBkb21haW4gb2YgY29udHJvbC4NCj5XaGlsZSB0 aGlzIGlzbid0IHRvbyBwcm9zY3JpcHRpdmUgYm90aCBkb2N1bWVudHMgdG9nZXRoZXIgYXJlIGhl YWRlZCBpbg0KPnRoYXQgZGlyZWN0aW9uLg0KDQpXZSBmdWxseSBhZ3JlZSB0aGUgYXNzaWduZWQg c2VtYW50aWMgZm9yIHByZWZpeCBzaG91bGQgYmUgb25seSBtZWFuaW5nZnVsIGxvY2FsbHkuIElu IHNvbWUgdXNlIGNhc2UsIHRoZXNlIHNlbWFudGljIG1heSBhbHNvIGJlIHVzZWZ1bCBpbmZvcm1h dGlvbiBvdXRzaWRlIHRoZSBkb21haW4uIERvIHlvdSB0aGluayB0aGUgbGVhayBvZiBzZW1hbnRp YyBpbmZvcm1hdGlvbiBtYXkgY2F1c2Ugc2VjdXJlIGlzc3Vlcz8gSWYgc28sIHdlIGNhbiBhZGQg c29tZSBjb25zaWRlcmF0aW9uIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uLg0KDQo+QXMgd2l0aCBk cmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVmaXggdGhlIG5vdGlvbiB0aGF0IGhvc3Qgc3RhY2tzIG1p Z2h0IGJlDQo+bW9kaWZpZWQgdG8gdHJlYXQgcGFydGljdWxhciBtYXNrcyBvZiBiaXRzIGRpZmZl cmVudGx5IHdpdGhpbg0KPmFwcGxpY2F0aW9ucyBpcyBhbiBlc3BlY2lhbGx5IGV4cGVuc2l2ZSBm b3JtIG9mIGFwcGxpY2F0aW9uIG5ldHdvcmsNCj5hd2FyZS1zaWduYWxpbmcsIGZsaWVzIGNvbXBs ZXRlbHkgaW4gdGhlIGZhY2Ugb2YgdGhlIHVuaWZvcm0gdXRpbGl0eSBvZg0KPmlwdjYgdW5pY2Fz dCBhZGRyZXNzaW5nLg0KDQpUaGUgYXBwbGljYXRpb24tYXdhcmUgaXMgYW4gZXh0ZW5kIHVzZSBj YXNlLiBZZXMsIGl0IGlzIGV4cGVuc2l2ZSBhbmQgaXQgaXMgdGVjaG5pY2FsIGdhcCB0byBtYWtl IGdvb2QgdXNlIG9mIGl0IGZyb20gdGhlIGN1cnJlbnQgbmV0d29yayBhbmQgdXNlciBkZXZpY2Vz LiBUaGUgYmFzaWMgdXNlIGNhc2UgaXMgb25seSBlbWJlZGRlZCB1c2VyIHNlbWFudGljLCB3aGlj aCBpcyBjaGVhcCBhbmQgbWF5IGJlIHN1cHBvcnRlZCBieSBjdXJyZW50IG5ldHdvcmtzLiBUaGlz IHB1cnBvc2UgaW5mb3JtYXRpb25hbCBmcmFtZXdvcmsgZG9jdW1lbnQgaXMgb25seSBkZXNjcmli ZSB0aGUgY29uY2VwdCBmcmFtZXdvcmsgYW5kIGl0cyBwb3NzaWJpbGl0aWVzLg0KDQo+R2VuZXJp Y2FsbHksIHRoZSB1dGlsaXR5IGZvciBhbiBvcGVyYXRvciBvZiBhc2NyaWJpbmcgbWVhbmluZyB0 byBhDQo+cGFydGljdWxhciBiaXQgbWFzayBvdXRzaWRlIG9mIHRoZSBob3N0IG1hc2sgaXMgcmVs YXRpdmVseSBzdHJhaWdodA0KPmZvcndhcmQgYW5kIGNvbnNpc3RlbnQgd2l0aCBhbGwgc29ydHMg b2YgYWRkcmVzc2luZyBwbGFucyAoSSBjYW4gZm9yDQo+ZXhhbXBsZSB0cml2aWFsbHkgaWRlbnRp ZnkgYWxsIHRoZSByb3V0ZXIgbG9vcGJhY2socykgaW4gbXkgbmV0d29yayBkdWUNCj50aGUgdGhl IGFkZHJlc3Npbmcgc2NoZW1lLCBsaWtld2lzZSBpbnRlcm5hbCBzaXRlIHZlcnN1cyBleHRlcm5h bCBzaXRlDQo+YXNzaWdubWVudHMgYW5kIHNvIG9uIHdpdGhpbiBnaXZlbiAvNDggc2l0ZSBhc3Np Z25lbWVudChzKS4NCg0KVGhlcmUgYXJlIG1hbnkgYmVuZWZpdHMgZm9yIG9wZXJhdG9yIHRvIGRv IHRoaXMuIEFjdHVhbGx5LCBzb21lIG9wZXJhdGlvbiBtYXkgYWxyZWFkeSBhcHBseSBzdWNoIG5v dGlvbiBpbiB0aGVpciBhZGRyZXNzaW5nIHBsYW5zIG9uZSB3YXkgb3IgYW5vdGhlci4NCg0KPkkg dGhpbmsgYm90aCBvZiB0aGVzZSBkcmFmdHMgY2FuIGJlIG1hZGUgdXNlZnVsIGJ1dCB0aGVyZSBh cmUgbGltaXRzDQo+Y2xlYXJseSB0byB0aGUgc2NvcGUgaW4gd2hpY2ggdGhleSBjYW4gYmUgYXBw bGllZC4NCg0KRnVsbHkgYWdyZWUuIEFjdHVhbGx5IGl0IGlzIG9uZSBvZiB0aGUgcHVycG9zZSBv ZiBmcmFtZXdvcmsgZG9jdW1lbnQgdG8gbGlzdCBhbmQgZG9jdW1lbnQgdGhlc2UgbGltaXRhdGlv bnMgYW5kIHRlY2huaWNhbCBnYXBzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj50aGFu a3MNCj5qb2VsDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From mohamed.boucadair@orange.com Mon Feb 18 01:48: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 E864421F87AB for ; Mon, 18 Feb 2013 01:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-i00mnDqB11 for ; Mon, 18 Feb 2013 01:48:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 191E521F87AA for ; Mon, 18 Feb 2013 01:48:41 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A2A943244BD; Mon, 18 Feb 2013 10:48:40 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8466635C04E; Mon, 18 Feb 2013 10:48:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 18 Feb 2013 10:48:40 +0100 From: To: "Fred Baker (fred)" , IPv6 Ops WG Date: Mon, 18 Feb 2013 10:48:38 +0100 Thread-Topic: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt Thread-Index: AQHODNekVZKYhGyOsEuHG0rsd5iCwZh/VHaQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EB1A52B9F@PUEXCB1B.nanterre.francetelecom.fr> References: <20130130122812.15161.13098.idtracker@ietfa.amsl.com> <5109723D.4090905@bogus.com> <511C8EA0.2070708@bogus.com> <8C48B86A895913448548E6D15DA7553B795752@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B795752@xmb-rcd-x09.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: 2012.12.31.121227 Cc: "draft-binet-v6ops-cellular-host-requirements@tools.ietf.org" Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.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: Mon, 18 Feb 2013 09:48:43 -0000 Dear Fred, Thanks for confirming there is consensus for the adoption of draft-binet-*.= =20 draft-binet-* already includes a section to position itself vs. draft-ietf-= v6ops-rfc3316bis. This point was already raised in the last IETF meeting an= d it was clear from that discussion these two documents have two different = goals: http://www.ietf.org/proceedings/85/minutes/minutes-85-v6ops.=20 Is there anything else we can add to the draft to further clarify this?=20 Cheers, Med=20 >-----Message d'origine----- >De : Fred Baker (fred) [mailto:fred@cisco.com]=20 >Envoy=E9 : dimanche 17 f=E9vrier 2013 07:26 >=C0 : IPv6 Ops WG >Cc : draft-binet-v6ops-cellular-host-requirements@tools.ietf.org >Objet : Re: [v6ops] Test for adoption as a working group=20 >document - Re: I-D Action:=20 >draft-binet-v6ops-cellular-host-requirements-02.txt > > >On Feb 13, 2013, at 11:13 PM, joel jaeggli wrote: > >> On 1/30/13 11:19 AM, joel jaeggli wrote: >>> Greetings, >>>=20 >>> This kicks of a request for adoption as a working group=20 >document on draft-binet-v6ops-cellular-host-requirements-02.txt >>>=20 >>> This document and a similar one were discussed during IETF=20 >85 and were updated accordingly. Support was far from=20 >unanimous at the time and we're interested in seeing how far=20 >it has progressed. >>>=20 >>> The deadline for this discussion phase is two weeks from=20 >today, 2/13. >> This test is completed. > > >Following up from the discussion. > >In Joel's thread, I saw 27 emails from 18 people. Some=20 >comments didn't really take a position on the question, and=20 >some argued against adoption. However, the preponderance of=20 >speakers spoke in favor of adoption. So I believe that the=20 >working group consensus, albeit rough, supports that status. > >As chair, this leaves me puzzled. We already have a working=20 >group draft updating RFC 3316: draft-ietf-v6ops-rfc3316bis. If=20 >this is also a working group document, and intended to give=20 >guidance and RFP air support to operators, IMHO either it has=20 >to merge with draft-ietf-v6ops-rfc3316bis or be obviously=20 >different from it, not only during our discussion but to=20 >purchasing agents that list it as a requirement in RFPs/RFIs.=20 >It will be up to this working group to draw that distinction.=20 >I'm hoping for a lot of help in getting that right.= From fred@cisco.com Mon Feb 18 05:45: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 6D09C21F88C7 for ; Mon, 18 Feb 2013 05:45:02 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DmxWjqacgvs for ; Mon, 18 Feb 2013 05:45:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0421F88BC for ; Mon, 18 Feb 2013 05:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126; q=dns/txt; s=iport; t=1361195101; x=1362404701; h=date:from:message-id:to:subject:cc; bh=qjcY2yW7RpvWO3UH2/HkWBitt/gK13rtRvXMxGcDLAU=; b=JQFivW6vkuRDP/rujfbo80lu2fRLyy5ISoPGz8+qcPHXLLZmtovvTEZ3 52yjfJZR02+bEf8IXPR/2mR5w1MGG7PSyYM+Gpfq+tp8q4pwXVgqdDhRy jiGTZLCIXf7JorH/5JOgrSeiTtv+d4qn4ysB4JJwHt/v3b1Qz9K8VyPYE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIGAMMvIlGrRDoH/2dsb2JhbABFhgKoYAGRNgiBBRZzgx88LQeIcg2/U483HYMqA4hnjmKPO4Mo X-IronPort-AV: E=Sophos;i="4.84,688,1355097600"; d="scan'208";a="72590035" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Feb 2013 13:45:00 +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 r1IDj0AL008564; Mon, 18 Feb 2013 13:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r1IDj0J04495; Mon, 18 Feb 2013 05:45:00 -0800 (PST) Date: Mon, 18 Feb 2013 05:45:00 -0800 (PST) From: Message-Id: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-shishio-v6ops-dpvt@tools.ietf.org Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2013 13:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. Please take a look at it and comment. From bingxuere@gmail.com Mon Feb 18 06:08: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 6669C21F8958 for ; Mon, 18 Feb 2013 06:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohRKtyWV1JTM for ; Mon, 18 Feb 2013 06:08:39 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1227C21F8918 for ; Mon, 18 Feb 2013 06:08:39 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so5647326obb.3 for ; Mon, 18 Feb 2013 06:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=9PJfRpUnmgIGmCYbO3xakM2m+Zf7MrrwwTKSVJuDFi8=; b=mExQktMYqxdE6E8UA4EtQYcdSmzqesy0dKr/0v3MOPYPgNhuqlXIrGrA1JcUkrGUeO 4SdjVTqAoadiTZhAtyPns25Ur9uTJif1csQhsk8aQMTmPtoDYjHPu45WYLnW6K8nfkkX C8Stcy6bWcg6UMFLEVqN/8gIuag/OtY2mrfq2xU9QCDnrxuzRSMGPRyUcUgftFj0qS5O /QxQ1QB0tknYvXzgNTLevIR15jcasles8Uk1m9ufjg22bQswIQX055M6lIkw9MRegSKL B7vOjo4/RJ/RzbkPdqF3kI80x77HclMaqoOPSu8IgoUPFjZAgBfYhrBrXzFrLsUftabs 1AXA== X-Received: by 10.60.18.167 with SMTP id x7mr6206135oed.95.1361196518586; Mon, 18 Feb 2013 06:08:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Mon, 18 Feb 2013 06:07:58 -0800 (PST) In-Reply-To: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> From: Qiong Date: Mon, 18 Feb 2013 22:07:58 +0800 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=e89a8ff2566ef5b88f04d60042f0 Cc: draft-sun-v6ops-semantic-usecase@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2013 14:08:40 -0000 --e89a8ff2566ef5b88f04d60042f0 Content-Type: text/plain; charset=UTF-8 Dear Fred, Thanks for invoking it. This draft is a companion draft of I-D.jiang-v6ops-semantic-prefix. It provides a use case and some guidelines from operator's point of view. Semantic prefix can be quite useful in terms of user/device management, high-priority service guarantee, etc. However, since some limitations and implementation complexity still exist, careful considerations should be taken into designing it. Your comments/feedback are very much appreciated. Thanks in advance :) From: internet-drafts Date: 2013-02-17 15:52 To: sunqiong CC: xiechf; jiangsheng Subject: New Version Notification for draft-sun-v6ops-semantic-usecase-00.txt A new version of I-D, draft-sun-v6ops-semantic-usecase-00.txt has been successfully submitted by Qiong Sun and posted to the IETF repository. Filename: draft-sun-v6ops-semantic-usecase Revision: 00 Title: Use case of IPv6 prefix semantics for operators Creation date: 2013-02-17 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-sun-v6ops-semantic-usecase-00.txt Status: http://datatracker.ietf.org/doc/draft-sun-v6ops-semantic-usecase Htmlized: http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase-00 Abstract: Embedding certain semantics into IPv6 addresses will bring a lot of benifits for operators to simplify network management and apply operations accordingly[I-D.jiang-semantic-prefix]. This memo illustrates the use case of semantic bits from operator's point of view, and provides considerations on how to design the semantic bits in IPv6 address. The IETF Secretariat On Sun, Feb 17, 2013 at 9:45 PM, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase. Please take > a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --e89a8ff2566ef5b88f04d60042f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Fred,

Thanks for invoking it= .=C2=A0

This draft is a companion draf= t of I-D.jiang-v6ops-semantic-prefix. It provides a use case and some guide= lines from operator's point of view. Semantic prefix can=C2=A0be quite = useful in terms of user/device management, high-priority=C2=A0service=C2=A0= guarantee, etc. However, since some limitations and implementation complexi= ty still exist, careful considerations should be taken into designing it.

Your comments/feedback are very much apprec= iated. Thanks in advance :)


=
From: internet-drafts
Date: 2013-02-17 15:52
To: sunqiong
CC: xiechf; jiangsheng
Subject: New V= ersion Notification for draft-sun-v6ops-semantic-usecase-00.txt
<= br>
A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-su= n-v6ops-semantic-usecase-00.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Qiong=C2= =A0Sun=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-sun-v6ops-semantic-usecase
Revision: =C2=A000
Title: =C2=A0Use=C2=A0case=C2=A0of=C2=A0IPv6=C2=A0prefix=C2=A0semantic= s=C2=A0for=C2=A0operators
Creation=C2=A0date: =C2=A02013-02-17
Group: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A011
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0Embedding=C2=A0certain=C2=A0semantics=C2=A0into=C2= =A0IPv6=C2=A0addresses=C2=A0will=C2=A0bring=C2=A0a=C2=A0lot=C2=A0of
=C2=A0=C2=A0=C2=A0benifits=C2=A0for=C2=A0operators=C2=A0to=C2=A0simpli= fy=C2=A0network=C2=A0management=C2=A0and=C2=A0apply
=C2=A0=C2=A0=C2=A0operations=C2=A0accordingly[I-D.jiang-semantic-prefi= x].=C2=A0=C2=A0This=C2=A0memo
=C2=A0=C2=A0=C2=A0illustrates=C2=A0the=C2=A0use=C2=A0case=C2=A0of=C2= =A0semantic=C2=A0bits=C2=A0from=C2=A0operator's=C2=A0point=C2=A0of
=C2=A0=C2=A0=C2=A0view,=C2=A0and=C2=A0provides=C2=A0considerations=C2= =A0on=C2=A0how=C2=A0to=C2=A0design=C2=A0the=C2=A0semantic=C2=A0bits
=C2=A0=C2=A0=C2=A0in=C2=A0IPv6=C2=A0address.=C2=A0
=C2=A0
The=C2=A0IETF=C2=A0Secretariat
=C2=A0=C2=A0


On Sun, Feb 17, 2013 at 9:45 PM, &= lt;fred@cisco.com&g= t; wrote:

A new draft has been posted, at http://tools.ietf.org/html/d= raft-sun-v6ops-semantic-usecase. Please take a look at it and comment.<= br> _______________________________________________
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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D
--e89a8ff2566ef5b88f04d60042f0-- From bingxuere@gmail.com Mon Feb 18 06:45: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 6C64921F896B for ; Mon, 18 Feb 2013 06:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsy4lKd8JiYp for ; Mon, 18 Feb 2013 06:45:09 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id A8A8C21F890E for ; Mon, 18 Feb 2013 06:45:09 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so5822071oag.20 for ; Mon, 18 Feb 2013 06:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gXlrTnJeP5JcZrGbSm0lmmwTmsnBPLOiBd5Nh8N6GXw=; b=p/TMQGsTC8j0/2M7OGgyH5mNuI+C/gdHcMEwuPRdUn1uBk1n/ko/zHSkP6kDeIEcWl N2bzWfJUtxoIxARCPmovrYTJaPgTGIG3hlza86GBHXu8AqWO7tOk8z1y9RGIxYj+N+sY AObaWafj1Kmxi3FvEpefdgQjmDh5/Ei3PK1e2CR0iQ2iBnt59m7iEb7jEX0Xco1+VB3k v0B8La+GnNxnELx5ubYkkIkRgANDp2XibiMPRxwZOwjlLAgk3Hv4C185QMIs4DgxYjkx 6+VSvmB8bRXgUdAAmpPXzmYv7Yxu6oZUsSWSb9YOkHl6/wsmqcuSiqmFHExmqL6iDvrB D+cQ== X-Received: by 10.60.13.162 with SMTP id i2mr6174283oec.121.1361198708949; Mon, 18 Feb 2013 06:45:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Mon, 18 Feb 2013 06:44:28 -0800 (PST) In-Reply-To: <51217464.5030507@bogus.com> References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> <51217464.5030507@bogus.com> From: Qiong Date: Mon, 18 Feb 2013 22:44:28 +0800 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=e89a8fb2011884037904d600c54b Cc: draft-sun-v6ops-semantic-usecase , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2013 14:45:10 -0000 --e89a8fb2011884037904d600c54b Content-Type: text/plain; charset=UTF-8 Hi Joel, Thanks for your comments. I agree with you semantic prefix will have limitations in real world deployment. We will improve the limitation part and clearly clarify the scope for which operators should take in the next version. In designing the use case, we do need to carefully consider the tradeoff between the benefits and complexity. That's the current use case is relatively easy to deploy and have little impact on the current infrastructure. But of course, it will be evolved to reflect more requirements and feedback from the working group. Thanks ! Best wishes Qiong On Mon, Feb 18, 2013 at 8:23 AM, joel jaeggli wrote: > On 2/17/13 5:45 AM, fred@cisco.com wrote: > >> A new draft has been posted, at http://tools.ietf.org/html/** >> draft-sun-v6ops-semantic-**usecase. >> Please take a look at it and comment. >> > I have some serious qualms about specifying something that that you > absolutely do not want to honor outside your own domain of control. While > this isn't too proscriptive both documents together are headed in that > direction. > > As with draft-jiang-semantic-prefix the notion that host stacks might be > modified to treat particular masks of bits differently within applications > is an especially expensive form of application network aware-signaling, > flies completely in the face of the uniform utility of ipv6 unicast > addressing. > > Generically, the utility for an operator of ascribing meaning to a > particular bit mask outside of the host mask is relatively straight forward > and consistent with all sorts of addressing plans (I can for example > trivially identify all the router loopback(s) in my network due the the > addressing scheme, likewise internal site versus external site assignments > and so on within given /48 site assignement(s). > > I think both of these drafts can be made useful but there are limits > clearly to the scope in which they can be applied. > > thanks > joel > > ______________________________**_________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/**listinfo/v6ops >> > > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --e89a8fb2011884037904d600c54b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

Thanks for your comments.

I agree with you semantic prefix will have limitations= in real world deployment. We will improve the limitation part and clearly = clarify the scope for which operators should take in the next version.

In designing the use case, we do need to carefully cons= ider the tradeoff between the benefits and complexity. That's the curre= nt use case is relatively easy to deploy and have little impact on the curr= ent infrastructure. But of course, it will be evolved to reflect more requi= rements and feedback from the working group.

Thanks !

Best wishes
Qiong


On = Mon, Feb 18, 2013 at 8:23 AM, joel jaeggli <joelja@bogus.com>= wrote:
On 2/17/13 5:45 AM, fred@cisco.com wrote:
A new draft has been posted, at http://tools.ietf.org/html/<= u>draft-sun-v6ops-semantic-usecase. Please take a look at it= and comment.
I have some serious qualms about specifying something that that you absolut= ely do not want to honor outside your own domain of control. While this isn= 't too proscriptive both documents together are headed in that directio= n.

As with draft-jiang-semantic-prefix the notion that host stacks might be mo= dified to treat particular masks of bits differently within applications is= an especially expensive form of application network aware-signaling, flies= completely in the face of the uniform utility of ipv6 unicast =C2=A0addres= sing.

Generically, the utility for an operator of ascribing meaning to a particul= ar bit mask outside of the host mask is relatively straight forward and con= sistent with all sorts of addressing plans (I can for example trivially ide= ntify all the router loopback(s) in my network due the the addressing schem= e, likewise internal site versus external site assignments and so on within= given /48 site assignement(s).

I think both of these drafts can be made useful but there are limits clearl= y to the scope in which they can be applied.

thanks
joel

_______________________________________________ v6ops mailing list <= a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D
--e89a8fb2011884037904d600c54b-- From internet-drafts@ietf.org Mon Feb 18 18:57: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 C42D621E80B6; Mon, 18 Feb 2013 18:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaL-P6eY0+Kd; Mon, 18 Feb 2013 18:57:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6606B21E8053; Mon, 18 Feb 2013 18:57:16 -0800 (PST) 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.40 Message-ID: <20130219025716.19619.67492.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 18:57:16 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-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: Tue, 19 Feb 2013 02:57:16 -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 : Design Choices for IPv6 Networks Author(s) : Philip Matthews Filename : draft-ietf-v6ops-design-choices-00.txt Pages : 12 Date : 2013-02-14 Abstract: This document presents advice on the design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From joelja@bogus.com Mon Feb 18 23:41: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 4BF5721F8D7A for ; Mon, 18 Feb 2013 23:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6pldascP7FE for ; Mon, 18 Feb 2013 23:41:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 541E821F8D71 for ; Mon, 18 Feb 2013 23:41:37 -0800 (PST) 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 r1J7fX5O000645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 07:41:33 GMT (envelope-from joelja@bogus.com) Message-ID: <51232CA8.9070204@bogus.com> Date: Mon, 18 Feb 2013 23:41:28 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Qiong References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> <51217464.5030507@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 19 Feb 2013 07:41:34 +0000 (UTC) Cc: draft-sun-v6ops-semantic-usecase , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 07:41:38 -0000 On 2/18/13 6:44 AM, Qiong wrote: > Hi Joel, > > Thanks for your comments. > > I agree with you semantic prefix will have limitations in real world > deployment. We will improve the limitation part and clearly clarify > the scope for which operators should take in the next version. > I particular I think it would be particularly undesirable but from a policy and address assignment perspective if providers were to up the size of their assignment requests using a justification of more semantic bits required. Where does that thought experiemnt end? > In designing the use case, we do need to carefully consider the > tradeoff between the benefits and complexity. That's the current use > case is relatively easy to deploy and have little impact on the > current infrastructure. But of course, it will be evolved to reflect > more requirements and feedback from the working group. > > Thanks ! > > Best wishes > Qiong > > > On Mon, Feb 18, 2013 at 8:23 AM, joel jaeggli > wrote: > > On 2/17/13 5:45 AM, fred@cisco.com wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase. > Please take a look at it and comment. > > I have some serious qualms about specifying something that that > you absolutely do not want to honor outside your own domain of > control. While this isn't too proscriptive both documents together > are headed in that direction. > > As with draft-jiang-semantic-prefix the notion that host stacks > might be modified to treat particular masks of bits differently > within applications is an especially expensive form of application > network aware-signaling, flies completely in the face of the > uniform utility of ipv6 unicast addressing. > > Generically, the utility for an operator of ascribing meaning to a > particular bit mask outside of the host mask is relatively > straight forward and consistent with all sorts of addressing plans > (I can for example trivially identify all the router loopback(s) > in my network due the the addressing scheme, likewise internal > site versus external site assignments and so on within given /48 > site assignement(s). > > I think both of these drafts can be made useful but there are > limits clearly to the scope in which they can be applied. > > thanks > joel > > _______________________________________________ v6ops mailing > list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: /http://sourceforge.net/projects/laft6// > PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ / > =============================================== > From owen@delong.com Mon Feb 18 23:50: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 D778121F888E for ; Mon, 18 Feb 2013 23:50:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHGtuDUBxZvF for ; Mon, 18 Feb 2013 23:50:42 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1438D21F8D83 for ; Mon, 18 Feb 2013 23:50:41 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1J7o5Uw027530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2013 23:50:05 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1J7o5Uw027530 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361260205; bh=6DOXtRyzNWQv6tDDboeT1r5iddE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vyNdL1N1cvG9B8x6AqMMCkZrbhu6HPW52FRYVAVw7IW3m1QFVmtuO5Emdx9HCfUgF vlo/Xnfy85W1cKBSnH25WxG6D2aXnyoO05oH8WKDuuKnuSrNPesDtm/hla0BELrHPM qhW4wa5/HTD8h5dEg3YiWIQF9KGcPDbX9sX9f0CE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51232CA8.9070204@bogus.com> Date: Mon, 18 Feb 2013 23:50:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> <51217464.5030507@bogus.com> <51232CA8.9070204@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 18 Feb 2013 23:50:05 -0800 (PST) Cc: draft-sun-v6ops-semantic-usecase , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 07:50:43 -0000 On Feb 18, 2013, at 11:41 PM, joel jaeggli wrote: > On 2/18/13 6:44 AM, Qiong wrote: >> Hi Joel, >>=20 >> Thanks for your comments. >>=20 >> I agree with you semantic prefix will have limitations in real world = deployment. We will improve the limitation part and clearly clarify the = scope for which operators should take in the next version. >>=20 > I particular I think it would be particularly undesirable but from a = policy and address assignment perspective if providers were to up the = size of their assignment requests using a justification of more semantic = bits required. Where does that thought experiment end? I don't think the RIR communities are likely to go along with that in = terms of adopting it into policy. Owen >> In designing the use case, we do need to carefully consider the = tradeoff between the benefits and complexity. That's the current use = case is relatively easy to deploy and have little impact on the current = infrastructure. But of course, it will be evolved to reflect more = requirements and feedback from the working group. >>=20 >> Thanks ! >>=20 >> Best wishes >> Qiong >>=20 >>=20 >> On Mon, Feb 18, 2013 at 8:23 AM, joel jaeggli > wrote: >>=20 >> On 2/17/13 5:45 AM, fred@cisco.com wrote: >>=20 >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase. >> Please take a look at it and comment. >>=20 >> I have some serious qualms about specifying something that that >> you absolutely do not want to honor outside your own domain of >> control. While this isn't too proscriptive both documents together >> are headed in that direction. >>=20 >> As with draft-jiang-semantic-prefix the notion that host stacks >> might be modified to treat particular masks of bits differently >> within applications is an especially expensive form of application >> network aware-signaling, flies completely in the face of the >> uniform utility of ipv6 unicast addressing. >>=20 >> Generically, the utility for an operator of ascribing meaning to a >> particular bit mask outside of the host mask is relatively >> straight forward and consistent with all sorts of addressing plans >> (I can for example trivially identify all the router loopback(s) >> in my network due the the addressing scheme, likewise internal >> site versus external site assignments and so on within given /48 >> site assignement(s). >>=20 >> I think both of these drafts can be made useful but there are >> limits clearly to the scope in which they can be applied. >>=20 >> thanks >> joel >>=20 >> _______________________________________________ v6ops mailing >> list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >> --=20 >> =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=3D=3D=3D=3D=3D >> Qiong Sun >> China Telecom Beijing Research Institude >>=20 >>=20 >> Open source code: >> lightweight 4over6: /http://sourceforge.net/projects/laft6// >> PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ / >> =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=3D=3D=3D=3D=3D=3D >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Tue Feb 19 04:02: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 17CD621F8889 for ; Tue, 19 Feb 2013 04:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XtLUuJSYvok for ; Tue, 19 Feb 2013 04:01:58 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id A4BF421F8806 for ; Tue, 19 Feb 2013 04:01:58 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id l10so6799746oag.2 for ; Tue, 19 Feb 2013 04:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=y7YbIhl0NlMdJ8MrScYS1v9xYhWKLYqXbdt3cWYXVXs=; b=Egn7pUqhO8ivDo9xDBIi3ujpPk3mg/QvgEicklaQhzVO2jeLPFBuO2o0Bz+1Y+ssQT gbWW72eRX4dmmJHilkLkX92m1tItt9ITFs71vhSCwIipS0ji/xzXr25ZD0g6S0x45+RK rGhxnGAorWBl8jJ5JJcSEw9JFIB8vGRTMs6F2svo4X0xEm0952P7tp21TX74J7QlNFMs wVYK1RHnvc8GZk/91KWCGzIy1iraPPXpyz/GE+ClriuKdroLR40o6t+57H64Y7JEwrH7 txlXdG9yJOiN1XT6nRZhw+SQoJobysYnVQvYs6EL1i0R+cPcF76zXCNTVzfz6PH6LVQQ Er7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=y7YbIhl0NlMdJ8MrScYS1v9xYhWKLYqXbdt3cWYXVXs=; b=TSZmxfSCxBdaWk0BwCx6n5eV02RsFOLVdzzXZ5XyWu+MmiitZHeYINXl0Pr1zpsRwC I1TRHSobETNdhUbHzIL2ubm79eh1e+qoUeaniwqssLIA3m5hOc5cGDdaq8xhYftipSR3 +NDZPOOP+Yr/kPEQcAjnAutezVbqOlDHbiA8qO1VRBfyncZNSgRX9ETbmTs8eNY3OR1w 6JZivenKAoYPSP3nufsFFh1FaKVYj2zUuILrlR05DVeorH+PR2SaX+Joziu0Roj906xO jKJrHjDHKaxZnXclYYKbbQaa/ctRrXlK/86E88YQst9Ehh/kGN022pXk2CzZKnSVUm57 6pyA== X-Received: by 10.60.170.140 with SMTP id am12mr7242694oec.125.1361275318061; Tue, 19 Feb 2013 04:01:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Tue, 19 Feb 2013 04:01:38 -0800 (PST) In-Reply-To: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> From: Lorenzo Colitti Date: Tue, 19 Feb 2013 21:01:38 +0900 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=bcaec54b4812c649d804d6129b7b X-Gm-Message-State: ALoCoQlLJK39GvNtTpITRJLePYqa3lTxmJWDu+uUd5whurbky3o8J53iWwf99lT79W9eNJXVMNoVRZri+tNXYNved0QwcjxYHhE/yh3VFPGUF6HpPjWIbkEk7XGJJJ6zcAbKDcOIl/v+fBisDZGcxVDmvqjO5ZqnMxFhbedeYMiBTSjczqqnX1QWnolmWmIT58qFu3+2F6N5 Cc: "v6ops@ietf.org WG" , draft-shishio-v6ops-dpvt@tools.ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 12:02:00 -0000 --bcaec54b4812c649d804d6129b7b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 18, 2013 at 10:45 PM, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. Please take a look > at it and comment. > Wait... this draft seems to propose a way of figuring out a node's IPv6 prefixes (i.e., part of its configuration). using unauthenticated ICMPv6 messages. How can there be "no additional security considerations"? --bcaec54b4812c649d804d6129b7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 18, 2013 at 10:45 PM, <<= a href=3D"mailto:fred@cisco.com" target=3D"_blank">fred@cisco.com> wrote:

A new draft has been posted, at http://tools.ietf.org/html/draft-shi= shio-v6ops-dpvt. Please take a look at it and comment.

Wait... this draft seems to propose a way of figuring o= ut a node's IPv6 prefixes (i.e., part of its configuration). using unau= thenticated ICMPv6 messages. How can there be "no additional security = considerations"?
--bcaec54b4812c649d804d6129b7b-- From fred@cisco.com Tue Feb 19 05:45: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 82C8A21F8B6C for ; Tue, 19 Feb 2013 05:45:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsZPVCFyzIbq for ; Tue, 19 Feb 2013 05:45:02 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 06D0F21F8C5D for ; Tue, 19 Feb 2013 05:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1361281502; x=1362491102; h=date:from:message-id:to:subject:cc; bh=YkqTKLFy8qnY+h7jdcyyxsBzSU9wxtqjCRl9RDwUJkw=; b=WoQChkDrHS+KFkqa4T8mPmlSU5kfNbzvXrj/gv6/EbDrAst/8g/A1/78 YwHW3ve134l1yrWM1BIGE2Rye341+q+K3o3AOgAIT77JhfDYSo+lWPzuj nzkKQy4U4CxbKVZ7lYBF2l1rKpGpwIFsnOsTovgC0t65qidh3PK9y9IAP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAOyAI1GrRDoJ/2dsb2JhbABFhgKofQGRNwiBCRZzgx88LQeIcg2vdpAcjw4dgyoDiGaOYo87gyg X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; d="scan'208";a="72711876" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 19 Feb 2013 13:45:01 +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 r1JDj1pQ018365; Tue, 19 Feb 2013 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r1JDj1J06940; Tue, 19 Feb 2013 05:45:01 -0800 (PST) Date: Tue, 19 Feb 2013 05:45:01 -0800 (PST) From: Message-Id: <201302191345.r1JDj1J06940@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-design-choices@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-design-choices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 13:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-design-choices. Please take a look at it and comment. From fred@cisco.com Tue Feb 19 05:45: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 88B5F21F8BF6 for ; Tue, 19 Feb 2013 05:45:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8meTpX9MhzTl for ; Tue, 19 Feb 2013 05:45:02 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 064FD21F8C53 for ; Tue, 19 Feb 2013 05:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1361281502; x=1362491102; h=date:from:message-id:to:subject:cc; bh=OjjhQvyG5qR0ggDIrxt5TPcqdprWfvAN0mNPqaVvXrA=; b=MQ5hdTyZv4Xw5D5oGZYDTWQ6ZgGli2JPI8452YctQ8aswT0s6HDn2MgL btGbepfT3Wk/AkYVXUMVSLS5PuvDkDP9k638i7AfgAj8JZ6o1ZcoVipD7 MU7M3PF++xwVqEvv4iz4kCMQ7A3PRZhVEiAm4HUHg7/7BX4J5ZsQa0MaX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAJyBI1GrRDoI/2dsb2JhbABFhgKofQGRNwiBCRZzgx88LQeIcg2vdpAcjw4dgyoDiGaOYo87gyg X-IronPort-AV: E=Sophos;i="4.84,695,1355097600"; d="scan'208";a="70135078" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 19 Feb 2013 13: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 r1JDj18I027769; Tue, 19 Feb 2013 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r1JDj1k06943; Tue, 19 Feb 2013 05:45:01 -0800 (PST) Date: Tue, 19 Feb 2013 05:45:01 -0800 (PST) From: Message-Id: <201302191345.r1JDj1k06943@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, 19 Feb 2013 13:45:03 -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 ales.vizdal@t-mobile.cz Tue Feb 19 06:08: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 4DD8E21F8CE0 for ; Tue, 19 Feb 2013 06:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DptC4McM39Z7 for ; Tue, 19 Feb 2013 06:08:55 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id D200221F8CC7 for ; Tue, 19 Feb 2013 06:08:54 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 44D28285820; Tue, 19 Feb 2013 15:08:46 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 19 Feb 2013 15:08:46 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Tue, 19 Feb 2013 15:08:04 +0100 Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: Ac4N3j0M0eA/IUTHQxW6CqEfBOtarAAzBk2Q Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> In-Reply-To: <201302181345.r1IDj0J04495@ftpeng-update.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 14:08:56 -0000 Hi, can you please bit more elaborate on the problem you're trying to solve? Cheers, Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Monday, February 18, 2013 2:45 PM > To: v6ops@ietf.org > Cc: draft-shishio-v6ops-dpvt@tools.ietf.org > Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt >=20 >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-shishio-= v6ops-dpvt. > Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Feb 19 07:03: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 90B0121F8B8B for ; Tue, 19 Feb 2013 07:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5mMk3XcKsZ1 for ; Tue, 19 Feb 2013 07:03:06 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AC4B921F880F for ; Tue, 19 Feb 2013 07:03:06 -0800 (PST) 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 r1JF30j6005581 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 15:03:01 GMT (envelope-from joelja@bogus.com) Message-ID: <5123941F.3020609@bogus.com> Date: Tue, 19 Feb 2013 07:02:55 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Owen DeLong References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> <51217464.5030507@bogus.com> <51232CA8.9070204@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 19 Feb 2013 15:03:02 +0000 (UTC) Cc: draft-sun-v6ops-semantic-usecase , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 15:03:07 -0000 On 2/18/13 11:50 PM, Owen DeLong wrote: > On Feb 18, 2013, at 11:41 PM, joel jaeggli wrote: > >> On 2/18/13 6:44 AM, Qiong wrote: >>> Hi Joel, >>> >>> Thanks for your comments. >>> >>> I agree with you semantic prefix will have limitations in real world deployment. We will improve the limitation part and clearly clarify the scope for which operators should take in the next version. >>> >> I particular I think it would be particularly undesirable but from a policy and address assignment perspective if providers were to up the size of their assignment requests using a justification of more semantic bits required. Where does that thought experiment end? > I don't think the RIR communities are likely to go along with that in terms of adopting it into policy. nor should they. > Owen > >>> In designing the use case, we do need to carefully consider the tradeoff between the benefits and complexity. That's the current use case is relatively easy to deploy and have little impact on the current infrastructure. But of course, it will be evolved to reflect more requirements and feedback from the working group. >>> >>> Thanks ! >>> >>> Best wishes >>> Qiong >>> >>> >>> On Mon, Feb 18, 2013 at 8:23 AM, joel jaeggli > wrote: >>> >>> On 2/17/13 5:45 AM, fred@cisco.com wrote: >>> >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase. >>> Please take a look at it and comment. >>> >>> I have some serious qualms about specifying something that that >>> you absolutely do not want to honor outside your own domain of >>> control. While this isn't too proscriptive both documents together >>> are headed in that direction. >>> >>> As with draft-jiang-semantic-prefix the notion that host stacks >>> might be modified to treat particular masks of bits differently >>> within applications is an especially expensive form of application >>> network aware-signaling, flies completely in the face of the >>> uniform utility of ipv6 unicast addressing. >>> >>> Generically, the utility for an operator of ascribing meaning to a >>> particular bit mask outside of the host mask is relatively >>> straight forward and consistent with all sorts of addressing plans >>> (I can for example trivially identify all the router loopback(s) >>> in my network due the the addressing scheme, likewise internal >>> site versus external site assignments and so on within given /48 >>> site assignement(s). >>> >>> I think both of these drafts can be made useful but there are >>> limits clearly to the scope in which they can be applied. >>> >>> thanks >>> joel >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >>> >>> -- >>> ============================================== >>> Qiong Sun >>> China Telecom Beijing Research Institude >>> >>> >>> Open source code: >>> lightweight 4over6: /http://sourceforge.net/projects/laft6// >>> PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ / >>> =============================================== >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From shtsuchi@cisco.com Tue Feb 19 07:40: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 4859D21F8DED for ; Tue, 19 Feb 2013 07:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOChUgwjeJ-u for ; Tue, 19 Feb 2013 07:40:28 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id EB20C21F8DD7 for ; Tue, 19 Feb 2013 07:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2123; q=dns/txt; s=iport; t=1361288428; x=1362498028; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ciFZyeoV4NKjJ3A1/RB3Mog4v6hofnF9MbkjhkbzHG4=; b=CCTGn8ZOPMdfeYWVAuYyhEu81tXVkpddSRB1F99CrhmX51ejA7iJRPD/ STnpoPNufYVBDbJvc89x0pMB1OapIVEK6Y3LvL0IK9IJp7sw20cEs990V b5mThwAuwKZ6VE1+QpgIHOcj4/kBFi4/WXfPlAEvH1I0LNvidhu7Sq8ML M=; X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="25718891" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 19 Feb 2013 15:40:22 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1JFeLcB005047; Tue, 19 Feb 2013 15:40:21 GMT Message-ID: <51239CE3.2070807@cisco.com> Date: Wed, 20 Feb 2013 00:40:19 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: fred@cisco.com References: <201302181345.r1IDj0i04498@ftpeng-update.cisco.com> In-Reply-To: <201302181345.r1IDj0i04498@ftpeng-update.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, draft-shishio-v6ops-dpvt@tools.ietf.org Subject: Re: [v6ops] Some questions on draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 15:40:29 -0000 Fred (2013/02/18 22:45), fred@cisco.com wrote: > Let me ask some questions. This is not intended to put you off or offend, but to help the chairs in understanding where the draft fits in the big scheme of things. Yes, I understand. > > 1) Please provide a succinct problem statement for your draft. What problem/issue is this draft discussing? What operational problems does the proposal address in real life networks? I should define problem statement more clearly. The stateless tunnel and prefix delegation technology provides much scalability network to the customer. On one hand, these technologies are difficult to plan additional capacity and hard to know current deployment status unless the devices are completely managed. If the BR has state and DHCPv6 server knows detail route,then the merit of these technologies would be disappeared. So I thought these technologies need small oam tools. > > 2) Where does this draft or presentation fits into v6ops' current charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s) of the charter is preferable. I thought this is operational issue. > > 3) Who is this draft's audience? I think v6ops wg. > > 4) Have any operators expressed interest in this draft or its problem space, either via review or other discussion? > Some ISP expressed interest in 1) problem statement. But the people does not reviewed my draft yet. > 5) Is this draft pursuing discussion in any other WGs? If so, please list them here, along with rationale for the interaction with multiple WGs in parallel. I would like to talk in opsawg,too. > > 6) Is any protocol work being recommended in the draft? > > the criteria the WG asked me to apply for new work or presentation slots are: > - recent or recently updated draft > - within charter > - results in constructive discussion on the mailing list > > I need for you to provoke discussion on the list. You may respond to my opening email to do so if it's helpful. > . I would like to get opinion on mailing list. Regards, -Shishio From shtsuchi@cisco.com Tue Feb 19 07:40: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 C69B621F8DF4 for ; Tue, 19 Feb 2013 07:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm4PWp83sR2o for ; Tue, 19 Feb 2013 07:40:56 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 75A0321F8DC6 for ; Tue, 19 Feb 2013 07:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1106; q=dns/txt; s=iport; t=1361288455; x=1362498055; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kng9bowpTw3n5GT3t4x70QSeoNtU6w+vLtQ4MTIa3/c=; b=hjZ0N+zNS95t0NW/OFtAJEvujbKWA/sbRActqoot+rar8r8P/tSRqEws P/JjfwGtH2NWDSgsQNPjpd6QlodSYGGu8G04Ywwzs8f6Y8FqU71zTU3IK pAnmp8Hjr2ts3O4ACWdtQ2HBSipzq7jT9zfvV4qIrQgkuBW0kJHBAfsZn M=; X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="25718906" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 19 Feb 2013 15:40:53 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1JFeqTm020558; Tue, 19 Feb 2013 15:40:53 GMT Message-ID: <51239D04.3080109@cisco.com> Date: Wed, 20 Feb 2013 00:40:52 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: lorenzo@google.com References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-shishio-v6ops-dpvt@tools.ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 15:40:56 -0000 Lorenzo (2013/02/19 21:01), Lorenzo Colitti wrote: > On Mon, Feb 18, 2013 at 10:45 PM, > wrote: > > > A new draft has been posted, at http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. Please take a look at it and comment. > > > Wait... this draft seems to propose a way of figuring out a node's IPv6 prefixes (i.e., part of its configuration). using unauthenticated ICMPv6 messages. How can there be "no additional security considerations"? Indeed. I should modify this section . The message should only accept from authorized node(like 6PE BR and DHCPv6 server). And I will replace "Delegated Prefix(128bit): the delegate prefix which is the operators would like to know.If the field be zero,it means all of inteface address are requested." to "Delegated Prefix(128bit): the delegate prefix which is the operators would like to know." Regards, -Shishio > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shtsuchi@cisco.com Tue Feb 19 07:41: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 2545721F8DFC for ; Tue, 19 Feb 2013 07:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS2Kd9brBIWL for ; Tue, 19 Feb 2013 07:41:01 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id C3F4721F8DFD for ; Tue, 19 Feb 2013 07:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1402; q=dns/txt; s=iport; t=1361288461; x=1362498061; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2xkAWiMkrP90WTf1s3yGWWDq/CN11lj3kZcU7on0ZhE=; b=AEZCmJC5MUpPr9LFX3dZpXmiMHFRueVvsl0fcVGVF529J1MsG8a8DpCV Ef2I4OK0hm/PwbNDjlvYa2JjnPEyOE3zTrvOVPqkgkP9FR74uNIkD/DnO BRiQfA+BlMeAeJKjW06RTnnyJuqT248sk0YK2sfX1ADcSkZmxlkAstK12 0=; X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="25714381" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 19 Feb 2013 15:40:59 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1JFew0d028871; Tue, 19 Feb 2013 15:40:58 GMT Message-ID: <51239D09.10305@cisco.com> Date: Wed, 20 Feb 2013 00:40:57 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ales.vizdal@t-mobile.cz References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, draft-shishio-v6ops-dpvt@tools.ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 15:41:02 -0000 Ales Thank for your interest. As I described reply to Fred, The stateless tunnel and prefix delegation technology provides much scalability network to the customer. On one hand, these technologies are difficult to plan additional capacity and hard to know current deployment status unless the devices are completely managed. If the BR has state and DHCPv6 server knows detail route,then the merit of these technologies would be disappeared. So I thought these technologies need small oam tools. -confirm only interface configuration from ISP side -confirm reachability not use end to end I would appreciate any comment. Regards, -Shishio (2013/02/19 23:08), Vízdal Aleš wrote: > Hi, > > can you please bit more elaborate on the problem you're trying to solve? > > Cheers, > Ales > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> fred@cisco.com >> Sent: Monday, February 18, 2013 2:45 PM >> To: v6ops@ietf.org >> Cc: draft-shishio-v6ops-dpvt@tools.ietf.org >> Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt >> >> >> A new draft has been posted, at http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. >> Please take a look at it and comment. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From farinacci@gmail.com Tue Feb 19 09:12: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 A672F21F8E51; Tue, 19 Feb 2013 09:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJU7xiWNghw4; Tue, 19 Feb 2013 09:12:15 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8621F8E4D; Tue, 19 Feb 2013 09:12:15 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so3028067dak.2 for ; Tue, 19 Feb 2013 09:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=o6iW554eLUEcxZMQcTbR8gs5S3LSPazHGYvdFamiAl4=; b=AO/tnfO+5NY4ARvuGkFxmvYmpFdUawB5E5jh6wwTDJv6btxSsghAD50lqcLEoxAMTB OzIpel/q8C+9u3zqGA+8/kV8rf++STX4MIqj8+ycd/Thl/cv84xrrA3ONv1ImGoEGpr7 09E4Wxo8dsHu+TMe8ezWXbh/vUjDIA5dUPDJnsAg1mV/HRAxwwMnO+VwUUBu859xyAes xigOQvHXAaz63kXAqDaFTSyqLXeXggrAmfuOK4afEJfXLXsUZS+OACQk2FOqUlSKFWFL Gpd+2SJJpUMd8haqZ7FUjE0crxbgTcsMxqT4BDfVHdKMpEOJVJUfDpjo2YzkFbIb1upP 5quw== X-Received: by 10.68.42.9 with SMTP id j9mr42541794pbl.142.1361293935233; Tue, 19 Feb 2013 09:12:15 -0800 (PST) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPS id d1sm108027787pav.6.2013.02.19.09.12.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 09:12:14 -0800 (PST) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Feb 2013 09:12:11 -0800 Message-Id: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> To: "Martin J. Levy" , mpounsett@afilias.info Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org, "lisp@ietf.org list list" Subject: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 17:12:16 -0000 Sorry I am late on this thread. I just joined the list and read the = discussion on this draft. Here are my comments from a LISP perspective. = I am cross posting to the LISP WG mailing list. Your draft text comes first indented and my comments follow. > Network Working Group M. = Levy > Internet-Draft Hurricane = Electric > Intended status: Informational M. = Pounsett > Expires: July 28, 2013 = Afilias > January 24, = 2013 >=20 >=20 > A mechanism to allocate IPv6 blocks for BGP networks based on the > networks AS Number > draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt We have been discussing in the LISP WG the allocation of a coarse IPv6 = prefix for the use of Provider Independent EID prefixes. > Abstract >=20 > This document provides a methodology for automatically allocating > IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] = and > are either single-homed or multi-homed [BARBER2011]. The automatic > allocation is taken from a specific /16 block assigned by IANA for > this purpose. >=20 > Networks that require more than this single /48 can still request > additional allocations via the existing RIR process. Networks are > not forced to use this allocation and can ignore this completely. > Availability of the /48 assignment via this mechanism does not = change > existing mechanisms for obtaining IPv6 assignments through the > existing RIR (Regional Internet Registry) or LIR (Local Internet > Registry) mechanisms. This is a good idea PROVIDED these prefixes are not injected into the = core routing system. > 1. Introduction >=20 > IPv6's massive address space provides a wonderful opportunity to > radically change the process of IP address allocation. Presently > IPv6 allocation is the same process as used by the IPv4 world. The > RIRs allocate IPv6 address blocks based on member requests and = their > space requirements. A minimum allocation of a /48 is believed to = be > sufficient to start any enterprise in the world of IPv6. Or a small set of devices that plan to be mobile. Where they do not want = to reallocate addresses when they move. > 2. Defining the /48 address >=20 > The /48 address is allocated using a fixed pattern. >=20 >=20 > ASN-based address assignment > +----------+--------------------+-----------------/ /------------+ > | IANA /16 | 32 bit ASN | 80 bits for IPv6 /48 space | > +----------+--------------------+-----------------/ /------------+ This is similar in concept to the GLOP space we allocated for IPv4 = multicast addresses. What we said is that anyone could join a group with = a ASN-based address. That is, they did not have to own it. Can the authors tell me if someone who owns such a prefix, will they be = allowed to use and reallocate for any general purpose to other = entities/organizations? > The sum of the bits in the IANA allocated /16 prefix plus the 32 = bits > of the ASN plus the /48 of user defined usage adds up to 128 bits. >=20 > +------+----------------------+ > | Bits | Usage | > +------+----------------------+ > | 16 | IANA provided prefix | > | 32 | ASN | > | 80 | User defined | > | 128 | TOTAL | > +------+----------------------+ >=20 > Table 1: Address space math Can there be some ASN values assigned to signify "no one owns the /48"? = So we can have even more independent assignments. For the purposes of = LISP, we don't care if these address don't perfect aggregate because = these addresses will go into the LISP mapping database system which may = not need to aggregate since the RLOCs associated with the prefixes will = be different anyways (and therefore can't aggregate or compress). > The end network can allocate out of the assigned /48 as needed. It > is assumed that the end network will use this allocation for global > routing; however the network may choose to not announce this > allocation. Okay, so lets use an example to see how this can be used. Let's say a = /80 comes out of Verizon's space: (1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and Ford = so they can use Vehicle ID Numbers for the rest of the allocation for = their automobile EID assignments? (2) Or do the RIRs believe they need to assign a /48 with distinct ASNs = to each of BMW, Mercedes and Ford so they have more bits to embed VIN = numbers? (3) What if these auto manufactures don't want to allocate ASN numbers = because they will never have any intent to run BGP either in the cars, = POPs, data centers? > If any route is announced from this allocation, any prefixes more > specific than the allocated /48 must not be propagated in to the > global IPv6 routing table. This is to prevent the IPv6 routing = table This is fine authors, but if you are multi-home, it will require each = system at the site to possess multiple addresses one from each attached = ASN if they do not have their own prefix but get it out of their = provider. If you say that this prefix will never be associated with a provider's = attachment point, then I'm okay with that and agree. > from becoming too large. Therefore, a site which uses this > allocation MUST NOT advertise a more specific than the allocated = /48 > routing prefix. All native IPv6 network operators MUST filter out >=20 >=20 >=20 > Levy & Pounsett Expires July 28, 2013 [Page = 3] > Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >=20 >=20 > and discard any routing prefix advertisements longer than /48 from > within this /16 allocation. Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. > 3. IANA allocated /16 >=20 > IANA is to allocate a /16 in a similar manner to the 2002::/16 > allocation for 6to4 [RFC3068] which is used by the 6to4 > protocol[RFC3056].. No IPv4 allocation by IANA is required. But in this case there is no implicit assumption about mapping to = anything else with a bit-by-bit algorithm but rather an advertisement or = another network-based mapping data structure. Correct? > ASNs are normally expressed as human-readable decimal numbers; yet > for this allocation the number should be converted into a = hexadecimal > notation. All IPv6 addresses are written in hexadecimal. (NNNN > represents the /16 allocation by IANA) >=20 > +----------------+--------------------+---------------------+ > | ASN in decemal | ASN in hexadecimal | Sample IP block | > +----------------+--------------------+---------------------+ > | AS1 | 1 | NNNN:0000:0001::/48 | > | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | > | AS29001 | 7149 | NNNN:0000:0001::/48 | > | AS393220 | 60004 | NNNN:0006:0004::/48 | > +----------------+--------------------+---------------------+ What we had found in the old days of NSAP deployment (OSI) that encoding = IPv4 addresses in BCD format in a hexadecimal longer address was = extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. Rather than having to build tools and make vendors do UI work, can we = have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. > 5. ASN allocation >=20 > ASNs are allocated by RIRs and this RFC does not handle that arena. >=20 > ASNs defined as private ASNs MUST NOT use this scheme. The special > 16-bit ASN 23456 MUST NOT use this scheme. I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. > 6. BGP Filtering and Validation >=20 > Filtering would be a simple case of mapping the final ASN in a path > to the prefix in an exact bit-order match. >=20 > For example; the prefix NNNN:0000:1B1B::/48 should only be seen as > announced from AS6939 (6939 equals 0x1B1B in hex). Networks would > have their upstream transit providers add this /48 prefix to their > existing inbound BGP route filters. IMO, these addresses should stay out of underlying routing. If you want = to build a mobile Internet for IPv6, these sort of addresses are = identity addresses and not topological. Let's not perpetuate the non-sense of the past. > 10. Routing Table Impact >=20 > This mechanism is not expected to have any impact to the global > Internet routing table since existing policies in the RIR system > already readily provide for the allocation of provider-independent > IPv6 prefixes. Additionally, AS number holders are likely to be > multihomed entities which were going to be independently routed in > any case. Service Providers are, as always, not obligated to route > these IPv6 assignments and/or may establish conditions of service > which offset any additional routing cost. I would say it would have the same impact as PI prefixes do today. > 14.2. Informative References You may, not sure, but may want to add these as possible informative = references: draft-ietf-lisp-eid-block draft-iannone-lisp-eid-block-mgmnt > Martin J. Levy > Matthew Pounsett Thanks for coming out with this, Dino From nick@inex.ie Tue Feb 19 10:07: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 77F9321F8E59; Tue, 19 Feb 2013 10:07:07 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5He936JEkJE4; Tue, 19 Feb 2013 10:07:06 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5267821F8E4C; Tue, 19 Feb 2013 10:07:04 -0800 (PST) X-Envelope-To: lisp@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1JI4IIM036666 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 18:04:18 GMT (envelope-from nick@inex.ie) Message-ID: <5123BF44.9020302@inex.ie> Date: Tue, 19 Feb 2013 18:07:00 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dino Farinacci References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> In-Reply-To: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 18:07:14 -0000 On 19/02/2013 17:12, Dino Farinacci wrote: >> not forced to use this allocation and can ignore this completely. >> Availability of the /48 assignment via this mechanism does not change >> existing mechanisms for obtaining IPv6 assignments through the >> existing RIR (Regional Internet Registry) or LIR (Local Internet >> Registry) mechanisms. > > This is a good idea PROVIDED these prefixes are not injected into the > core routing system. I don't think that this is a realistic expectation. If people get blocks of this form, they will turn up in the dfz for sure. Nick From owen@delong.com Tue Feb 19 11:25: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 4A57F21F8E82 for ; Tue, 19 Feb 2013 11:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rTsnTa6hqvf for ; Tue, 19 Feb 2013 11:25:46 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3896621F8E7B for ; Tue, 19 Feb 2013 11:25:45 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1JJLBoK014910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2013 11:21:12 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1JJLBoK014910 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361301674; bh=WjcuwlJvOeoccE+rSBtsrZ4MXSc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=a2MOO3+CezIpOgm365M55TQFdwMSZ+h2BKfa0CZ8EEIOp9UTPyRgKLRJGCYWG7+cB nw87HPOWDjeMuQlVhVmFDyiWGjfE1yAFDUi9pRBzQCBwvBHno50mGz7qM+ZgMBQ/TO 9WtKcK0Hoxmc13/0PtIlcITsXccIhYvxdUI20UYw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51239D09.10305@cisco.com> Date: Tue, 19 Feb 2013 11:21:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> To: Shishio Tsuchiya X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 19 Feb 2013 11:21:14 -0800 (PST) Cc: v6ops@ietf.org, draft-shishio-v6ops-dpvt@tools.ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 19:25:47 -0000 I'm sorry, but I still do not understand the need for this technology. In the current case: The operator's system delegates a prefix to the subscriber. The operator has no need for visibility into the subscriber's = network. The subscriber's equipment can break up the delegated prefix at = will. The operator only needs to deliver packets to the subscriber = through the device which requested and received the delegation. What problem is solved by giving the operator additional visibility into = the subscriber's network and why would this be desirable? =46rom the subscriber perspective, I think this is a breech of security = as it discloses information about the structure of my network without my consent.(Even if that disclosure is limited to the provider which delegated the prefix.) =46rom the provider perspective, I don't see the advantage to being able = to gather this information. Perhaps it would help if you could answer the following questions: 1. What is the advantage to the provider from knowing the = subscriber's router interface configuration? 2. What if the router has delegated component prefixes to other routers? Additionally, I think that there are security considerations and merely restricting the permitted sources of these queries does not adequately address them. Owen On Feb 19, 2013, at 7:40 AM, Shishio Tsuchiya = wrote: > Ales > Thank for your interest. > As I described reply to Fred, > The stateless tunnel and prefix delegation technology provides much = scalability network to the customer. > On one hand, these technologies are difficult to plan additional = capacity and hard to know current deployment > status unless the devices are completely managed. > If the BR has state and DHCPv6 server knows detail route,then the = merit of these technologies would be disappeared. >=20 > So I thought these technologies need small oam tools. >=20 > -confirm only interface configuration from ISP side > -confirm reachability not use end to end >=20 > I would appreciate any comment. >=20 > Regards, > -Shishio >=20 >=20 >=20 > (2013/02/19 23:08), V=EDzdal Ale=9A wrote: >> Hi, >>=20 >> can you please bit more elaborate on the problem you're trying to = solve? >>=20 >> Cheers, >> Ales >>=20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >>> fred@cisco.com >>> Sent: Monday, February 18, 2013 2:45 PM >>> To: v6ops@ietf.org >>> Cc: draft-shishio-v6ops-dpvt@tools.ietf.org >>> Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt >>>=20 >>>=20 >>> A new draft has been posted, at = http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. >>> Please take a look at it and comment. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Tue Feb 19 11:42: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 7D7E321F8A25 for ; Tue, 19 Feb 2013 11:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdPuOpIMKOfj for ; Tue, 19 Feb 2013 11:42:39 -0800 (PST) Received: from nm32-vm2.bullet.mail.bf1.yahoo.com (nm32-vm2.bullet.mail.bf1.yahoo.com [72.30.239.138]) by ietfa.amsl.com (Postfix) with ESMTP id A344721F8996 for ; Tue, 19 Feb 2013 11:42:39 -0800 (PST) Received: from [98.139.212.144] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 19:42:38 -0000 Received: from [98.139.212.241] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 19:42:38 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 19:42:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 867058.58482.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 48417 invoked by uid 60001); 19 Feb 2013 19:42:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361302958; bh=cnifSzqAlM1r5iIbzoCKIVuHqITXDylS1rZyWhx74Jo=; 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=MWqQDZquXF6M4UssdvM6X30l1jyITq07qj53axptl5Nwo3xf4NnxBZlvNhcsMb0V2cJUFTsRYjnOkrIkyUUKCpVBowUJJxEh7ou+iG/hXAfcLKJ5/AOTfWAoPFVlzZ0LkHvjRH+oE1VZHMfgpyVoCpQPE73pJrhMg7sbS1pDtBI= 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=SPUMOvMzJ+UX8Bv9nCVdIOSJvDT7/cVMMbvqI/6yOXpOQRZYGiL/uzFCkQBBLVL66hssLcaMyXpVYRYdU6ceze3ona+7BrNj5XOD/8sMFxZVEg0/4kAGZg7iZQPh4/xDeLqHMjSkw9JfgwtH4FWzM1qyy/SzNolWZ92GampG+48=; X-YMail-OSG: 1nXl4xcVM1l6y81NVIFwoyRAZFn.U_b_Kyz7ZO7U9X5M5_t MegtRYBlyMPc5ZatawyN.iyJaJQFXlCxICPwZfvL_ws7bxOtn94d9xgGJmnN lLFmn.GA0DinGMngh5AatXrNU2Coux_IP82xbx8D0A4YhsZERCT7fPaGuATR uYifh99mkIJb48ngOx0369zPezEA8JOf6aSQyb5iTS1YWz101RSML4Dl3kLC Bqy8nKqZaTqfr00kXo4a6o5kJB9i9oZzb63gjYfoO.5qjYjkY6HgwpWxbqIS JNk0mJjZGYb5cC6ZodHjqfHmY8stqBwAf1wUpBaHSVY8YSSsA5sF6406aISL P31evlyO7GVzGy6Fpt6sRwDhWzdkv2b3dNxMUsuP9ZXCYdIfCwdEaAAeh5HY Um8_1yn1ymczc3_u23ArGTvOfn5Bc.AhNgUAre_Bgs5roGxlIQbNVHr6QRmV ePitBuEIvCkUXZuMq5Cbqy4l81vO.bQNH6qbWm7NbuqP07e3nBYlsNOgkFm7 Iqmw_XzyBSI5liALGGaNBvkUm Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Tue, 19 Feb 2013 11:42:38 PST X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206ICJmcmVkQGNpc2NvLmNvbSIgPGZyZWRAY2lzY28uY29tPgo.IFRvOiB2Nm9wc0BpZXRmLm9yZwo.IENjOiBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzQHRvb2xzLmlldGYub3JnCj4gU2VudDogV2VkbmVzZGF5LCAyMCBGZWJydWFyeSAyMDEzIDEyOjQ1IEFNCj4gU3ViamVjdDogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMKPiAKPiAKPiBBIG5ldyBkcmFmdCBoYXMgYmVlbiBwb3MBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <201302191345.r1JDj1J06940@ftpeng-update.cisco.com> Message-ID: <1361302958.46753.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Tue, 19 Feb 2013 11:42:38 -0800 (PST) From: Mark Smith To: "v6ops@ietf.org" In-Reply-To: <201302191345.r1JDj1J06940@ftpeng-update.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-v6ops-design-choices@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-design-choices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:42:40 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: "fred@cisco.com" =0A> To: v6ops@ietf.org=0A> Cc: draft-ietf-v6ops-design-choices@to= ols.ietf.org=0A> Sent: Wednesday, 20 February 2013 12:45 AM=0A> Subject: [v= 6ops] new draft: draft-ietf-v6ops-design-choices=0A> =0A> =0A> A new draft = has been posted, at =0A> http://tools.ietf.org/html/draft-ietf-v6ops-design= -choices. Please take a look =0A> at it and comment.=0A> _=0A=0A=0AThis dra= ft only covers unicast, however I think it would be useful to also cover an= ycast and multicast as they have been "baked in" to IPv6 from day one, and = therefore they're ubiquitous capabilities.=0A=0ARegarding anycast, IPv6 any= cast is different from IPv4's, as in IPv6 it is also possible to anycast wi= thin the subnets on the link, rather than requiring packets to enter the ro= uting/forwarding domain. This may have increased it's utility e.g. for some= applications, link level anycast might be more useful than link level mult= icast. One application I can think of might be NTP servers on the link - th= e NTP servers have anycast addresses, and anycast is used to pick one of th= em, rather than having them all issue multicasts.=A0Architectural Considera= tions of IP Anycast (draft-iab-anycast-arch-implications) and=A0Operation o= f Anycast Services (RFC4786) would be useful references. RFC4786 seems to b= e limited to the "anycast implemented using the routing domain" scenario, s= o this draft would be an opportunity to add to that by also focussing on us= es and advice on IPv6 anycast implemented within the link/subnet.=0A=0ARega= rding multicast, I think the common view might be that it is only useful fo= r end-user applications, and therefore isn't useful or necessary to enable = until a network needs to support one. However, I think multicast can be use= ful to a network operator, with an example being DHCPv6 relays using multic= ast to reach a distributed set of DHCPv6 servers. Another example I have he= ard of is the use of multicast to distribute Netflow/IPFix information to m= ultiple collectors. As syslog is typically carried within UDP, using multic= ast to replicate it for redundancy to distributed syslog servers could be a= nother use of interest to a network designer. Stepping back, the common req= uirements that multicast can satisfy for a network designer are duplication= of packets/data and geographic diversity, for availability.=0A=0ARegards,= =0AMark. From owen@delong.com Tue Feb 19 12:36: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 3AD6221F87B6; Tue, 19 Feb 2013 12:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.795 X-Spam-Level: * X-Spam-Status: No, score=1.795 tagged_above=-999 required=5 tests=[AWL=-3.206, BAYES_50=0.001, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAHgGT4blDuV; Tue, 19 Feb 2013 12:36:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B349421F8860; Tue, 19 Feb 2013 12:36:05 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1JKYwuM019292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2013 12:34:58 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1JKYwuM019292 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361306099; bh=HoH4sGiMxvkVaMjcNSSfZefX+fI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iUCtZwR+7XEcdZM4VNalRwEYY0BRtjpmS8xiNWZViSq7vpUFE35Uk4cQfKX94Rxlt kIjD1i489hEcZvnG22/1CKG6NY+MwEjsdTl/on3UI4bAj1xy0Ko5azF0J0/Q1aZhXy zqtCAlSlpWdJHmRx/t6lv2uKbZQssPOfROqfichQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> Date: Tue, 19 Feb 2013 12:34:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 19 Feb 2013 12:34:59 -0800 (PST) Cc: "Martin J. Levy" , v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 20:36:09 -0000 >> Abstract >>=20 >> This document provides a methodology for automatically allocating >> IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] = and >> are either single-homed or multi-homed [BARBER2011]. The automatic >> allocation is taken from a specific /16 block assigned by IANA for >> this purpose. >>=20 >> Networks that require more than this single /48 can still request >> additional allocations via the existing RIR process. Networks are >> not forced to use this allocation and can ignore this completely. >> Availability of the /48 assignment via this mechanism does not = change >> existing mechanisms for obtaining IPv6 assignments through the >> existing RIR (Regional Internet Registry) or LIR (Local Internet >> Registry) mechanisms. >=20 > This is a good idea PROVIDED these prefixes are not injected into the = core routing system. >=20 The prefixes should not be automatically injected, but I think = prohibiting such injection would decrease the utility of this addressing and that there = is no good reason to have such a prohibition. >> The sum of the bits in the IANA allocated /16 prefix plus the 32 = bits >> of the ASN plus the /48 of user defined usage adds up to 128 bits. >>=20 >> +------+----------------------+ >> | Bits | Usage | >> +------+----------------------+ >> | 16 | IANA provided prefix | >> | 32 | ASN | >> | 80 | User defined | >> | 128 | TOTAL | >> +------+----------------------+ >>=20 >> Table 1: Address space math >=20 > Can there be some ASN values assigned to signify "no one owns the = /48"? So we can have even more independent assignments. For the purposes = of LISP, we don't care if these address don't perfect aggregate because = these addresses will go into the LISP mapping database system which may = not need to aggregate since the RLOCs associated with the prefixes will = be different anyways (and therefore can't aggregate or compress). Wouldn't the private ASN range already effectively do this? >> The end network can allocate out of the assigned /48 as needed. It >> is assumed that the end network will use this allocation for global >> routing; however the network may choose to not announce this >> allocation. >=20 > Okay, so lets use an example to see how this can be used. Let's say a = /80 comes out of Verizon's space: >=20 > (1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and Ford = so they can use Vehicle ID Numbers for the rest of the allocation for = their automobile EID assignments? >=20 First of all, you can't pull a /64 out of a /80 so I think you mean a = /48 assigned to $PROVIDER. In that case, I see no reason $AUTO_MAKER1, $AUTO_MAKER2, etc. could not = receive /64s from $PROVIDER for that purpose, but, I would propose that = such use is not a very good idea from the auto maker's perspective. Once = you embed one of these addresses into an automobile and sell it, you are = locked into a contract with Verizon until you can readdress all such = cars. > (2) Or do the RIRs believe they need to assign a /48 with distinct = ASNs to each of BMW, Mercedes and Ford so they have more bits to embed = VIN numbers? I don't believe that the RIRs are involved in the addresses contemplated = under this draft. I think permanently assigned addresses related to VINS are, in general, = a bad idea. I don't see any advantage to tying the semantics of the two = systems to each other. If anything, the development of LISP is the = result of failing to separate the semantics of end-point addressing from = the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. > (3) What if these auto manufactures don't want to allocate ASN numbers = because they will never have any intent to run BGP either in the cars, = POPs, data centers? >=20 I don't see anything in this draft that would preclude them from using a = different source of addressing. I confess, to some extent, I wonder if this is a solution in search of a = problem. >> If any route is announced from this allocation, any prefixes more >> specific than the allocated /48 must not be propagated in to the >> global IPv6 routing table. This is to prevent the IPv6 routing = table >=20 > This is fine authors, but if you are multi-home, it will require each = system at the site to possess multiple addresses one from each attached = ASN if they do not have their own prefix but get it out of their = provider. >=20 > If you say that this prefix will never be associated with a provider's = attachment point, then I'm okay with that and agree. >=20 Either I misunderstand what you are saying, or, you have erred. I'm not = sure which. If a site uses a /64 from within this /48 to attach to each upstream, = the more specific does not need to propagate beyond the immediate = upstream router, so it still wouldn't be announced into the global = routing table. >> from becoming too large. Therefore, a site which uses this >> allocation MUST NOT advertise a more specific than the allocated = /48 >> routing prefix. All native IPv6 network operators MUST filter out >>=20 >>=20 >>=20 >> Levy & Pounsett Expires July 28, 2013 [Page = 3] >> Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >>=20 >>=20 >> and discard any routing prefix advertisements longer than /48 from >> within this /16 allocation. >=20 > Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. >=20 I think that is inherent in the definition of the prefix. Can you = clarify why you think this statement is necessary? >> ASNs are normally expressed as human-readable decimal numbers; yet >> for this allocation the number should be converted into a = hexadecimal >> notation. All IPv6 addresses are written in hexadecimal. (NNNN >> represents the /16 allocation by IANA) >>=20 >> +----------------+--------------------+---------------------+ >> | ASN in decemal | ASN in hexadecimal | Sample IP block | >> +----------------+--------------------+---------------------+ >> | AS1 | 1 | NNNN:0000:0001::/48 | >> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >> | AS29001 | 7149 | NNNN:0000:0001::/48 | >> | AS393220 | 60004 | NNNN:0006:0004::/48 | >> +----------------+--------------------+---------------------+ >=20 > What we had found in the old days of NSAP deployment (OSI) that = encoding IPv4 addresses in BCD format in a hexadecimal longer address = was extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. >=20 > Rather than having to build tools and make vendors do UI work, can we = have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. I would oppose doing this. If we are going to do this (and I'm not = entirely convinced that we should, but also not opposed), we should = support the full ASN space and doing so as a bit field is fine. I don't = think any UI work is required. Tools to convert 32-bit numbers from = decimal to hex are already widely available and the process is well = understood. It's not like anyone will have to do this conversion on a = daily basis. perl -e 'printf "%08x\n", ' will solve the = problem, for example. >=20 >> 5. ASN allocation >>=20 >> ASNs are allocated by RIRs and this RFC does not handle that arena. >>=20 >> ASNs defined as private ASNs MUST NOT use this scheme. The special >> 16-bit ASN 23456 MUST NOT use this scheme. >=20 > I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. What local/global bit? Institution of a local/global bit would require a /15 instead of a /16. = I'm not convinced that this is worthy of 1/65536 of the IPv6 address = space, let alone 1/32768. >> 6. BGP Filtering and Validation >>=20 >> Filtering would be a simple case of mapping the final ASN in a path >> to the prefix in an exact bit-order match. >>=20 >> For example; the prefix NNNN:0000:1B1B::/48 should only be seen as >> announced from AS6939 (6939 equals 0x1B1B in hex). Networks would >> have their upstream transit providers add this /48 prefix to their >> existing inbound BGP route filters. >=20 > IMO, these addresses should stay out of underlying routing. If you = want to build a mobile Internet for IPv6, these sort of addresses are = identity addresses and not topological. >=20 > Let's not perpetuate the non-sense of the past. >=20 I don't see any reason to limit these addresses to that single use case. For example, assume an SMB organization that just wants to use these = addresses for general multi homed connectivity. In this case, they would = only need to obtain an ASN. They would not need to apply for a prefix, = they could simply advertise this one. >> 10. Routing Table Impact >>=20 >> This mechanism is not expected to have any impact to the global >> Internet routing table since existing policies in the RIR system >> already readily provide for the allocation of provider-independent >> IPv6 prefixes. Additionally, AS number holders are likely to be >> multihomed entities which were going to be independently routed in >> any case. Service Providers are, as always, not obligated to route >> these IPv6 assignments and/or may establish conditions of service >> which offset any additional routing cost. >=20 > I would say it would have the same impact as PI prefixes do today. >=20 Which means that this has no impact because it doesn't change the impact = vs. the current PI impact. Owen From v6ops@wjcerveny.com Tue Feb 19 14:28: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 0F55921F8790 for ; Tue, 19 Feb 2013 14:28:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k41oyMgO9plk for ; Tue, 19 Feb 2013 14:28:41 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 64D7821F879D for ; Tue, 19 Feb 2013 14:28:40 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E7A1320A6B for ; Tue, 19 Feb 2013 17:28:39 -0500 (EST) Received: from web5.nyi.mail.srv.osa ([10.202.2.215]) by compute1.internal (MEProxy); Tue, 19 Feb 2013 17:28:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=Zzwv/6N6tb6pTHEQSYQuZamETL8=; b=p2Xaj7Vg3t7yNiNneNEZJdbq1Usc AIdy1t91Kxdft4kowHI/dqq30Xyic5OhTgUTo2ZllrrOiU42e0f09XHZmjptC3bS 2Aky+B78lTP/wjuYEXtPmEk5ckba7VCsX1ZouGkZ5hyJkymCjti0BqVVEqq4laEZ P58RCmKWg1MUIzE= Received: by web5.nyi.mail.srv.osa (Postfix, from userid 99) id BB9274C00CD; Tue, 19 Feb 2013 17:28:39 -0500 (EST) Message-Id: <1361312919.12066.140661193932333.05275018@webmail.messagingengine.com> X-Sasl-Enc: p5MrdEQLWZB5tgVd2BPTXIOo0A1G08+FyF//CmnZgUtD 1361312919 From: William Cerveny To: v6ops@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efb93dc9 Date: Tue, 19 Feb 2013 17:28:39 -0500 X-Mailman-Approved-At: Tue, 19 Feb 2013 14:52:42 -0800 Subject: [v6ops] Benchmarking Neighbor Discovery Problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 22:29:59 -0000 X-List-Received-Date: Tue, 19 Feb 2013 22:29:59 -0000 [Posting to bmwg and v6ops] At the IETF 85 BMWG meeting, Ron Bonica suggested a draft on neighbor discovery benchmarking, highlighting on the problems discussed in RFC 6583, =E2=80=9COperational Neighbor Discovery Problems.=E2=80=9D I=E2=80=99= ve completed a draft, but missed the submission deadline by an hour. Al Morton, the BMWG chair, suggested I post the draft elsewhere, and submit the draft when submissions have reopened March 11. For now, the draft can be found at: http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.txt http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.html http://21st-century-networks.org/draft-cerveny-bmwg-ipv6-nd.pdf Abstract This document is a benchmarking instantiation of RFC 6583: =E2=80=9COperati= onal Neighbor Discovery Problems=E2=80=9D. It describes a general testing proced= ure and measurements that can be performed to evaluate how the problems described in RFC 6583 may impact the functionality or performance of intermediate nodes. As always, I=E2=80=99m interested in suggestions and comments. Regards, Bill Cerveny From farinacci@gmail.com Tue Feb 19 15:02: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 542A221F8942; Tue, 19 Feb 2013 15:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.001 X-Spam-Level: **** X-Spam-Status: No, score=4.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyYm8wnNI6gT; Tue, 19 Feb 2013 15:02:38 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 706D921F893D; Tue, 19 Feb 2013 15:02:38 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so2487241pbc.24 for ; Tue, 19 Feb 2013 15:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=GqmU1V+EzYe9PISJOF7Uze+OwHcWGvwl4GMlqMNJg18=; b=vzsT7En1K9Vh4yKyTH9P8u6wcBhvq0RGwUqsynHFgZ6WnIaX8j2fSfMK8ctXdpBflj hkudR0ajbjn1b0CMvpzg+6DT+J+oDnT8bxxtzhiR4ys1YZjE3RFaGdPEn48wUcRmEGq0 ogULFefqOYDV+lVhdxGWk6VVZWiDU0l0cxFIjAHfSVwGtLc/bUS78K3so22GeJjLjn/U VzaKErEh7ERzWDvDM49dSLhiJ1k902OZUDV8vEOKgMYmNXkGaEVaWCi/yIqaQWercZU6 g9efVCuc+ey02RivBov6jJ8g24sqiMt4EhrD0uLS+X1gSRZLzN9GYaj81EeAcNHayl5u Dnyw== X-Received: by 10.68.48.227 with SMTP id p3mr44822952pbn.34.1361314958182; Tue, 19 Feb 2013 15:02:38 -0800 (PST) Received: from [192.168.13.208] (c-67-180-20-82.hsd1.ca.comcast.net. [67.180.20.82]) by mx.google.com with ESMTPS id q4sm108839772paz.20.2013.02.19.15.02.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 15:02:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> Date: Tue, 19 Feb 2013 15:02:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1499) Cc: "Martin J. Levy" , v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2013 23:02:39 -0000 >>> The sum of the bits in the IANA allocated /16 prefix plus the 32 = bits >>> of the ASN plus the /48 of user defined usage adds up to 128 bits. >>>=20 >>> +------+----------------------+ >>> | Bits | Usage | >>> +------+----------------------+ >>> | 16 | IANA provided prefix | >>> | 32 | ASN | >>> | 80 | User defined | >>> | 128 | TOTAL | >>> +------+----------------------+ >>>=20 >>> Table 1: Address space math >>=20 >> Can there be some ASN values assigned to signify "no one owns the = /48"? So we can have even more independent assignments. For the purposes = of LISP, we don't care if these address don't perfect aggregate because = these addresses will go into the LISP mapping database system which may = not need to aggregate since the RLOCs associated with the prefixes will = be different anyways (and therefore can't aggregate or compress). >=20 > Wouldn't the private ASN range already effectively do this? I'm asking the intent of the authors. >>> The end network can allocate out of the assigned /48 as needed. It >>> is assumed that the end network will use this allocation for global >>> routing; however the network may choose to not announce this >>> allocation. >>=20 >> Okay, so lets use an example to see how this can be used. Let's say a = /80 comes out of Verizon's space: >>=20 >> (1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and = Ford so they can use Vehicle ID Numbers for the rest of the allocation = for their automobile EID assignments? >>=20 >=20 > First of all, you can't pull a /64 out of a /80 so I think you mean a = /48 assigned to $PROVIDER. Yes, I mistyped. > I think permanently assigned addresses related to VINS are, in = general, a bad idea. I don't see any advantage to tying the semantics of = the two systems to each other. If anything, the development of LISP is = the result of failing to separate the semantics of end-point addressing = from the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. An EID is opaque and not used by the protocol stack just by humans if = they choose to look at them.=20 >> (3) What if these auto manufactures don't want to allocate ASN = numbers because they will never have any intent to run BGP either in the = cars, POPs, data centers? >>=20 >=20 > I don't see anything in this draft that would preclude them from using = a different source of addressing. >=20 > I confess, to some extent, I wonder if this is a solution in search of = a problem. I know there are customers that want to reduce the number of total = databases they have to manage at all layers of the stack. >>> If any route is announced from this allocation, any prefixes more >>> specific than the allocated /48 must not be propagated in to the >>> global IPv6 routing table. This is to prevent the IPv6 routing = table >>=20 >> This is fine authors, but if you are multi-home, it will require each = system at the site to possess multiple addresses one from each attached = ASN if they do not have their own prefix but get it out of their = provider. >>=20 >> If you say that this prefix will never be associated with a = provider's attachment point, then I'm okay with that and agree. >>=20 >=20 > Either I misunderstand what you are saying, or, you have erred. I'm = not sure which. >=20 > If a site uses a /64 from within this /48 to attach to each upstream, = the more specific does not need to propagate beyond the immediate = upstream router, so it still wouldn't be announced into the global = routing table. There is still PI flat routing on the scale of number of sites that use = this prefix. That is the point, there is no attempt to improve the route = table scaling problem. I'm not saying this draft should, just speaking = generally. >>> from becoming too large. Therefore, a site which uses this >>> allocation MUST NOT advertise a more specific than the allocated = /48 >>> routing prefix. All native IPv6 network operators MUST filter out >>>=20 >>>=20 >>>=20 >>> Levy & Pounsett Expires July 28, 2013 = [Page 3] >>> Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >>>=20 >>>=20 >>> and discard any routing prefix advertisements longer than /48 from >>> within this /16 allocation. >>=20 >> Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. >>=20 >=20 > I think that is inherent in the definition of the prefix. Can you = clarify why you think this > statement is necessary? I want it explicit so there is no layers of ownership of the prefix. >>> ASNs are normally expressed as human-readable decimal numbers; yet >>> for this allocation the number should be converted into a = hexadecimal >>> notation. All IPv6 addresses are written in hexadecimal. (NNNN >>> represents the /16 allocation by IANA) >>>=20 >>> +----------------+--------------------+---------------------+ >>> | ASN in decemal | ASN in hexadecimal | Sample IP block | >>> +----------------+--------------------+---------------------+ >>> | AS1 | 1 | NNNN:0000:0001::/48 | >>> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >>> | AS29001 | 7149 | NNNN:0000:0001::/48 | >>> | AS393220 | 60004 | NNNN:0006:0004::/48 | >>> +----------------+--------------------+---------------------+ >>=20 >> What we had found in the old days of NSAP deployment (OSI) that = encoding IPv4 addresses in BCD format in a hexadecimal longer address = was extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. >>=20 >> Rather than having to build tools and make vendors do UI work, can we = have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. >=20 > I would oppose doing this. If we are going to do this (and I'm not = entirely convinced that we should, but also not opposed), we should = support the full ASN space and doing so as a bit field is fine. I don't = think any UI work is required. Tools to convert 32-bit numbers from = decimal to hex are already widely available and the process is well = understood. It's not like anyone will have to do this conversion on a = daily basis. >=20 > perl -e 'printf "%08x\n", ' will solve the = problem, for example. Multiply by 1000 products coming out over different delivery times. = Don't underestimate the slowness of vendors. >>> 5. ASN allocation >>>=20 >>> ASNs are allocated by RIRs and this RFC does not handle that arena. >>>=20 >>> ASNs defined as private ASNs MUST NOT use this scheme. The special >>> 16-bit ASN 23456 MUST NOT use this scheme. >>=20 >> I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. >=20 > What local/global bit? Add one is the suggestion. >>> This mechanism is not expected to have any impact to the global >>> Internet routing table since existing policies in the RIR system >>> already readily provide for the allocation of provider-independent >>> IPv6 prefixes. Additionally, AS number holders are likely to be >>> multihomed entities which were going to be independently routed in >>> any case. Service Providers are, as always, not obligated to route >>> these IPv6 assignments and/or may establish conditions of service >>> which offset any additional routing cost. >>=20 >> I would say it would have the same impact as PI prefixes do today. >>=20 >=20 > Which means that this has no impact because it doesn't change the = impact vs. the current PI impact. You miss the point. The problem needs to be solved. Saying this draft = doesn't worsen it is not panacea. Dino From owen@delong.com Tue Feb 19 17:10: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 7AEF421F8758; Tue, 19 Feb 2013 17:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8brDuEZQUBwH; Tue, 19 Feb 2013 17:10:53 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1D21F874E; Tue, 19 Feb 2013 17:10:52 -0800 (PST) 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 r1K19sM9001429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2013 17:09:54 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1K19sM9001429 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361322595; bh=8enGPfNjgb3v1TM3JqHrfQwdGYM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TPWk+Cod54ZRln4IfH14AeyTMBzgBnGAzPR3TKpzWX6RpXbZRYsRbgj1vgG7D/i+0 Tk1qVJ9J1A2Fzy6IX02sjUFdfZiLN+y6Fij1ruKA6SmS55BZvNAFSB/J9FubZP+0lH D6++dFiaMd1ZowVefXdqnfXtIvjCCU6O9sRjCJNM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Date: Tue, 19 Feb 2013 17:09:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 19 Feb 2013 17:09:55 -0800 (PST) Cc: "Martin J. Levy" , v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 01:10:54 -0000 >> I think permanently assigned addresses related to VINS are, in = general, a bad idea. I don't see any advantage to tying the semantics of = the two systems to each other. If anything, the development of LISP is = the result of failing to separate the semantics of end-point addressing = from the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. >=20 > An EID is opaque and not used by the protocol stack just by humans if = they choose to look at them.=20 >=20 One of us is misunderstanding the other. My point is that using IPv6 = address space to number things that are not IPv6 hosts is, IMHO, a bad = idea. >>> (3) What if these auto manufactures don't want to allocate ASN = numbers because they will never have any intent to run BGP either in the = cars, POPs, data centers? >>>=20 >>=20 >> I don't see anything in this draft that would preclude them from = using a different source of addressing. >>=20 >> I confess, to some extent, I wonder if this is a solution in search = of a problem. >=20 > I know there are customers that want to reduce the number of total = databases they have to manage at all layers of the stack. >=20 All well and good, but I do not support turning IPv6 addresses into the = primary key for everything in world anyone wants to identify in any = namespace. If that's not what your sentence above means, then I'm afraid = I misunderstand your meaning. Again, I do not support the idea of using IPv6 numbers as a mechanism = for identifying anything that isn't an IPv6 host and I do not support = tying semantics other than the host end-system identifier for packet = delivery to IPv6 addresses. I think that past experience has = demonstrated that both of these practices create more problems than they = solve. >>>> If any route is announced from this allocation, any prefixes more >>>> specific than the allocated /48 must not be propagated in to the >>>> global IPv6 routing table. This is to prevent the IPv6 routing = table >>>=20 >>> This is fine authors, but if you are multi-home, it will require = each system at the site to possess multiple addresses one from each = attached ASN if they do not have their own prefix but get it out of = their provider. >>>=20 >>> If you say that this prefix will never be associated with a = provider's attachment point, then I'm okay with that and agree. >>>=20 >>=20 >> Either I misunderstand what you are saying, or, you have erred. I'm = not sure which. >>=20 >> If a site uses a /64 from within this /48 to attach to each upstream, = the more specific does not need to propagate beyond the immediate = upstream router, so it still wouldn't be announced into the global = routing table. >=20 > There is still PI flat routing on the scale of number of sites that = use this prefix. That is the point, there is no attempt to improve the = route table scaling problem. I'm not saying this draft should, just = speaking generally. I think that concern is entirely orthogonal to this draft. My point is = that for every PI prefix that gets advertised from this space, it should represent a PI = prefix from RIR space that does not get advertised, so it is a net equivalence in terms = of the routing table. Thus, I would anticipate that this draft has no impact on = the routing table. OTOH, the whole way we do IDR is broken and we should have fixed it as = part of the IPv6 development process. Unfortunately, we (IETF) chose to punt = on that and go down all kinds of other less important roads. However, this issue is = really not part of the discussion of this draft. >>>> from becoming too large. Therefore, a site which uses this >>>> allocation MUST NOT advertise a more specific than the allocated = /48 >>>> routing prefix. All native IPv6 network operators MUST filter out >>>>=20 >>>>=20 >>>>=20 >>>> Levy & Pounsett Expires July 28, 2013 = [Page 3] >>>> Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >>>>=20 >>>>=20 >>>> and discard any routing prefix advertisements longer than /48 from >>>> within this /16 allocation. >>>=20 >>> Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. >>>=20 >>=20 >> I think that is inherent in the definition of the prefix. Can you = clarify why you think this >> statement is necessary? >=20 > I want it explicit so there is no layers of ownership of the prefix. >=20 I'm not sure how stating that this prefix is PROVIDER INDEPENDENT = conveys any ownership or lack thereof. >>>> ASNs are normally expressed as human-readable decimal numbers; yet >>>> for this allocation the number should be converted into a = hexadecimal >>>> notation. All IPv6 addresses are written in hexadecimal. (NNNN >>>> represents the /16 allocation by IANA) >>>>=20 >>>> +----------------+--------------------+---------------------+ >>>> | ASN in decemal | ASN in hexadecimal | Sample IP block | >>>> +----------------+--------------------+---------------------+ >>>> | AS1 | 1 | NNNN:0000:0001::/48 | >>>> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >>>> | AS29001 | 7149 | NNNN:0000:0001::/48 | >>>> | AS393220 | 60004 | NNNN:0006:0004::/48 | >>>> +----------------+--------------------+---------------------+ >>>=20 >>> What we had found in the old days of NSAP deployment (OSI) that = encoding IPv4 addresses in BCD format in a hexadecimal longer address = was extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. >>>=20 >>> Rather than having to build tools and make vendors do UI work, can = we have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. >>=20 >> I would oppose doing this. If we are going to do this (and I'm not = entirely convinced that we should, but also not opposed), we should = support the full ASN space and doing so as a bit field is fine. I don't = think any UI work is required. Tools to convert 32-bit numbers from = decimal to hex are already widely available and the process is well = understood. It's not like anyone will have to do this conversion on a = daily basis. >>=20 >> perl -e 'printf "%08x\n", ' will solve the = problem, for example. >=20 > Multiply by 1000 products coming out over different delivery times. = Don't underestimate the slowness of vendors. >=20 I'm not sure what you mean by this. Why would products coming out = receive AS Numbers? I think you are pursuing a use case that is not = intended under my interpretation of this draft and taking it to extremes = that are beyond my comprehension. >>>> 5. ASN allocation >>>>=20 >>>> ASNs are allocated by RIRs and this RFC does not handle that arena. >>>>=20 >>>> ASNs defined as private ASNs MUST NOT use this scheme. The special >>>> 16-bit ASN 23456 MUST NOT use this scheme. >>>=20 >>> I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. >>=20 >> What local/global bit? >=20 > Add one is the suggestion. >=20 I expected that's where you were going. I think 16 bits is already a = rather short prefix for this use case. I don't believe that there is a = sufficient use case for a local/global bit. If you do, you need to make = a better case for it than the above. I would propose modifying section 5 of the draft to state, instead of = "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any = prefixes within the prefix allocated for this purpose must be considered = "LOCAL addresses and given similar semantics to RFC-1918". I would not give the the semantics of ULA because of the likelihood of = overlap. >>>> This mechanism is not expected to have any impact to the global >>>> Internet routing table since existing policies in the RIR system >>>> already readily provide for the allocation of provider-independent >>>> IPv6 prefixes. Additionally, AS number holders are likely to be >>>> multihomed entities which were going to be independently routed in >>>> any case. Service Providers are, as always, not obligated to route >>>> these IPv6 assignments and/or may establish conditions of service >>>> which offset any additional routing cost. >>>=20 >>> I would say it would have the same impact as PI prefixes do today. >>>=20 >>=20 >> Which means that this has no impact because it doesn't change the = impact vs. the current PI impact. >=20 > You miss the point. The problem needs to be solved. Saying this draft = doesn't worsen it is not panacea. >=20 You miss the point. This draft is not intending to solve that problem = and makes no claim in that respect. I agree the problem needs to be solved. However, Solving the problem = isn't even within the purview of the v6ops working group. Raising it as = an issue in the discussion of this draft is only relevant to the extent = that this draft makes the problem worse or prevents any proposed = solution to the problem from being effective. Since neither of those = applies, there are no routing table considerations applicable to this = draft IMHO. Owen From farinacci@gmail.com Tue Feb 19 18: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 1EBA721F8802; Tue, 19 Feb 2013 18:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-2.198, BAYES_50=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0yfqlgMAJpW; Tue, 19 Feb 2013 18:16:44 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id D69A321F8840; Tue, 19 Feb 2013 18:16:43 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id ma3so2584399pbc.39 for ; Tue, 19 Feb 2013 18:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=tLk6xPBNIkDvLe4uuPm3Ga9qJIxDmw6KIAK7Kd0ZpXc=; b=gsmkOhqNF4eFmWO5QE1qlwoFmj0it3/kTTIw2OLXSJrCaklmJffNKe1POhJbNEciGo PZ0R5x55e1edzMNqTayToMzGoifW7euTE33Ckm3cngBIeIpvhErnMiXvcB3Ngi974Ij4 q2D2OhbjfrHF7B859pIgFK0Mj7i2Ekz7gpwyONs/2vKZ2+GYpR54XEoyofNd4U4CKH8d uMjnw3f+LZF/wuwEc7ogRROQRk9BFewvDyCj0gEO1SZeUGyF86Vf1V6kzhsj5KxPbS7X gV54kTlf/xo8K2dHPlqCHddhEHi0Dq2BZxiX/FfBVYsdCuRdrFIkUU3bdYZfK9G1vrpQ 3Apg== X-Received: by 10.68.130.35 with SMTP id ob3mr59646pbb.92.1361326603515; Tue, 19 Feb 2013 18:16:43 -0800 (PST) Received: from [192.168.1.9] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id gg7sm19847416pbc.45.2013.02.19.18.16.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 18:16:42 -0800 (PST) References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B143) From: Dino Farinacci Date: Tue, 19 Feb 2013 18:16:41 -0800 To: Owen DeLong Cc: "Martin J. Levy" , "v6ops@ietf.org" , "lisp@ietf.org list list" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 02:16:45 -0000 On Feb 19, 2013, at 5:09 PM, Owen DeLong wrote: >>> I think permanently assigned addresses related to VINS are, in general, a= bad idea. I don't see any advantage to tying the semantics of the two syste= ms to each other. If anything, the development of LISP is the result of fail= ing to separate the semantics of end-point addressing from the semantics of t= opological location. Combining the semantics of end-point addressing and VIN= s seems even more far-fetched to me. >>=20 >> An EID is opaque and not used by the protocol stack just by humans if the= y choose to look at them.=20 >>=20 >=20 > One of us is misunderstanding the other. My point is that using IPv6 addre= ss space to number things that are not IPv6 hosts is, IMHO, a bad idea. The automobiles are IPv6 hosts.=20 >=20 >>>> (3) What if these auto manufactures don't want to allocate ASN numbers b= ecause they will never have any intent to run BGP either in the cars, POPs, d= ata centers? >>>>=20 >>>=20 >>> I don't see anything in this draft that would preclude them from using a= different source of addressing. >>>=20 >>> I confess, to some extent, I wonder if this is a solution in search of a= problem. >>=20 >> I know there are customers that want to reduce the number of total databa= ses they have to manage at all layers of the stack. >>=20 >=20 > All well and good, but I do not support turning IPv6 addresses into the pr= imary key for everything in world anyone wants to identify in any namespace.= If that's not what your sentence above means, then I'm afraid I misundersta= nd your meaning. It is none of your business how sites use their addresses. That is the whole= point of ID/Locator separation.=20 The EID is opaque to the network but may have meaning to the sites who commu= nicate with each other within that EID-prefix.=20 > Again, I do not support the idea of using IPv6 numbers as a mechanism for i= dentifying anything that isn't an IPv6 host and I do not support tying seman= tics other than the host end-system identifier for packet delivery to IPv6 a= ddresses. I think that past experience has demonstrated that both of these p= ractices create more problems than they solve. See above. Tell me if you still disagree and if so we will have to disagree.= This is where IPv6 could be useful. What does IPv6 have that IPv4 doesn't? R= eally only longer addresses.=20 >=20 >>>>> If any route is announced from this allocation, any prefixes more >>>>> specific than the allocated /48 must not be propagated in to the >>>>> global IPv6 routing table. This is to prevent the IPv6 routing table >>>>=20 >>>> This is fine authors, but if you are multi-home, it will require each s= ystem at the site to possess multiple addresses one from each attached ASN i= f they do not have their own prefix but get it out of their provider. >>>>=20 >>>> If you say that this prefix will never be associated with a provider's a= ttachment point, then I'm okay with that and agree. >>>>=20 >>>=20 >>> Either I misunderstand what you are saying, or, you have erred. I'm not s= ure which. >>>=20 >>> If a site uses a /64 from within this /48 to attach to each upstream, th= e more specific does not need to propagate beyond the immediate upstream rou= ter, so it still wouldn't be announced into the global routing table. >>=20 >> There is still PI flat routing on the scale of number of sites that use t= his prefix. That is the point, there is no attempt to improve the route tabl= e scaling problem. I'm not saying this draft should, just speaking generally= . >=20 > I think that concern is entirely orthogonal to this draft. My point is tha= t for every PI > prefix that gets advertised from this space, it should represent a PI pref= ix from RIR > space that does not get advertised, so it is a net equivalence in terms of= the > routing table. Thus, I would anticipate that this draft has no impact on t= he routing > table. Okay fine.=20 > OTOH, the whole way we do IDR is broken and we should have fixed it as par= t > of the IPv6 development process. Unfortunately, we (IETF) chose to punt on= that and > go down all kinds of other less important roads. However, this issue is re= ally > not part of the discussion of this draft. If locator/ID separation is used then this is helped and you make multi-homi= ng easier at the same time as making address management in every host.=20 Look how complicated the home networking proposals are? >=20 >>>>> from becoming too large. Therefore, a site which uses this >>>>> allocation MUST NOT advertise a more specific than the allocated /48 >>>>> routing prefix. All native IPv6 network operators MUST filter out >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Levy & Pounsett Expires July 28, 2013 [Page 3= ] >>>>> Internet-Draft Auto allocation mechanism for IPv6 blocks January 20= 13 >>>>>=20 >>>>>=20 >>>>> and discard any routing prefix advertisements longer than /48 from >>>>> within this /16 allocation. >>>>=20 >>>> Can you explicitly state then that this prefix for use as a PROVIDER IN= DEPENDENT prefix. Thanks. >>>>=20 >>>=20 >>> I think that is inherent in the definition of the prefix. Can you clarif= y why you think this >>> statement is necessary? >>=20 >> I want it explicit so there is no layers of ownership of the prefix. >>=20 >=20 > I'm not sure how stating that this prefix is PROVIDER INDEPENDENT conveys a= ny ownership or lack thereof. Never mind - bit worth arguing the point.=20 >=20 >>>>> ASNs are normally expressed as human-readable decimal numbers; yet >>>>> for this allocation the number should be converted into a hexadecimal >>>>> notation. All IPv6 addresses are written in hexadecimal. (NNNN >>>>> represents the /16 allocation by IANA) >>>>>=20 >>>>> +----------------+--------------------+---------------------+ >>>>> | ASN in decemal | ASN in hexadecimal | Sample IP block | >>>>> +----------------+--------------------+---------------------+ >>>>> | AS1 | 1 | NNNN:0000:0001::/48 | >>>>> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >>>>> | AS29001 | 7149 | NNNN:0000:0001::/48 | >>>>> | AS393220 | 60004 | NNNN:0006:0004::/48 | >>>>> +----------------+--------------------+---------------------+ >>>>=20 >>>> What we had found in the old days of NSAP deployment (OSI) that encodin= g IPv4 addresses in BCD format in a hexadecimal longer address was extremely= useful for management. And as we have seen for IPv6, even embedding IPv4 do= tted decimal format was extremely useful. >>>>=20 >>>> Rather than having to build tools and make vendors do UI work, can we h= ave some form of BCD format for AS number. I know this will be difficult for= a 32-bit number but we could make it work for the ASNs that are <=3D 65535.= Just a thought. But even 10 million ASNS would only take up to 8 nibbles. A= nd since we won't and can't aggregate ASNs there is no point in making the e= ncoding a power-of-2 value. >>>=20 >>> I would oppose doing this. If we are going to do this (and I'm not entir= ely convinced that we should, but also not opposed), we should support the f= ull ASN space and doing so as a bit field is fine. I don't think any UI work= is required. Tools to convert 32-bit numbers from decimal to hex are alread= y widely available and the process is well understood. It's not like anyone w= ill have to do this conversion on a daily basis. >>>=20 >>> perl -e 'printf "%08x\n", ' will solve the problem= , for example. >>=20 >> Multiply by 1000 products coming out over different delivery times. Don't= underestimate the slowness of vendors. >>=20 >=20 > I'm not sure what you mean by this. Why would products coming out receive A= S Numbers? I think you are pursuing a use case that is not intended under my= interpretation of this draft and taking it to extremes that are beyond my c= omprehension. I mean each product would have to build a hex to decimal conversion capabili= ty in their UI.=20 >=20 >>>>> 5. ASN allocation >>>>>=20 >>>>> ASNs are allocated by RIRs and this RFC does not handle that arena. >>>>>=20 >>>>> ASNs defined as private ASNs MUST NOT use this scheme. The special >>>>> 16-bit ASN 23456 MUST NOT use this scheme. >>>>=20 >>>> I would let users do this with private ASes if they want to. Set a loca= l/global bit in your encoding so they can use it. If you don't they will ste= al ASN numbers which they should not do but will. >>>=20 >>> What local/global bit? >>=20 >> Add one is the suggestion. >>=20 >=20 > I expected that's where you were going. I think 16 bits is already a rathe= r short prefix for this use case. I don't believe that there is a sufficient= use case for a local/global bit. If you do, you need to make a better case f= or it than the above. Well explicitly encoding that the intent of the address is local is a good t= hing IMO.=20 >=20 > I would propose modifying section 5 of the draft to state, instead of "ASN= s MUST NOT use..." that "ASNs MUST NOT advertise..." and that any prefixes w= ithin the prefix allocated for this purpose must be considered "LOCAL addres= ses and given similar semantics to RFC-1918". Sounds good.=20 >=20 > I would not give the the semantics of ULA because of the likelihood of ove= rlap. >=20 >>>>> This mechanism is not expected to have any impact to the global >>>>> Internet routing table since existing policies in the RIR system >>>>> already readily provide for the allocation of provider-independent >>>>> IPv6 prefixes. Additionally, AS number holders are likely to be >>>>> multihomed entities which were going to be independently routed in >>>>> any case. Service Providers are, as always, not obligated to route >>>>> these IPv6 assignments and/or may establish conditions of service >>>>> which offset any additional routing cost. >>>>=20 >>>> I would say it would have the same impact as PI prefixes do today. >>>>=20 >>>=20 >>> Which means that this has no impact because it doesn't change the impact= vs. the current PI impact. >>=20 >> You miss the point. The problem needs to be solved. Saying this draft doe= sn't worsen it is not panacea. >>=20 >=20 > You miss the point. This draft is not intending to solve that problem and m= akes no claim in that respect. I understand that and I'm not saying the spec should fix it. I was replying t= o your comment only.=20 >=20 > I agree the problem needs to be solved. However, Solving the problem isn't= even within the purview of the v6ops working group. Raising it as an I realize that. But not let's process get in the way of having an open dial= ogue.=20 > issue in the discussion of this draft is only relevant to the extent that t= his draft makes the problem worse or prevents any proposed solution to the p= roblem from being effective. Since neither of those applies, there are no ro= uting table considerations applicable to this draft IMHO. >=20 > Owen Fine. Thanks for listening.=20 Dino= From owen@delong.com Tue Feb 19 18:50: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 D31EB21F87FF; Tue, 19 Feb 2013 18:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_40=-0.185, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkPfr0sDkoe8; Tue, 19 Feb 2013 18:50:51 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57421F86EA; Tue, 19 Feb 2013 18:50:50 -0800 (PST) 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 r1K2o6L8004216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2013 18:50:06 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1K2o6L8004216 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361328606; bh=yOer/efuQUNmH+jE1iAcXmaoucc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ilHwoigobpVbCipl1Z2khxS4lfT035NucMgSpjgmlvie0d5yNqOBTVaDqvyKiES0k vGMTsoTzi+QVR47EH28aJzaTORXTlVJYSyNWrRTsCZpqg8v8x4BcDbcSm7fds+pR+L ssn3u0xfFxjywGdYfpq8XuTeNkkLDo4LDWtMzkS0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Tue, 19 Feb 2013 18:50:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 19 Feb 2013 18:50:06 -0800 (PST) Cc: "Martin J. Levy" , "v6ops@ietf.org" , "lisp@ietf.org list list" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 02:50:53 -0000 On Feb 19, 2013, at 18:16 , Dino Farinacci wrote: > On Feb 19, 2013, at 5:09 PM, Owen DeLong wrote: >=20 >>>> I think permanently assigned addresses related to VINS are, in = general, a bad idea. I don't see any advantage to tying the semantics of = the two systems to each other. If anything, the development of LISP is = the result of failing to separate the semantics of end-point addressing = from the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. >>>=20 >>> An EID is opaque and not used by the protocol stack just by humans = if they choose to look at them.=20 >>>=20 >>=20 >> One of us is misunderstanding the other. My point is that using IPv6 = address space to number things that are not IPv6 hosts is, IMHO, a bad = idea. >=20 > The automobiles are IPv6 hosts.=20 It is unlikely that any network will ever be {all vehicles with VIN is a = member of [RANGE]} other than possibly a brief factory test. Thus, I do not believe it is appropriate to permanently associate a = prefix with a collection of vehicles based on their VIN. >=20 >>=20 >>>>> (3) What if these auto manufactures don't want to allocate ASN = numbers because they will never have any intent to run BGP either in the = cars, POPs, data centers? >>>>>=20 >>>>=20 >>>> I don't see anything in this draft that would preclude them from = using a different source of addressing. >>>>=20 >>>> I confess, to some extent, I wonder if this is a solution in search = of a problem. >>>=20 >>> I know there are customers that want to reduce the number of total = databases they have to manage at all layers of the stack. >>>=20 >>=20 >> All well and good, but I do not support turning IPv6 addresses into = the primary key for everything in world anyone wants to identify in any = namespace. If that's not what your sentence above means, then I'm afraid = I misunderstand your meaning. >=20 > It is none of your business how sites use their addresses. That is the = whole point of ID/Locator separation.=20 >=20 > The EID is opaque to the network but may have meaning to the sites who = communicate with each other within that EID-prefix.=20 >=20 I do not support allocating globally unique prefixes for things that are = not networks. Perhaps that will better explain my position. I think that overloading the IPv6 prefix space with semantics for = arbitrary collections of things is a really bad idea that has tremendous = potential to consume vast amounts of addresses while yielding no network = benefit in return. Will it exhaust the IPv6 space immediately, probably not. Could we = easily exhaust the ASN space if we start promoting the idea of claiming = ASNs to support this? Yeah, we could probably burn 4 billion ASNs that = way without too much trouble. >> Again, I do not support the idea of using IPv6 numbers as a mechanism = for identifying anything that isn't an IPv6 host and I do not support = tying semantics other than the host end-system identifier for packet = delivery to IPv6 addresses. I think that past experience has = demonstrated that both of these practices create more problems than they = solve. >=20 > See above. Tell me if you still disagree and if so we will have to = disagree. This is where IPv6 could be useful. What does IPv6 have that = IPv4 doesn't? Really only longer addresses.=20 >=20 I disagree, but at least I now fully understand what you're trying to = inflict on the world. As to the answer to your other question: SLAAC 6-lowpan Improved header structure Extension headers Cleaner IPSEC implementation I'm sure there's more, but I don't want to get too far down yet another = orthogonal discussion. >>=20 >>>>>> If any route is announced from this allocation, any prefixes more >>>>>> specific than the allocated /48 must not be propagated in to the >>>>>> global IPv6 routing table. This is to prevent the IPv6 routing = table >>>>>=20 >>>>> This is fine authors, but if you are multi-home, it will require = each system at the site to possess multiple addresses one from each = attached ASN if they do not have their own prefix but get it out of = their provider. >>>>>=20 >>>>> If you say that this prefix will never be associated with a = provider's attachment point, then I'm okay with that and agree. >>>>>=20 >>>>=20 >>>> Either I misunderstand what you are saying, or, you have erred. I'm = not sure which. >>>>=20 >>>> If a site uses a /64 from within this /48 to attach to each = upstream, the more specific does not need to propagate beyond the = immediate upstream router, so it still wouldn't be announced into the = global routing table. >>>=20 >>> There is still PI flat routing on the scale of number of sites that = use this prefix. That is the point, there is no attempt to improve the = route table scaling problem. I'm not saying this draft should, just = speaking generally. >>=20 >> I think that concern is entirely orthogonal to this draft. My point = is that for every PI >> prefix that gets advertised from this space, it should represent a PI = prefix from RIR >> space that does not get advertised, so it is a net equivalence in = terms of the >> routing table. Thus, I would anticipate that this draft has no impact = on the routing >> table. >=20 > Okay fine.=20 >=20 >> OTOH, the whole way we do IDR is broken and we should have fixed it = as part >> of the IPv6 development process. Unfortunately, we (IETF) chose to = punt on that and >> go down all kinds of other less important roads. However, this issue = is really >> not part of the discussion of this draft. >=20 > If locator/ID separation is used then this is helped and you make = multi-homing easier at the same time as making address management in = every host.=20 >=20 At the price of converting every connection into a tunnel with = associated MTU penalties. A better solution (IMHO) would be to have a 32 bit field added to the = protocol to contain the destination ASN embedded in the packet header. = Unfortunately, this is a major change to every system and would = basically be the next protocol version (though at least IPv6 and IPv{N} = would be interchangeably compatible with each other except for the MTU = issues). > Look how complicated the home networking proposals are? Agreed, it's ridiculous. We should, instead, recognize that we dropped = the ball in IPv6 design and do something slightly different before the = routing table explodes. We have several years beyond IPv6 deployment to = address that issue, IMHO. For now, I'd rather focus on actual = operational issues related to IPv6 deployment and revisit solving the = routing table problem later. >> I'm not sure what you mean by this. Why would products coming out = receive AS Numbers? I think you are pursuing a use case that is not = intended under my interpretation of this draft and taking it to extremes = that are beyond my comprehension. >=20 > I mean each product would have to build a hex to decimal conversion = capability in their UI.=20 1. Libraries already contain these and nobody is hand-coding = systems in assembly language any more. 2. This is seriously not difficult and most products duplicate = enough UI components from other products that it would rapidly become a boilerplate component in the = developer tool kit at each organization if it hasn't already. >=20 >>=20 >>>>>> 5. ASN allocation >>>>>>=20 >>>>>> ASNs are allocated by RIRs and this RFC does not handle that = arena. >>>>>>=20 >>>>>> ASNs defined as private ASNs MUST NOT use this scheme. The = special >>>>>> 16-bit ASN 23456 MUST NOT use this scheme. >>>>>=20 >>>>> I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. >>>>=20 >>>> What local/global bit? >>>=20 >>> Add one is the suggestion. >>>=20 >>=20 >> I expected that's where you were going. I think 16 bits is already a = rather short prefix for this use case. I don't believe that there is a = sufficient use case for a local/global bit. If you do, you need to make = a better case for it than the above. >=20 > Well explicitly encoding that the intent of the address is local is a = good thing IMO.=20 >=20 Which I believe my suggestion below would cover... >>=20 >> I would propose modifying section 5 of the draft to state, instead of = "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any = prefixes within the prefix allocated for this purpose must be considered = "LOCAL addresses and given similar semantics to RFC-1918". >=20 > Sounds good.=20 >=20 Zero bit cost here.=20 Owen From farinacci@gmail.com Tue Feb 19 19:20: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 9679621F887F; Tue, 19 Feb 2013 19:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrEe1ZfvL+b9; Tue, 19 Feb 2013 19:20:45 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0700621F8810; Tue, 19 Feb 2013 19:20:40 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so2614760pbc.30 for ; Tue, 19 Feb 2013 19:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=N4hwWzaV6pdkj4kRL75CYppYYpByKNuGnL/PrpGoX9A=; b=Nh3DnlR/5ZVk+i2WWUc/YOz1oGApiy1mHYdE2Dre8+7QQCaoe82A3Wc7imUw0QZ4Ug 7sJ60iVsyzG29UcaXeEmqPaEBHBv6mgbrBFNJjZdLk4M4My5L/6ekDHHgWgH1V74jMT+ l3dM5OmNWBwCGuiFgyf99Vx2TywWNh2j+qQsmYMCFjazE45dKwHouTIuSssD9V4m3H/R sporNgwXpkhy+73jWDbIjaSSQaS/lVuuppiRt3Aq/FiFLZ+aPz/lpl36MMmJSdyAbAlU scyiYzKkJ5jd9UIPk3/jW2ofBynkITJhOzm5h7Xkkw2jXvfmbbU4qP9mkArEt41I5aQA qc1w== X-Received: by 10.68.10.227 with SMTP id l3mr16809485pbb.100.1361330440728; Tue, 19 Feb 2013 19:20:40 -0800 (PST) Received: from [192.168.1.9] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id e6sm109514760paw.16.2013.02.19.19.20.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 19:20:39 -0800 (PST) References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2AC77963-D39E-4026-A0A7-01CCCE2026D9@gmail.com> X-Mailer: iPhone Mail (10B143) From: Dino Farinacci Date: Tue, 19 Feb 2013 19:20:37 -0800 To: Owen DeLong Cc: "Martin J. Levy" , "v6ops@ietf.org" , "lisp@ietf.org list list" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 03:20:47 -0000 > A better solution (IMHO) would be to have a 32 bit field added to the prot= ocol to contain the destination ASN embedded in the packet header. Unfortuna= tely, this is a major change to every system and would basically be the next= protocol version (though at least IPv6 and IPv{N} would be interchangeably c= ompatible with each other except for the MTU issues). Right - a non-starter.=20 LISP is certainly not a non-starter. More specifically, it is a incremental-= starter.=20 If you want to find out, get on the LISP pilot network. See www.lisp4.net, e= rr I mean www.lisp6.net for you. :-) Dino From shtsuchi@cisco.com Tue Feb 19 21:18: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 B936A21F877A for ; Tue, 19 Feb 2013 21:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.97 X-Spam-Level: X-Spam-Status: No, score=-8.97 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBA+drf7nGeU for ; Tue, 19 Feb 2013 21:18:44 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3121F8684 for ; Tue, 19 Feb 2013 21:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4161; q=dns/txt; s=iport; t=1361337523; x=1362547123; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XYq+H6cvAtBAA/Fh1BZYcKmCGMsnP2rPX+B9NoMrVvI=; b=FNS2tdnWUVAylIiRtRD2dMSRCr13waOpC1vsIJ4apCBR2PX9CmUrtiC0 lxm7LJVxkPyriwslBCHLAe30J6S5xAv6t0uxBl21bWU6Hw5Zr/r3xfYnY BN7eaQ4RetVitg6ajuLThEPSNaguHbydmoGPHHoxIyjCroVLRGWAmi9Gb A=; X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; d="scan'208";a="25757305" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 20 Feb 2013 05:18:39 +0000 Received: from [10.141.43.157] (dhcp-10-141-43-157.cisco.com [10.141.43.157]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1K5Icjo015034; Wed, 20 Feb 2013 05:18:38 GMT Message-ID: <51245CAC.1050609@cisco.com> Date: Wed, 20 Feb 2013 14:18:36 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: owen@delong.com References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, draft-shishio-v6ops-dpvt@tools.ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 05:18:45 -0000 Owen I really appreciate your comment. (2013/02/20 4:21), Owen DeLong wrote: > I'm sorry, but I still do not understand the need for this technology. > > In the current case: > The operator's system delegates a prefix to the subscriber. > The operator has no need for visibility into the subscriber's network. > The subscriber's equipment can break up the delegated prefix at will. > The operator only needs to deliver packets to the subscriber through > the device which requested and received the delegation. > > What problem is solved by giving the operator additional visibility into the > subscriber's network and why would this be desirable? > >>From the subscriber perspective, I think this is a breech of security as it > discloses information about the structure of my network without my > consent.(Even if that disclosure is limited to the provider which > delegated the prefix.) > >>From the provider perspective, I don't see the advantage to being able to > gather this information. I know Sakura internet who provides the information of 6rd CE/BR and IPv6 internet. In this case,the operators can enable 6rd CE on demand. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04 BR don't need any additional configuration, so 6rd PE provider can not know how many CE enabled 6rd without traffic monitoring. And some enterprise customer would like to use 6rd instead of manual tunnel. In these cases,PE operators doesn't need additional configuration for each of CEs. This is really stateless tunnel merit.But can not find how many CE already deployed. About DHCP-pd,service provider delegates large prefix to CPE. Service provider can not know proper prefix size for the customer. > > Perhaps it would help if you could answer the following questions: > > 1. What is the advantage to the provider from knowing the subscriber's > router interface configuration? As I describes, the advantage is for planning. > > 2. What if the router has delegated component prefixes to other > routers? Umm.Indeed. The draft can not know information if the delegated prefix move and relay to another routers. > > Additionally, I think that there are security considerations and merely > restricting the permitted sources of these queries does not adequately > address them. > > Owen Thanks for comment. Regards, -Shishio > > On Feb 19, 2013, at 7:40 AM, Shishio Tsuchiya wrote: > >> Ales >> Thank for your interest. >> As I described reply to Fred, >> The stateless tunnel and prefix delegation technology provides much scalability network to the customer. >> On one hand, these technologies are difficult to plan additional capacity and hard to know current deployment >> status unless the devices are completely managed. >> If the BR has state and DHCPv6 server knows detail route,then the merit of these technologies would be disappeared. >> >> So I thought these technologies need small oam tools. >> >> -confirm only interface configuration from ISP side >> -confirm reachability not use end to end >> >> I would appreciate any comment. >> >> Regards, >> -Shishio >> >> >> >> (2013/02/19 23:08), Vízdal Aleš wrote: >>> Hi, >>> >>> can you please bit more elaborate on the problem you're trying to solve? >>> >>> Cheers, >>> Ales >>> >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >>>> fred@cisco.com >>>> Sent: Monday, February 18, 2013 2:45 PM >>>> To: v6ops@ietf.org >>>> Cc: draft-shishio-v6ops-dpvt@tools.ietf.org >>>> Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt >>>> >>>> >>>> A new draft has been posted, at http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. >>>> 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 joelja@bogus.com Wed Feb 20 00:14: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 F266321F8A99 for ; Wed, 20 Feb 2013 00:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1MZFdRiKTVp for ; Wed, 20 Feb 2013 00:14:15 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7E521F8A90 for ; Wed, 20 Feb 2013 00:14:15 -0800 (PST) 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 r1K8E99U017228 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 20 Feb 2013 08:14:10 GMT (envelope-from joelja@bogus.com) Message-ID: <512485CC.5010102@bogus.com> Date: Wed, 20 Feb 2013 00:14:04 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: maqiongfang , "fred@cisco.com" , draft-ma-v6ops-ipv6-address-assignment References: <201302201509342346215@chinamobile.com> In-Reply-To: <201302201509342346215@chinamobile.com> Content-Type: text/plain; charset=GB2312 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, 20 Feb 2013 08:14:11 +0000 (UTC) Cc: IPv6 Ops WG , v6ops-chairs Subject: Re: [v6ops] Some questions on 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: Wed, 20 Feb 2013 08:14:16 -0000 On 2/19/13 11:09 PM, maqiongfang wrote: > Dear all, > We have posted a draft about IPv6 address planning in the operator > network, at http://tools.ietf.org/html/draft-ma-v6ops-ipv6-address-ass > please make some comments. thanks! Some thoughts. So, this is pretty well traversed ground already. at a minimum a document wading into area should characterize why it is different than the previous documents and attempts to address the issue. section 3, MiFi is a registered trademark of novatel wireless in the united states and several other markets. the functionality you are describing is that of a router or device supporting mobile tehering. While I recognize that section 5 is a stab at a semantic address assignment section 6 essentially rebuts the utility of the document by stating that the problem is not genralizeable. in the example in section 5 the p1 bit-field which is the most significant bits in the prefix assignment to the provider, is the type field, if a provider is assigned a /16 then you just burned a /19 on loopbacks and interface addresses if you use 3 bits for the type field, which seems like a lot. From owen@delong.com Wed Feb 20 00:45: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 7F6C821F86EC for ; Wed, 20 Feb 2013 00:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHeylE++u6fh for ; Wed, 20 Feb 2013 00:45:46 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 80DDD21F86EA for ; Wed, 20 Feb 2013 00:45:45 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1K8ioUC007010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2013 00:44:50 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1K8ioUC007010 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361349891; bh=66NeGo8Z3FlxOWBJElL875ZTmTc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x5HgB0v4JBE5uMj5H0vkEJGy2Gsbp/VEjP+tX7YN2TlextTSq2JnHO5CYa4Kasvan sQ7gXJQtjYnTIQ/QtDUE8D8xbBeMDyb1vAYw3CnVtXIiRFfPDo0DoNsQuP7tQTi6K3 R5ZFA5n+Ra0NDhA0fgNTlFQ82djtSYjPUYHI1QsU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51245CAC.1050609@cisco.com> Date: Wed, 20 Feb 2013 00:44:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <51245CAC.1050609@cisco.com> To: Shishio Tsuchiya X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Feb 2013 00:44:51 -0800 (PST) Cc: v6ops@ietf.org, draft-shishio-v6ops-dpvt@tools.ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 08:45:47 -0000 On Feb 19, 2013, at 9:18 PM, Shishio Tsuchiya = wrote: > Owen > I really appreciate your comment. >=20 > (2013/02/20 4:21), Owen DeLong wrote: >> I'm sorry, but I still do not understand the need for this = technology. >>=20 >> In the current case: >> The operator's system delegates a prefix to the subscriber. >> The operator has no need for visibility into the subscriber's = network. >> The subscriber's equipment can break up the delegated prefix at = will. >> The operator only needs to deliver packets to the subscriber = through >> the device which requested and received the delegation. >>=20 >> What problem is solved by giving the operator additional visibility = into the >> subscriber's network and why would this be desirable? >>=20 >>> =46rom the subscriber perspective, I think this is a breech of = security as it >> discloses information about the structure of my network without my >> consent.(Even if that disclosure is limited to the provider which >> delegated the prefix.) >>=20 >>> =46rom the provider perspective, I don't see the advantage to being = able to >> gather this information. >=20 > I know Sakura internet who provides the information of 6rd CE/BR and = IPv6 internet. > In this case,the operators can enable 6rd CE on demand. > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04 >=20 > BR don't need any additional configuration, so 6rd PE provider can not = know > how many CE enabled 6rd without traffic monitoring. >=20 But why do they need to know? If they've set aside the covering prefix, = there's no prefix capacity planning issue to consider, so what is the = justification for them needing this information? > And some enterprise customer would like to use 6rd instead of manual = tunnel. >=20 Hopefully we won't need tunnels too much longer anyway,. I would rather = see us treat this as a deficiency/limitation in 6rd and continue to push for = native deployment and moving away from 6rd. In the DHCP case, you've got the logs of the PD request and PD response = from the DHCP server to give you that data. > In these cases,PE operators doesn't need additional configuration for = each of CEs. > This is really stateless tunnel merit.But can not find how many CE = already deployed. >=20 Again, once you've set aside the 6rd covering prefix, what does it = matter? > About DHCP-pd,service provider delegates large prefix to CPE. > Service provider can not know proper prefix size for the customer. >=20 I would say any prefix longer than /48 requested by the customer's = equipment is the right size, no? If the customer wants something shorter than a /48, you've moved beyond straight DHCP configuration without operator intervention anyway. Such cases should be pretty rare exceptions. >>=20 >> Perhaps it would help if you could answer the following questions: >>=20 >> 1. What is the advantage to the provider from knowing the = subscriber's >> router interface configuration? >=20 > As I describes, the advantage is for planning. >=20 Planning what, exactly? >>=20 >> 2. What if the router has delegated component prefixes to other >> routers? >=20 > Umm.Indeed. > The draft can not know information if the delegated prefix move and = relay to another routers. >=20 Which seems to me like a very likely scenario and one which would = invalidate any planning based on what you have proposed. Am I missing = something? >=20 >>=20 >> Additionally, I think that there are security considerations and = merely >> restricting the permitted sources of these queries does not = adequately >> address them. >>=20 >> Owen >=20 >=20 > Thanks for comment. >=20 > Regards, > -Shishio >=20 >=20 >>=20 >> On Feb 19, 2013, at 7:40 AM, Shishio Tsuchiya = wrote: >>=20 >>> Ales >>> Thank for your interest. >>> As I described reply to Fred, >>> The stateless tunnel and prefix delegation technology provides much = scalability network to the customer. >>> On one hand, these technologies are difficult to plan additional = capacity and hard to know current deployment >>> status unless the devices are completely managed. >>> If the BR has state and DHCPv6 server knows detail route,then the = merit of these technologies would be disappeared. >>>=20 >>> So I thought these technologies need small oam tools. >>>=20 >>> -confirm only interface configuration from ISP side >>> -confirm reachability not use end to end >>>=20 >>> I would appreciate any comment. >>>=20 >>> Regards, >>> -Shishio >>>=20 >>>=20 >>>=20 >>> (2013/02/19 23:08), V=EDzdal Ale=9A wrote: >>>> Hi, >>>>=20 >>>> can you please bit more elaborate on the problem you're trying to = solve? >>>>=20 >>>> Cheers, >>>> Ales >>>>=20 >>>>> -----Original Message----- >>>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >>>>> fred@cisco.com >>>>> Sent: Monday, February 18, 2013 2:45 PM >>>>> To: v6ops@ietf.org >>>>> Cc: draft-shishio-v6ops-dpvt@tools.ietf.org >>>>> Subject: [v6ops] new draft: draft-shishio-v6ops-dpvt >>>>>=20 >>>>>=20 >>>>> A new draft has been posted, at = http://tools.ietf.org/html/draft-shishio-v6ops-dpvt. >>>>> Please take a look at it and comment. >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> . >>=20 >=20 From maqiongfang@chinamobile.com Wed Feb 20 01:54: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 4D10021F86DE for ; Wed, 20 Feb 2013 01:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.711 X-Spam-Level: **** X-Spam-Status: No, score=4.711 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LarxqM21v9Za for ; Wed, 20 Feb 2013 01:54:08 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id EE17D21F86D6 for ; Wed, 20 Feb 2013 01:54:06 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251249d23eda-0feda; Wed, 20 Feb 2013 17:53:40 +0800 (CST) X-RM-TRANSID: 2ee251249d23eda-0feda Received: from LENOVO-CAECC328 (unknown[10.2.43.230]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351249d23e64-776dc; Wed, 20 Feb 2013 17:53:39 +0800 (CST) X-RM-TRANSID: 2ee351249d23e64-776dc Date: Wed, 20 Feb 2013 17:53:57 +0800 From: "maqiongfang" To: "joel jaeggli" , "fred@cisco.com" , "draft-ma-v6ops-ipv6-address-assignment" References: <201302201509342346215@chinamobile.com> Message-ID: <201302201753571710332@chinamobile.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon228565541804_=====" Cc: IPv6 Ops WG , v6ops-chairs Subject: Re: [v6ops] Some questions on 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: Wed, 20 Feb 2013 09:54:09 -0000 This is a multi-part message in MIME format. --=====003_Dragon228565541804_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IEhpIEpvZWwsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KSSBhZ3JlZSB3aXRoIHlv dSB0aGF0IHVzaW5nIHRoZSB3b3JkICJNaUZpIiBpcyBub3QgZ29vZC4gSW4gc2VjdGlvbiAzLCB3 aGF0IEkgbWVhbiBoZXJlIGlzIGRldmljZXMgYWxsb3dzIHNoYXJpbmcgdGhlIEludGVybmV0IGNv bm5lY3Rpb24gb2YgdGhlIHBob25lIG9yIHRhYmxldCB3aXRoIG90aGVyIGRldmljZXMgc3VjaCBh cyBsYXB0b3BzLiANCg0KSW4gZmFjdCwgdGhpcyBkcmFmdCBkaXNjdXNzZWQgdGhlIElQdjYgYWRk cmVzcyBwYWxubmluZy4gc2VjdGlvbiA1IGdpdmUgYW4gZXhhbXBsZSB0byBpbGx1c3RyYXRlIHRo ZSBhZGRyZXNzIHBsYW5uaW5nLCBpbiB0aGUgZXhhbXBsZSwgaG93IG1hbnkgZmllbGRzIHRoZSA2 NCBiaXQgY2FuIGJlIGRpdmlkZWQgaW50byAsdGhlIGxlbmd0aCBhbmQgbWVhbmluZyBvZiBlYWNo IGZpZWxkIHNob3VsZCAgYmUgYXNzaWduZWQgYWNjb3JkaW5nIHRvIHRoZSBkZXZlbG9wbWVudCBv ZiBzZXJ2aWNlIGFuZCB1c2Vycy4gc28gSSAgc3RhdGVkIHRoYXQgdGhlIGFzc2lnbm1lbnQgIGlz IG5vdCBnZW5yYWxpemVhYmxlIGluIHNlY3Rpb24gNi4gDQoNCkkgYWxzbyB0aGluayB0aGF0IHVz aW5nIDMgYml0cyBmb3IgdGhlIHR5cGUgZmllbGQgaXMgIHRvbyBtdWNoLCB0aGUgZXh0cmEgZmll bGRzIGNhbiBiZSBjb25zZXJ2ZWQuIEFzIHRoZSBudW1iZXIgb2YgdXNlcnMgaW5jcmVhc2luZywg c29tZSBmaWVsZHMgbWF5IGJlIG5vdCBlbm91Z2gsIHRoZSBjb25zZXJ2ZWQgZmllbGRzIGNhbiBi ZSB1c2VkIGZvciBleHBhbnNpb24gaW4gdGhlIGZ1dHVyZS4NCg0KQmVzdCB3aXNoZXMhDQoNCk1h IFFpb25nZmFuZw0KDQoyMDEzLTAyLTIwIA0KDQoNCg0KDQoNCg0KDQq3orz+yMujuiBqb2VsIGph ZWdnbGkgDQq3osvNyrG85KO6IDIwMTMtMDItMjAgIDE2OjEzOjU4IA0KytW8/sjLo7ogbWFxaW9u Z2Zhbmc7IGZyZWRAY2lzY28uY29tOyBkcmFmdC1tYS12Nm9wcy1pcHY2LWFkZHJlc3MtYXNzaWdu bWVudCANCrOty82juiB2Nm9wcy1jaGFpcnM7IElQdjYgT3BzIFdHIA0K1vfM4qO6IFJlOiBTb21l IHF1ZXN0aW9ucyBvbiBkcmFmdC1tYS12Nm9wcy1pcHY2LWFkZHJlc3MtYXNzaWdubWVudCANCiAN Ck9uIDIvMTkvMTMgMTE6MDkgUE0sIG1hcWlvbmdmYW5nIHdyb3RlOg0KPiBEZWFyIGFsbCwNCj4g V2UgaGF2ZSBwb3N0ZWQgYSBkcmFmdCBhYm91dCBJUHY2IGFkZHJlc3MgcGxhbm5pbmcgaW4gdGhl IG9wZXJhdG9yDQo+IG5ldHdvcmssIGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW1hLXY2b3BzLWlwdjYtYWRkcmVzcy1hc3MNCj4gcGxlYXNlIG1ha2Ugc29tZSBjb21tZW50cy4g dGhhbmtzIQ0KU29tZSB0aG91Z2h0cy4NClNvLCB0aGlzIGlzIHByZXR0eSB3ZWxsIHRyYXZlcnNl ZCBncm91bmQgYWxyZWFkeS4gYXQgYSBtaW5pbXVtIGENCmRvY3VtZW50IHdhZGluZyBpbnRvIGFy ZWEgc2hvdWxkIGNoYXJhY3Rlcml6ZSB3aHkgaXQgaXMgZGlmZmVyZW50IHRoYW4NCnRoZSBwcmV2 aW91cyBkb2N1bWVudHMgYW5kIGF0dGVtcHRzIHRvIGFkZHJlc3MgdGhlIGlzc3VlLg0Kc2VjdGlv biAzLCBNaUZpIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Ygbm92YXRlbCB3aXJlbGVzcyBp biB0aGUNCnVuaXRlZCBzdGF0ZXMgYW5kIHNldmVyYWwgb3RoZXIgbWFya2V0cy4gdGhlIGZ1bmN0 aW9uYWxpdHkgeW91IGFyZQ0KZGVzY3JpYmluZyBpcyB0aGF0IG9mIGEgcm91dGVyIG9yIGRldmlj ZSBzdXBwb3J0aW5nIG1vYmlsZSB0ZWhlcmluZy4NCldoaWxlIEkgcmVjb2duaXplIHRoYXQgc2Vj dGlvbiA1IGlzIGEgc3RhYiBhdCBhIHNlbWFudGljIGFkZHJlc3MNCmFzc2lnbm1lbnQgc2VjdGlv biA2IGVzc2VudGlhbGx5IHJlYnV0cyB0aGUgdXRpbGl0eSBvZiB0aGUgZG9jdW1lbnQgYnkNCnN0 YXRpbmcgdGhhdCB0aGUgcHJvYmxlbSBpcyBub3QgZ2VucmFsaXplYWJsZS4gaW4gdGhlIGV4YW1w bGUgaW4gc2VjdGlvbg0KNSB0aGUgcDEgYml0LWZpZWxkIHdoaWNoIGlzIHRoZSBtb3N0IHNpZ25p ZmljYW50IGJpdHMgaW4gdGhlIHByZWZpeA0KYXNzaWdubWVudCB0byB0aGUgcHJvdmlkZXIsIGlz IHRoZSB0eXBlIGZpZWxkLCBpZiBhIHByb3ZpZGVyIGlzIGFzc2lnbmVkDQphIC8xNiB0aGVuIHlv dSBqdXN0IGJ1cm5lZCBhIC8xOSBvbiBsb29wYmFja3MgYW5kIGludGVyZmFjZSBhZGRyZXNzZXMg aWYNCnlvdSB1c2UgMyBiaXRzIGZvciB0aGUgdHlwZSBmaWVsZCwgd2hpY2ggc2VlbXMgbGlrZSBh IGxvdC4NCg== --=====003_Dragon228565541804_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1nYjIzMTIi IGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD0i TVNIVE1MIDguMDAuNjAwMS4xOTM5NCI+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9udC1mYW1p bHk6IMvOzOU7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFuYTsNCn0NCkBm b250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBAy87M5TsNCn0NCkBwYWdlIFNlY3Rpb24xIHtzaXpl OiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0OyBs YXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRl ci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZP TlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQNCn0NCkxJLk1z b05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1 c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFu IjsgRk9OVC1TSVpFOiAxMC41cHQNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBNQVJHSU46IDBjbSAwY20gMHB0 OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IEZPTlQtU0laRTogMTAuNXB0DQp9DQpB Omxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BB Ti5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGlu ZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglGT05ULVNU WUxFOiBub3JtYWw7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBDT0xPUjogd2luZG93dGV4dDsgRk9O VC1XRUlHSFQ6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28tc3R5bGUtdHlwZTog cGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0KfQ0K VU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsNCglNQVJHSU4tVE9Q OiAwcHg7IE1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLUxFRlQ6IDJlbQ0KfQ0KT0wgew0KCU1B UkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQpVTCB7DQoJTUFSR0lOLVRPUDog MHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBzdHls ZT0iTUFSR0lOOiAxMHB4OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4N CjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj4mbmJz cDtIaSZuYnNwO0pvZWwsPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGFua3MmbmJz cDtmb3ImbmJzcDt5b3VyJm5ic3A7Y29tbWVudHMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5JIGFncmVlIHdpdGggeW91IHRoYXQgdXNpbmcgdGhlIHdvcmQgIk1pRmkiIGlzIG5vdCBn b29kLiBJbiBzZWN0aW9uIDMsIHdoYXQgDQpJIG1lYW4gaGVyZSZuYnNwO2lzIGRldmljZXMgYWxs b3dzIHNoYXJpbmcgdGhlIEludGVybmV0IGNvbm5lY3Rpb24gb2YgdGhlIHBob25lIA0Kb3IgdGFi bGV0IHdpdGggb3RoZXIgZGV2aWNlcyBzdWNoIGFzIGxhcHRvcHMuIDwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+SW4gZmFjdCwgdGhpcyBkcmFmdCBkaXNjdXNzZWQgdGhlIElQdjYgYWRk cmVzcyBwYWxubmluZy4gc2VjdGlvbiANCjUmbmJzcDtnaXZlIGFuIGV4YW1wbGUgdG8gaWxsdXN0 cmF0ZSB0aGUgYWRkcmVzcyBwbGFubmluZywgaW4gdGhlIGV4YW1wbGUsIGhvdyANCm1hbnkgZmll bGRzIHRoZSA2NCBiaXQgY2FuIGJlIGRpdmlkZWQgaW50byZuYnNwOyx0aGUgbGVuZ3RoIGFuZCBt ZWFuaW5nIG9mIGVhY2ggDQpmaWVsZCBzaG91bGQmbmJzcDsmbmJzcDtiZSANCmFzc2lnbmVkJm5i c3A7YWNjb3JkaW5nJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtkZXZlbG9wbWVudCZuYnNwO29mJm5i c3A7c2VydmljZSZuYnNwO2FuZCZuYnNwO3VzZXJzLiANCnNvIEkmbmJzcDsgc3RhdGVkJm5ic3A7 dGhhdCZuYnNwO3RoZSZuYnNwO2Fzc2lnbm1lbnQgJm5ic3A7aXMgDQpub3QmbmJzcDtnZW5yYWxp emVhYmxlIGluIHNlY3Rpb24gNi4gPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGFs c28gdGhpbmsgdGhhdCB1c2luZyAzJm5ic3A7Yml0cyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3R5 cGUmbmJzcDtmaWVsZCANCmlzJm5ic3A7IHRvbyBtdWNoLCZuYnNwO3RoZSBlPFNQQU4gaWQ9cmVz dWx0X2JveCBsYW5nPWVuIGNsYXNzPXNob3J0X3RleHQgDQpjbG9zdXJlX3VpZF80NDc2NDg3Mj0i MTEyIiBtZD0ibnVsbCIgYT0idW5kZWZpbmVkIiBjPSI0Ij48U1BBTiANCmNsb3N1cmVfdWlkXzQ0 NzY0ODcyPSI5MjYiIG1kPSJudWxsIj54dHJhPC9TUEFOPiA8U1BBTiBjbGFzcz1ocHMgDQpjbG9z dXJlX3VpZF80NDc2NDg3Mj0iOTI3IiBtZD0ibnVsbCI+ZmllbGRzPC9TUEFOPiA8U1BBTiBjbGFz cz1ocHMgDQpjbG9zdXJlX3VpZF80NDc2NDg3Mj0iOTI4IiBtZD0ibnVsbCI+Y2FuPC9TUEFOPiA8 U1BBTiBjbGFzcz1ocHMgDQpjbG9zdXJlX3VpZF80NDc2NDg3Mj0iOTI5IiBtZD0ibnVsbCI+YmU8 L1NQQU4+IGNvbnNlcnZlZC4gPC9TUEFOPjxTUEFOIA0KaWQ9cmVzdWx0X2JveCBsYW5nPWVuIGNs b3N1cmVfdWlkXzQ0NzY0ODcyPSIxMTIiIG1kPSJudWxsIiBhPSJ1bmRlZmluZWQiIA0KYz0iNCI+ PFNQQU4gY2xvc3VyZV91aWRfNDQ3NjQ4NzI9IjgwNiIgbWQ9Im51bGwiPkFzPC9TUEFOPiA8U1BB TiBjbGFzcz1ocHMgDQpjbG9zdXJlX3VpZF80NDc2NDg3Mj0iODA3IiBtZD0ibnVsbCI+dGhlPC9T UEFOPiA8U1BBTiBjbGFzcz1ocHMgDQpjbG9zdXJlX3VpZF80NDc2NDg3Mj0iODA4IiBtZD0ibnVs bCI+bnVtYmVyIG9mIHVzZXJzIGluY3JlYXNpbmc8L1NQQU4+PFNQQU4gDQpjbG9zdXJlX3VpZF80 NDc2NDg3Mj0iODA5IiBtZD0ibnVsbCI+LCBzb21lIGZpZWxkczwvU1BBTj4gPFNQQU4gY2xhc3M9 aHBzIA0KY2xvc3VyZV91aWRfNDQ3NjQ4NzI9IjgxMCIgbWQ9Im51bGwiPm1heTwvU1BBTj4gPFNQ QU4gY2xhc3M9aHBzIA0KY2xvc3VyZV91aWRfNDQ3NjQ4NzI9IjgxMSIgbWQ9Im51bGwiPmJlPC9T UEFOPiBub3QgPFNQQU4gY2xhc3M9aHBzIA0KY2xvc3VyZV91aWRfNDQ3NjQ4NzI9IjgxMiIgbWQ9 Im51bGwiPmVub3VnaDwvU1BBTj48U1BBTiANCmNsb3N1cmVfdWlkXzQ0NzY0ODcyPSI4MTMiIG1k PSJudWxsIj4sPC9TUEFOPiA8U1BBTiBjbGFzcz1ocHMgDQpjbG9zdXJlX3VpZF80NDc2NDg3Mj0i ODE0IiBtZD0ibnVsbCI+dGhlIGNvbnNlcnZlZCBmaWVsZHM8L1NQQU4+IDxTUEFOIGNsYXNzPWhw cyANCmNsb3N1cmVfdWlkXzQ0NzY0ODcyPSI4MTUiIG1kPSJudWxsIj5jYW4gYmUgdXNlZCBmb3I8 L1NQQU4+PFNQQU4gY2xhc3M9aHBzIA0KY2xvc3VyZV91aWRfNDQ3NjQ4NzI9IjgxNiIgbWQ9Im51 bGwiPiBleHBhbnNpb24gaW4gdGhlIA0KZnV0dXJlLjwvU1BBTj48L1NQQU4+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXpl PTIgZmFjZT1WZXJkYW5hPkJlc3Qgd2lzaGVzITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+ TWEgUWlvbmdmYW5nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9 MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBj MGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxMy0wMi0yMCA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpj b2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMDBw eCIgYWxpZ249bGVmdCBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCjwvRk9OVD4NCjxESVY+PEZPTlQg Y29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTUEFOPg0KPERJVj48Rk9OVCBmYWNl PbuqzsTW0MvOPg0KPERJVj48L0ZPTlQ+PEZPTlQgc2l6ZT0zPjxGT05UIA0KZmFjZT3LzszlPjwv Rk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9ESVY+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxIUiBj b2xvcj0jYjVjNGRmIFNJWkU9MT4NCg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxT VFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gam9lbCBqYWVnZ2xpIDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPreiy83Ksbzko7o8L1NUUk9ORz4gMjAx My0wMi0yMCZuYnNwOyAxNjoxMzo1OCANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y IGZhY2U9VmVyZGFuYT48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IG1hcWlvbmdmYW5nOyANCmZy ZWRAY2lzY28uY29tOyBkcmFmdC1tYS12Nm9wcy1pcHY2LWFkZHJlc3MtYXNzaWdubWVudCA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz6zrcvNo7o8 L1NUUk9ORz4gdjZvcHMtY2hhaXJzOyBJUHY2IE9wcyBXRyANCjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPtb3zOKjujwvU1RST05HPiBSZTogU29t ZSBxdWVzdGlvbnMgb24gDQpkcmFmdC1tYS12Nm9wcy1pcHY2LWFkZHJlc3MtYXNzaWdubWVudCA8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiA8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+T24mbmJzcDsyLzE5LzEz Jm5ic3A7MTE6MDkmbmJzcDtQTSwmbmJzcDttYXFpb25nZmFuZyZuYnNwO3dyb3RlOjwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7RGVhciZuYnNwO2FsbCw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1dlJm5i c3A7aGF2ZSZuYnNwO3Bvc3RlZCZuYnNwO2EmbmJzcDtkcmFmdCZuYnNwO2Fib3V0Jm5ic3A7SVB2 NiZuYnNwO2FkZHJlc3MmbmJzcDtwbGFubmluZyZuYnNwO2luJm5ic3A7dGhlJm5ic3A7b3BlcmF0 b3I8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO25ldHdvcmssJm5ic3A7YXQmbmJzcDtodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYS12Nm9wcy1pcHY2LWFkZHJlc3MtYXNzPC9ESVY+DQo8 RElWPiZndDsmbmJzcDtwbGVhc2UmbmJzcDttYWtlJm5ic3A7c29tZSZuYnNwO2NvbW1lbnRzLiZu YnNwO3RoYW5rcyE8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlNvbWUmbmJzcDt0aG91Z2h0cy48 L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlNvLCZuYnNwO3RoaXMmbmJzcDtpcyZuYnNwO3ByZXR0 eSZuYnNwO3dlbGwmbmJzcDt0cmF2ZXJzZWQmbmJzcDtncm91bmQmbmJzcDthbHJlYWR5LiZuYnNw O2F0Jm5ic3A7YSZuYnNwO21pbmltdW0mbmJzcDthPC9ESVY+DQo8RElWPmRvY3VtZW50Jm5ic3A7 d2FkaW5nJm5ic3A7aW50byZuYnNwO2FyZWEmbmJzcDtzaG91bGQmbmJzcDtjaGFyYWN0ZXJpemUm bmJzcDt3aHkmbmJzcDtpdCZuYnNwO2lzJm5ic3A7ZGlmZmVyZW50Jm5ic3A7dGhhbjwvRElWPg0K PERJVj50aGUmbmJzcDtwcmV2aW91cyZuYnNwO2RvY3VtZW50cyZuYnNwO2FuZCZuYnNwO2F0dGVt cHRzJm5ic3A7dG8mbmJzcDthZGRyZXNzJm5ic3A7dGhlJm5ic3A7aXNzdWUuPC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj5zZWN0aW9uJm5ic3A7MywmbmJzcDtNaUZpJm5ic3A7aXMmbmJzcDthJm5i c3A7cmVnaXN0ZXJlZCZuYnNwO3RyYWRlbWFyayZuYnNwO29mJm5ic3A7bm92YXRlbCZuYnNwO3dp cmVsZXNzJm5ic3A7aW4mbmJzcDt0aGU8L0RJVj4NCjxESVY+dW5pdGVkJm5ic3A7c3RhdGVzJm5i c3A7YW5kJm5ic3A7c2V2ZXJhbCZuYnNwO290aGVyJm5ic3A7bWFya2V0cy4mbmJzcDt0aGUmbmJz cDtmdW5jdGlvbmFsaXR5Jm5ic3A7eW91Jm5ic3A7YXJlPC9ESVY+DQo8RElWPmRlc2NyaWJpbmcm bmJzcDtpcyZuYnNwO3RoYXQmbmJzcDtvZiZuYnNwO2EmbmJzcDtyb3V0ZXImbmJzcDtvciZuYnNw O2RldmljZSZuYnNwO3N1cHBvcnRpbmcmbmJzcDttb2JpbGUmbmJzcDt0ZWhlcmluZy48L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPldoaWxlJm5ic3A7SSZuYnNwO3JlY29nbml6ZSZuYnNwO3RoYXQm bmJzcDtzZWN0aW9uJm5ic3A7NSZuYnNwO2lzJm5ic3A7YSZuYnNwO3N0YWImbmJzcDthdCZuYnNw O2EmbmJzcDtzZW1hbnRpYyZuYnNwO2FkZHJlc3M8L0RJVj4NCjxESVY+YXNzaWdubWVudCZuYnNw O3NlY3Rpb24mbmJzcDs2Jm5ic3A7ZXNzZW50aWFsbHkmbmJzcDtyZWJ1dHMmbmJzcDt0aGUmbmJz cDt1dGlsaXR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtkb2N1bWVudCZuYnNwO2J5PC9ESVY+DQo8 RElWPnN0YXRpbmcmbmJzcDt0aGF0Jm5ic3A7dGhlJm5ic3A7cHJvYmxlbSZuYnNwO2lzJm5ic3A7 bm90Jm5ic3A7Z2VucmFsaXplYWJsZS4mbmJzcDtpbiZuYnNwO3RoZSZuYnNwO2V4YW1wbGUmbmJz cDtpbiZuYnNwO3NlY3Rpb248L0RJVj4NCjxESVY+NSZuYnNwO3RoZSZuYnNwO3AxJm5ic3A7Yml0 LWZpZWxkJm5ic3A7d2hpY2gmbmJzcDtpcyZuYnNwO3RoZSZuYnNwO21vc3QmbmJzcDtzaWduaWZp Y2FudCZuYnNwO2JpdHMmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3ByZWZpeDwvRElWPg0KPERJVj5h c3NpZ25tZW50Jm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtwcm92aWRlciwmbmJzcDtpcyZuYnNwO3Ro ZSZuYnNwO3R5cGUmbmJzcDtmaWVsZCwmbmJzcDtpZiZuYnNwO2EmbmJzcDtwcm92aWRlciZuYnNw O2lzJm5ic3A7YXNzaWduZWQ8L0RJVj4NCjxESVY+YSZuYnNwOy8xNiZuYnNwO3RoZW4mbmJzcDt5 b3UmbmJzcDtqdXN0Jm5ic3A7YnVybmVkJm5ic3A7YSZuYnNwOy8xOSZuYnNwO29uJm5ic3A7bG9v cGJhY2tzJm5ic3A7YW5kJm5ic3A7aW50ZXJmYWNlJm5ic3A7YWRkcmVzc2VzJm5ic3A7aWY8L0RJ Vj4NCjxESVY+eW91Jm5ic3A7dXNlJm5ic3A7MyZuYnNwO2JpdHMmbmJzcDtmb3ImbmJzcDt0aGUm bmJzcDt0eXBlJm5ic3A7ZmllbGQsJm5ic3A7d2hpY2gmbmJzcDtzZWVtcyZuYnNwO2xpa2UmbmJz cDthJm5ic3A7bG90LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+PC9GT05UPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon228565541804_=====-- From bingxuere@gmail.com Wed Feb 20 01:59: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 92DC221F8700 for ; Wed, 20 Feb 2013 01:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKIOAw-xo5X6 for ; Wed, 20 Feb 2013 01:59:59 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id EC80421F8702 for ; Wed, 20 Feb 2013 01:59:58 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id uz6so7456305obc.6 for ; Wed, 20 Feb 2013 01:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=G7MCYxw+V93cdbnPdZKKpIGghEynJTzumlkF5DgVfXo=; b=Dk9smzZot2VnydlvvMv+WysGJiQl56sI1BBSETXL7yS+0idyo6ZiCFs/mdmPatBOxJ nKggJ8tBYzH05x2dcCkDOzlTcqTQZKHBEmDMFKkH4MuOM6hphz7RIW/l8Tj0hzbHjHvz aM2lExVLCHU692RKSpU+NywvDkMUKWuHYHSChk01J9uRRU8YUlSLo2MRr11alSx70vF9 yDLG/y5RFebfBIekhcXYhlXk0X9wLkgxOKSLmQoOQE9xvj6zRAiiA2cI5cdaEINsv3SN 2TNhtoFprXG4FiAVpm3NahkkWY0pdUchqUDazH88jimM4BvhtUsqG+EY50iqtjePVu/y GnUA== X-Received: by 10.182.157.104 with SMTP id wl8mr3678302obb.79.1361354398557; Wed, 20 Feb 2013 01:59:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Wed, 20 Feb 2013 01:59:17 -0800 (PST) In-Reply-To: <51232CA8.9070204@bogus.com> References: <201302171345.r1HDj0I02968@ftpeng-update.cisco.com> <51217464.5030507@bogus.com> <51232CA8.9070204@bogus.com> From: Qiong Date: Wed, 20 Feb 2013 17:59:17 +0800 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=f46d044281a056e56d04d6250520 Cc: draft-sun-v6ops-semantic-usecase , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 09:59:59 -0000 --f46d044281a056e56d04d6250520 Content-Type: text/plain; charset=UTF-8 Hi Joel, Please see inline :) On Tue, Feb 19, 2013 at 3:41 PM, joel jaeggli wrote: > On 2/18/13 6:44 AM, Qiong wrote: > >> Hi Joel, >> >> Thanks for your comments. >> >> I agree with you semantic prefix will have limitations in real world >> deployment. We will improve the limitation part and clearly clarify the >> scope for which operators should take in the next version. >> >> I particular I think it would be particularly undesirable but from a > policy and address assignment perspective if providers were to up the size > of their assignment requests using a justification of more semantic bits > required. Where does that thought experiemnt end? > [Qiong] Sorry I do not quite understand your meaning. Do you mean operators may ask more semantic bits from address assignment community ? Our major purpose is to decide how to design the IPv6 prefix when the operator has already get the IPv6 address pool. It is mainly used within a local region. Would you please explain a bit more ? Thanks in advance! Best wishes Qiong --f46d044281a056e56d04d6250520 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

Please see inline :)
On Tue, Feb 19, 2013 at 3:41 PM, joel jaeggli <= span dir=3D"ltr"><= joelja@bogus.com> wrote:
On 2/18/13 6:44 AM, Qiong = wrote:
Hi Joel,

Thanks for your comments.

I agree with you semantic prefix will have limitations in real world deploy= ment. We will improve the limitation part and clearly clarify the scope for= which operators should take in the next version.

I particular =C2=A0I think it would be particularly undesirable but from a = policy and address assignment perspective if providers were to up the size = of their assignment requests using a justification of more semantic bits re= quired. Where does that thought experiemnt end?
[Qiong] Sorry I do not quite understand your meanin= g. Do you mean operators may ask more semantic bits from address assignment= community ? Our major purpose is to decide how to design the IPv6 prefix w= hen the operator has already get the IPv6 address pool. It is mainly used w= ithin a local region. Would you please explain a bit more ?

Thanks in advance!

Best wishes
Qiong
--f46d044281a056e56d04d6250520-- From ales.vizdal@t-mobile.cz Wed Feb 20 08:00: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 6085021F883B for ; Wed, 20 Feb 2013 08:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3SdEBJkzwSy for ; Wed, 20 Feb 2013 08:00:53 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8A73C21F86A1 for ; Wed, 20 Feb 2013 08:00:52 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 6562F2857E3; Wed, 20 Feb 2013 17:00:50 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 20 Feb 2013 17:00:50 +0100 From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: Shishio Tsuchiya Date: Wed, 20 Feb 2013 17:00:51 +0100 Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: Ac4OuO/R+XCN2OjPToimS8xfpktbSQAyS67w Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> In-Reply-To: <51239D09.10305@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 16:00:54 -0000 U2hpc2hpbywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaGlzaGlv IFRzdWNoaXlhIFttYWlsdG86c2h0c3VjaGlAY2lzY28uY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBG ZWJydWFyeSAxOSwgMjAxMyA0OjQxIFBNDQo+IFRvOiBWw616ZGFsIEFsZcWhDQo+IENjOiB2Nm9w c0BpZXRmLm9yZzsgZHJhZnQtc2hpc2hpby12Nm9wcy1kcHZ0QHRvb2xzLmlldGYub3JnOyBzaHRz dWNoaUBjaXNjby5jb20NCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1z aGlzaGlvLXY2b3BzLWRwdnQNCj4gDQo+IEFsZXMNCj4gVGhhbmsgZm9yIHlvdXIgaW50ZXJlc3Qu DQo+IEFzIEkgZGVzY3JpYmVkIHJlcGx5IHRvIEZyZWQsDQoNCldoYXQgeW91J3ZlIHJlc3BvbmRl ZCB0byBpcyBhIGRlZmF1bHQgZW1haWwgdGhhdCBpcyBzZW5kIHRvIHRoZSBhdXRob3JzIGJ5IHRo ZSB0cmFja2VyIA0Kb25jZSBhIG5ldyBkcmFmdCBpcyBwb3N0ZWQuDQoNCj4gVGhlIHN0YXRlbGVz cyB0dW5uZWwgYW5kIHByZWZpeCBkZWxlZ2F0aW9uIHRlY2hub2xvZ3kgcHJvdmlkZXMgbXVjaCBz Y2FsYWJpbGl0eQ0KPiBuZXR3b3JrIHRvIHRoZSBjdXN0b21lci4NCj4gT24gb25lIGhhbmQsIHRo ZXNlIHRlY2hub2xvZ2llcyBhcmUgZGlmZmljdWx0IHRvIHBsYW4gYWRkaXRpb25hbCBjYXBhY2l0 eSBhbmQgaGFyZCB0bw0KPiBrbm93IGN1cnJlbnQgZGVwbG95bWVudA0KPiBzdGF0dXMgdW5sZXNz IHRoZSBkZXZpY2VzIGFyZSBjb21wbGV0ZWx5IG1hbmFnZWQuDQo+IElmIHRoZSBCUiBoYXMgc3Rh dGUgYW5kIERIQ1B2NiBzZXJ2ZXIga25vd3MgZGV0YWlsIHJvdXRlLHRoZW4gdGhlIG1lcml0IG9m IHRoZXNlDQo+IHRlY2hub2xvZ2llcyB3b3VsZCBiZSBkaXNhcHBlYXJlZC4NCg0KTGV0J3MgdGFr ZSB0aGUgREhDUC1QRCBjYXNlLCBJIGFzc3VtZSB0aGF0IHRoZSBJUCByZXNvdXJjZSBwbGFubmlu ZyBnb2VzIGhhbmQgaW4gaGFuZCANCndpdGggdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyB0aGUg SVNQIGlzIGV4cGVjdGluZyB0byBzZXJ2ZS4gVGhlIG9wZXJhdG9yIG5lZWRzIHRvIGRlY2lkZSAN Cm9uIHRoZSBwcmVmaXgtbGVuZ3RoIHRvIGJlIGRlbGVnYXRlZCBkb3duIHRvIHRoZSBzdWJzY3Jp YmVyIGFuZCB0aGF0J3MgaXQsIHNvIHRoZXkgY2FuDQpwbGFuIGVub3VnaCBwcmVmaXhlcyBwZXIg YWNjZXNzIGFyZWEuIFRoZSBvcGVyYXRvciBkb2VzIG5vdCBuZWVkIHRvIGtub3cgaWYvaG93IEkg YW0gdXNpbmcgDQpteSBkZWxlZ2F0ZWQgcHJlZml4LiBUaGV5IHNob3VsZCBiZSBoYXBweSB0byBn aXZlL3NlbGwgbWUgYW5vdGhlciBwcmVmaXggaWYgbmVlZGVkLiANCg0KQ2FuIHlvdSBwbGVhc2Ug Y2xhcmlmeSB3aGF0J3MgdGhlIGJlbmVmaXQgZnJvbSBPcGVyYXRvcidzIHBvaW50IG9mIHZpZXc/ DQoNCj4gU28gSSB0aG91Z2h0IHRoZXNlIHRlY2hub2xvZ2llcyBuZWVkIHNtYWxsIG9hbSB0b29s cy4NCj4gDQo+IC1jb25maXJtIG9ubHkgaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24gZnJvbSBJU1Ag c2lkZQ0KPiAtY29uZmlybSByZWFjaGFiaWxpdHkgbm90IHVzZSBlbmQgdG8gZW5kDQo+IA0KPiBJ IHdvdWxkIGFwcHJlY2lhdGUgYW55IGNvbW1lbnQuDQo+IA0KPiBSZWdhcmRzLA0KPiAtU2hpc2hp bw0KDQpDaGVlcnMsDQpBbGVzDQo= From owen@delong.com Wed Feb 20 09:01: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 0FFC521E803D for ; Wed, 20 Feb 2013 09:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.304 X-Spam-Level: * X-Spam-Status: No, score=1.304 tagged_above=-999 required=5 tests=[AWL=-1.097, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBcFVzlq7Obw for ; Wed, 20 Feb 2013 09:01:25 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A94A821F8836 for ; Wed, 20 Feb 2013 09:01:23 -0800 (PST) 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 r1KGtTrd029187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2013 08:55:29 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1KGtTrd029187 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361379330; bh=BBUqUBiH0PqNG81i6t5CRtqRlzc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=T/loYyV5ZR4Y3RPlG4H/pyYs7FdRkAan7FlMns1A+ceOfMRwwNKeCdNJd0rEZYhK5 KLc8byiHTSK78DZNy6V93DGsd1+P2r6l7Y57LTDRHzIk0n1dnvIj0CIz0mGLdsyn7s 1UXSoaiG8bXFPbQry72vEdUAtLuqmn+p1jHBn7ec= Content-Type: multipart/alternative; boundary="Apple-Mail=_C3F89C81-715C-42F4-851F-40143806E94A" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <512485CC.5010102@bogus.com> Date: Wed, 20 Feb 2013 08:55:28 -0800 Message-Id: <7D525337-B6C9-40D5-BF24-CC1C1E56A2B7@delong.com> References: <201302201509342346215@chinamobile.com> <512485CC.5010102@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Feb 2013 08:55:30 -0800 (PST) Cc: IPv6 Ops WG , v6ops-chairs , draft-ma-v6ops-ipv6-address-assignment Subject: Re: [v6ops] Some questions on 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: Wed, 20 Feb 2013 17:01:27 -0000 --Apple-Mail=_C3F89C81-715C-42F4-851F-40143806E94A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Summary: As written, I cannot support this draft. It is divergent from what I = have come to believe are the best practices for numbering IPv6 networks. This = document seems to incorporate a significant amount of IPv4-think and = over-conservative granularity in the initial sections, while providing contradictory and = confusing advice in section 5. A more detailed description of my concerns: Section 2 (3) I am unclear what you mean by the second bullet point. Section 2(4) is similarly unclear to me. Section 3 makes no allowance for the benefits of providing a uniform = assignment size to all subscribers. There is nothing wrong with assigning a /48 to each = end-site and no reason to discourage this practice. Section 3(2) should be rewritten replacing MiFi with "Mobile Hotspot or = other portable on-demand router technology". I do not agree that such a device should = receive only a /60. I would support rewording to "at least a /60 and no more than a = /48." Section 3(3) I do not agree with limiting broadband CPE to /56. There is = no reason not to assign these devices a /48. I could accept tis draft if it were = reworded to "at least a /56 and no more than a /48." Section 3(4) should be reworded to "a /48 per end-site where an end-site = is a single structure, building, or tenant in a multi-tenant structure or = building". There is no reason to count hosts in IPv6 and these words should be = removed. In IPv6, we should be counting subnets, not hosts. Section 3(5) should be rewritten as "Loopback interfaces requiring = public addresses should, generally be assigned a /128. In certain applications, a shorter = prefix may be necessary or desirable." Section 3(6) is very poorly constructed and implies that a datacenter = should assign a /127 to each server and connect each server separately to its upstream = router. While assigning /127s to point to point links can be an expediency to = work around certain security issues today, I do not support codifying it as a = permanent=20 recommendation. Rather I would prefer to see "Point to point links = should be assigned /64s, though it may be desirable to configure them as /127s to = work around certain security concerns." or words to that effect. Section 4 paragraph 3 you have reversed LAN and WAN. The WAN requires a /64 (or a /127) and the LAN requires a /48 (or less). Further, = computing the address pool as a combined total may not always yield optimal = results. There are good reasons to aggregate the LAN and WAN segments separately in many cases as the WAN segments may be better aggregated across multiple BRAS in a serving center, while each BRAS should have its own aggregate pool of LAN addresses to allocate to subscribers. Further, I believe it is good practice to round such pool assignments up to the = next nibble boundary which is neglected in this paragraph. A suggested = rewrite: The calculation of address pool in a broadband access server such as a BRAS or CMTS is slightly more complicated. In the broadband network, assume that user capacity configured in a BRAS is roughly 30 thousand end-sites. Each end site needs a prefix from which LAN segments can be assigned and a WAN interface address. The WAN interface numbering must be deployed on both the CPE and the provider's access gear and a single WAN interface prefix may be shared among multiple subscribers. In the case where each WAN segment contains a single subscriber, each segment should receive a /64. In the case where multiple subscribers share a single segment, a single /64 should be used for each shared segment. Each subscriber should receive a /48 (or longer) prefix. The sum of the expected number of prefixes (30 thousand in this case) should be calculated as a number of bits (30,000 would round up to 32768 or 15 bits) and rounded up to a multiple of four (16 bits in this case). This number should then be subtracted from the largest prefix size to be issued (/48 for example would yield a /32). The number of WAN segments should be similarly calculated as a number of /64s (for example, let's say we put 200 subscribers on a given WAN segment), this would be 30,000/200=3D150 /64s or 8 bits. Since 8 is already a multiple of 4, no additional rounding=20 is required. 64-8 is 56, so a /56 is required for WAN segments. Thus, the example broadband server would receive a /32 for subscriber addressing and a /56 for WAN segment numbering. Section 5, it should be made clear that this is just one example of one way to carve up addresses and may not be applicable to all networks. In fact, I would argue that placing "type" at the highest level of = aggregation may be very undesirable in most deployments. The assumption that all persons reading this document will receive their global prefix from an LIR is also incorrect. Many will be = receiving directly from an RIR or (in AP region, NIR). I have never seen a network where setting aside 1/2 of the address space for network infrastructure and leaving only 1/2 of the address space for customer assignments makes any sense at all. Thus, I do not think that your P0 type flag description is supportable. Further, it may not be desirable to use uniform sizes for all divisions at this first level. Often, for example, it may be desirable to set = aside a chunk of address space for all oeprational infrastructure separate from the address space used to meet client needs. For example, let us consider a small ISP which has received 2001:db8::/32 from its RIR. It is common practice for such an ISP to take the first /48 (2001:db8:0::/48 (or 2001:db8::/48)) for use in numbering its infrastructure. It may take an additional /48 per manned site for its own internal IT usage. =46rom within the first /48, networks would be created for DNS servers, network device loopback addressing, web servers, DHCP servers, etc. Your explanation of the P2 field is vague. A better description might be that P2 is used to number separate instantiations of the types of networks numbered in P1. In some cases, this may indicate a subtype (extending the proposed metaphor). P3 and P4 descriptions imply that geographical aggregation is preferable to topological aggregation. I believe this is entirely false and I would suggest that the terms Province and City be replaced with the terms "Topological Region and "Serving Site", respectively. In P5, the term city should similarly be replaced with "Serving Site". Section 7, I believe there are no security conisderations applicable to address assignment beyond those described above. Section 8, I don't see any IANA implications to this set of recommended addressing practices. Owen --Apple-Mail=_C3F89C81-715C-42F4-851F-40143806E94A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
on-demand router technology". I do not agree that = such a device should receive only
a /60. I would support = rewording to "at least a /60 and no more than a = /48."

Section 3(3) I do not agree with limiting = broadband CPE to /56. There is no reason
not to assign these = devices a /48. I could accept tis draft if it were reworded = to
"at least a /56 and no more than a = /48."

Section 3(4) should be reworded to "a /48 = per end-site where an end-site is
a single structure, = building, or tenant in a multi-tenant structure or = building".
There is no reason to count hosts in IPv6 and these = words should be removed.
In IPv6, we should be counting = subnets, not hosts.

Section 3(5) should be = rewritten as "Loopback interfaces requiring public = addresses
should, generally be assigned a /128. In certain = applications, a shorter prefix may
be necessary or = desirable."

Section 3(6) is very poorly = constructed and implies that a datacenter should assign
a /127 = to each server and connect each server separately to its upstream = router.
While assigning /127s to point to point links can be = an expediency to work around
certain security issues today, I = do not support codifying it as a = permanent 
recommendation. Rather I would prefer to see = "Point to point links should be
assigned /64s, though it may = be desirable to configure them as /127s to work
around certain = security concerns." or words to that = effect.

Section 4 paragraph 3 you have reversed = LAN and WAN. The WAN requires
a /64 (or a /127) and the LAN = requires a /48 (or less). Further, computing
the address pool = as a combined total may not always yield optimal = results.
There are good reasons to aggregate the LAN and WAN = segments separately
in many cases as the WAN segments may be = better aggregated across
multiple BRAS in a serving center, = while each BRAS should have its own
aggregate pool of LAN = addresses to allocate to subscribers. Further, I
believe it is = good practice to round such pool assignments up to the = next
nibble boundary which is neglected in this paragraph. A = suggested rewrite:

The calculation of address = pool in a broadband access server such
as a BRAS or CMTS is = slightly more complicated. In the broadband
network, assume = that user capacity configured in a BRAS is
roughly 30 thousand = end-sites. Each end site needs a prefix from
which LAN = segments can be assigned and a WAN interface address.
The WAN = interface numbering must be deployed on both the CPE and
the = provider's access gear and a single WAN interface prefix may = be
shared among multiple subscribers. In the case where each = WAN
segment contains a single subscriber, each segment should = receive
a /64. In the case where multiple subscribers share a = single segment,
a single /64 should be used for each shared = segment. Each
subscriber should receive a /48 (or longer) = prefix. The sum of the
expected number of prefixes (30 = thousand in this case) should be
calculated as a number of = bits (30,000 would round up to 32768
or 15 bits) and rounded = up to a multiple of four (16 bits in this
case). This number = should then be subtracted from the largest
prefix size to be = issued (/48 for example would yield a /32).
The number of = WAN segments should be similarly calculated
as a number of = /64s (for example, let's say we put 200 subscribers
on a given = WAN segment), this would be 30,000/200=3D150 /64s
or 8 bits. = Since 8 is already a multiple of 4, no additional = rounding 
is required. 64-8 is 56, so a /56 is required = for WAN segments.
Thus, the example broadband server would = receive a /32 for
subscriber addressing and a /56 for WAN = segment numbering.

Section 5, it = should be made clear that this is just one example of one
way = to carve up addresses and may not be applicable to all = networks.
In fact, I would argue that placing "type" at the = highest level of aggregation
may be very undesirable in most = deployments.

The assumption that all persons = reading this document will receive
their global prefix from an = LIR is also incorrect. Many will be receiving
directly from an = RIR or (in AP region, NIR).

I have never seen a = network where setting aside 1/2 of the address
space for = network infrastructure and leaving only 1/2 of the = address
space for customer assignments makes any sense at all. = Thus, I
do not think that your P0 type flag description is = supportable.

Further, it may not be desirable = to use uniform sizes for all divisions
at this first level. = Often, for example, it may be desirable to set aside
a chunk = of address space for all oeprational infrastructure = separate
from the address space used to meet client needs. For = example,
let us consider a small ISP which has received = 2001:db8::/32
from its RIR. It is common practice for such an = ISP to take the
first /48 (2001:db8:0::/48 (or 2001:db8::/48)) = for use in numbering
its infrastructure. It may take an = additional /48 per manned site
for its own internal IT = usage. =46rom within the first /48, networks
would be created = for DNS servers, network device loopback
addressing, web = servers, DHCP servers, etc.

Your explanation of = the P2 field is vague. A better description
might be that P2 = is used to number separate instantiations
of the types of = networks numbered in P1. In some cases, this
may indicate a = subtype (extending the proposed metaphor).

P3 = and P4 descriptions imply that geographical aggregation
is = preferable to topological aggregation. I believe this = is
entirely false and I would suggest that the terms = Province
and City be replaced with the terms "Topological = Region
and "Serving Site", = respectively.

In P5, the term city should = similarly be replaced with = "Serving
Site".

Section 7, I believe = there are no security conisderations
applicable to address = assignment beyond those = described
above.

Section 8, I don't = see any IANA implications to this set of
recommended = addressing = practices.



Owen


= --Apple-Mail=_C3F89C81-715C-42F4-851F-40143806E94A-- From markzzzsmith@yahoo.com.au Wed Feb 20 11:27: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 8019B21F8904 for ; Wed, 20 Feb 2013 11:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGZTZdzOJXXG for ; Wed, 20 Feb 2013 11:27:57 -0800 (PST) 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 SMTP id 9FE1D21F892F for ; Wed, 20 Feb 2013 11:27:57 -0800 (PST) Received: from [98.139.212.144] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 19:27:57 -0000 Received: from [98.139.212.213] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 19:27:57 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 19:27:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 58698.86168.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 49433 invoked by uid 60001); 20 Feb 2013 19:27:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361388476; bh=lozcSAO+NuqbVJpwZ/RrlRIomjYhD6gkgFh3PLdHDcE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qXBNfEoyhy5kTkKD8dlYLBHJuB1v36BynQSpKwkPxdPJNbNDYv3lVHOGvSSxu/chmCFT68ldu048IdVOrZ6CLDWvXfmJoEuL9i2QoV9uUfvSoeXMjI1JGGyQSRTUWtsbmlakG3nlL2LiIj4EYu2T4bClkOgS5h1T16uoefae6v0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x+wB4tSSavYYIElQ5yt++XmfwbX8XyVypJ5qd+r23CVkBuzn7pLeNkk27sZJQVbSkMjLffh2Dijk1JlwBrDPShC5qGyFHyFDmJr57aTZ2G8g1HNk8lpUJvx4HnmrLCG4w0KaeFAelmPP2+66SMto2UpHkFs/UwS9ccQh1qMbtaQ=; X-YMail-OSG: Tu4ZVy8VM1mI8mA2LNaRBu722G9.gal4bF3ONRftdVOZ_HQ zaiL_0mLcviAPkZsdc1jFlE1KVSfUOuJrdWgzW.Budb69PKCJF5z3KL5oFSo WeXl662.L3tSAHF5HFoJ8UgRw4DuhuOnEV_dTs.HUadkeic3_6xg9.OA.FVG 2qPteKevRSgcb1xW2K4L0kjM5TxjTL6Apy6Ots3Mq_tiXXwSNpgDeLbLVnUp MuBkF67_nB_fgCWrxXtGkKlfwVY5zeS3VlyilMtAG6CS0rihEgnMA9xqWitY kKJs2buq2mKY6ZO4BnFcSlWg6aXl7oarFciF0ilGdOyuH9cTLvE_zzpLZTCZ 3Or9AJMX1GWe.kBnl.I6sMi93LgJShwaLfaemuMq2YH5x7PMpMu3B3wxYAhu YsLbd9gTcUIWOCLEEuLikbxofST8SnYg99MXGh0Un1gqjG383.SvsieQQJ4_ FouYow_Su1vDKj4pVH8bfaPnRRrxBCtO_30ipJRf_m_buKpblja4HzRLEVdc XySRS91yiPlt9r7o4awCdDYI- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Wed, 20 Feb 2013 11:27:56 PST X-Rocket-MIMEInfo: 001.001, SGksCgpIZXJlIGlzIGEgbmV3IHZlcnNpb24gb2YgbXkgbGFyZ2VyIElQdjYgbG9vcGJhY2sgcHJlZml4IGRyYWZ0LiBDaGFuZ2VzIHNpbmNlIHRoZSBsYXN0IHZlcnNpb24gYXJlIHJlbGF0aXZlbHkgbWlub3I6CgrCoCDCoG8gwqB1c2FiaWxpdHkgcmVmZXJlbmNlcyAoRE9FVCBhbmQgRUFTWS1OVU1CRVJTKQrCoArCoCDCoG8gwqBtaW5vciBjbGFyaWZpY2F0aW9ucwrCoArCoCDCoG8gwqBncmFtbWFyIGNvcnJlY3Rpb25zCgpGdXJ0aGVyIHJldmlldyB3ZWxjb21lIGFuZCBhcHByZWNpYXRlZC4KClJlZ2FyZHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> Message-ID: <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 11:27:56 -0800 (PST) From: Mark Smith To: v6ops v6ops WG In-Reply-To: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:27:58 -0000 Hi,=0A=0AHere is a new version of my larger IPv6 loopback prefix draft. Cha= nges since the last version are relatively minor:=0A=0A=A0 =A0o =A0usabilit= y references (DOET and EASY-NUMBERS)=0A=A0=0A=A0 =A0o =A0minor clarificatio= ns=0A=A0=0A=A0 =A0o =A0grammar corrections=0A=0AFurther review welcome and = appreciated.=0A=0ARegards,=0AMark.=0A=0A=0A----- Forwarded Message -----=0A= > From: "internet-drafts@ietf.org" =0A> To: markz= zzsmith@yahoo.com.au=0A> Cc: =0A> Sent: Thursday, 21 February 2013 6:17 AM= =0A> Subject: New Version Notification for draft-smith-v6ops-larger-ipv6-lo= opback-prefix-04.txt=0A> =0A> =0A> A new version of I-D, draft-smith-v6ops-= larger-ipv6-loopback-prefix-04.txt=0A> has been successfully submitted by M= ark Smith and posted to the=0A> IETF repository.=0A> =0A> Filename:=A0=A0= =A0 draft-smith-v6ops-larger-ipv6-loopback-prefix=0A> Revision:=A0=A0=A0 = 04=0A> Title:=A0=A0=A0 =A0=A0=A0 A Larger Loopback Prefix for IPv6=0A> Cre= ation date:=A0=A0=A0 2013-02-20=0A> Group:=A0=A0=A0 =A0=A0=A0 Individual = Submission=0A> Number of pages: 12=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A> htt= p://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback-pre= fix-04.txt=0A> Status:=A0 =A0 =A0 =A0 =A0 =0A> http://datatracker.ietf.org/= doc/draft-smith-v6ops-larger-ipv6-loopback-prefix=0A> Htmlized:=A0 =A0 =A0 = =A0 =0A> http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-= prefix-04=0A> Diff:=A0 =A0 =A0 =A0 =A0 =A0 =0A> http://www.ietf.org/rfcdiff= ?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback-prefix-04=0A> =0A> Abstract:= =0A> =A0 During the development and testing of a network application, it c= an=0A> =A0 be useful to run multiple instances of the application using th= e same=0A> =A0 transport layer protocol port on the same development host,= while=0A> =A0 also having network access to the application instances lim= ited to=0A> =A0 the local host.=A0 Under IPv4, this has commonly been poss= ible by using=0A> =A0 different loopback addresses within 127/8.=A0 It is = not possible under=0A> =A0 IPv6, as the loopback prefix of ::1/128 only pr= ovides a single=0A> =A0 loopback address.=A0 This memo proposes a new larg= er loopback prefix=0A> =A0 that will provide many IPv6 loopback addresses.= =A0 The processing rules=0A> =A0 for this new larger loopback prefix also = allow sending or forwarding=0A> =A0 of packets containing these addresses = beyond the originating router=0A> =A0 under certain circumstances.=0A> =0A= > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =0A> =A0 =0A> =0A> =0A> The IETF Secretariat=0A> From owen@delong.com Wed Feb 20 11:40: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 C72CF21E803F for ; Wed, 20 Feb 2013 11:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=1.469, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4OLxN+Zb88N for ; Wed, 20 Feb 2013 11:40:48 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC7A21E803C for ; Wed, 20 Feb 2013 11:40:47 -0800 (PST) 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 r1KJbjt9001737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2013 11:37:45 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1KJbjt9001737 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361389065; bh=trCemB1ycX5k2XQWLDLhwNXwH+Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iJYXwKv9YdwLblgx6EK1Z2RL1XDBYRN7e/1tDaHvc4wouv422/fVA6q0GvhquGJz1 gs6h3lRcVx2rnwubZQgIC0jAwtHbh2SjDa8BLCvMTCw149utvlGL8X5WOhJXqPFQ3s A57gtWBxoM943FQzQIQIqcNSLUwYbWintGu7cU9Y= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 11:37:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Feb 2013 11:37:45 -0800 (PST) Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:40:48 -0000 This version has done nothing to address my previously stated objections = and concerns. Owen On Feb 20, 2013, at 11:27 , Mark Smith = wrote: > Hi, >=20 > Here is a new version of my larger IPv6 loopback prefix draft. Changes = since the last version are relatively minor: >=20 > o usability references (DOET and EASY-NUMBERS) > =20 > o minor clarifications > =20 > o grammar corrections >=20 > Further review welcome and appreciated. >=20 > Regards, > Mark. >=20 >=20 > ----- Forwarded Message ----- >> From: "internet-drafts@ietf.org" >> To: markzzzsmith@yahoo.com.au >> Cc:=20 >> Sent: Thursday, 21 February 2013 6:17 AM >> Subject: New Version Notification for = draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt >>=20 >>=20 >> A new version of I-D, = draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt >> has been successfully submitted by Mark Smith and posted to the >> IETF repository. >>=20 >> Filename: draft-smith-v6ops-larger-ipv6-loopback-prefix >> Revision: 04 >> Title: A Larger Loopback Prefix for IPv6 >> Creation date: 2013-02-20 >> Group: Individual Submission >> Number of pages: 12 >> URL: =20 >> = http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback= -prefix-04.txt >> Status: =20 >> = http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-pre= fix >> Htmlized: =20 >> = http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-0= 4 >> Diff: =20 >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback-= prefix-04 >>=20 >> Abstract: >> During the development and testing of a network application, it = can >> be useful to run multiple instances of the application using the = same >> transport layer protocol port on the same development host, while >> also having network access to the application instances limited to >> the local host. Under IPv4, this has commonly been possible by = using >> different loopback addresses within 127/8. It is not possible = under >> IPv6, as the loopback prefix of ::1/128 only provides a single >> loopback address. This memo proposes a new larger loopback prefix >> that will provide many IPv6 loopback addresses. The processing = rules >> for this new larger loopback prefix also allow sending or = forwarding >> of packets containing these addresses beyond the originating = router >> under certain circumstances. >>=20 >> = =20 >> =20 >>=20 >>=20 >> The IETF Secretariat >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Wed Feb 20 12:28: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 2FC6821F889C for ; Wed, 20 Feb 2013 12:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8AH0zCuUZx1 for ; Wed, 20 Feb 2013 12:28:00 -0800 (PST) Received: from nm29.bullet.mail.bf1.yahoo.com (nm29.bullet.mail.bf1.yahoo.com [98.139.212.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3F56A21F8802 for ; Wed, 20 Feb 2013 12:28:00 -0800 (PST) Received: from [98.139.212.150] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 20:27:59 -0000 Received: from [98.139.212.240] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 20:27:59 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 20:27:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 531612.17574.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 27605 invoked by uid 60001); 20 Feb 2013 20:27:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361392079; bh=8mJwjoVfFP5PfFu4R4/RnJTn6fhNaKkcJSw58U4lr9w=; 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=FfWMJysduw3343dO6NKYKpaTyVOj1tt/eIUWHXLCTbWnL+X2OiNRee7n+ZxVOK2DeMBmr7tDxVx3wPXPM8XeNHoeKam6THOhFIUzfE9x4aagdO2iMlzI+REM9dY1UxiobVWl8CnZldqm4HHexlefFRfVSRqS4eQP8eryo09gtZA= 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=LzYaGQwEfIMx1H7h6b0rxXwwW6eTu9CkRxbbs2GnT29xgcVcmsFKLOPxZbZ0kYUBzVEmzEbyPOV5lBhXmaw06SccOWj69dfvudr4KsTRfMVMNzTWLBqd7ZePpTancxExtP8IWU1yROM3Nz16Hln9gitEUfHVvAqcWKXNQPK4T/Y=; X-YMail-OSG: v8zsYogVM1mXVkH1qJX8QyRfZmHQRgxofFsqaNhujy3eZ0C vfCiw4_hXs.7bRpLltveMfhlJwYQ7F4IjJiuGczBUyQ9t1OHuorvdwITlciZ wGPXKZWeanwr1fAw3QWu1lMI9k14Wdfv48BNZ2eG4Vc6OSxeGJzhoZDr_pgf 3eVXZ9F3FWMP1UcikzE1WP4pM1N5MQmwmANAWLRqWzcZNJ1vMvBHcUBA2sO_ wLJkMcTCMAqnyjEb6P.fYk.hVnz4TSS.AQi8lXmrSLALreaCCjhuH_tx74_E TKEQKmkKkFUZ7oHPJy74P0L8PGCcE6YS4acOSoGhbmotpEUI4ZopIre0Fjge Lv6bNRAf7GAO_HDIARQIsulzhhKdmalyb6VpGLwc8zKJT5NeJEu2I2wB4iSW KfYKti7L9xr1yjGDY2HceisBPrbOR7an9kmbpFWC7dHKUYGRo24pkuO3XaDE I.SC2eR4g9R3fCFOISPwhyhX7Qn0h4METKwStsTAfG49GzIZsnzj_bw6maHN 8jBNXGW943f7bgmnC Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Wed, 20 Feb 2013 12:27:59 PST X-Rocket-MIMEInfo: 001.001, SGkgT3dlbiwKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbT4KPiBUbzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBDYzogdjZvcHMgdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFRodXJzZGF5LCAyMSBGZWJydWFyeSAyMDEzIDY6MzcgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zbWl0aC12Nm9wcy1sYXJnZXItaXB2Ni0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 12:27:59 -0800 (PST) From: Mark 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 v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:28:01 -0000 Hi Owen,=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: Mark Smith =0A> Cc: v6ops v6o= ps WG =0A> Sent: Thursday, 21 February 2013 6:37 AM=0A> Sub= ject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger= -ipv6-loopback-prefix-04.txt=0A> =0A>T his version has done nothing to addr= ess my previously stated objections and =0A> concerns.=0A>=A0=0A=0AI didn't= intend it to.=0A=0AYou seem to believe that the best solution to this prob= lem would be to reserve the all-zeros Global ID of the ULA prefix. I disagr= ee with that for quite number of reasons (with another one being that the "= Unique" in ULA would now be false). Many of the things I have proposed are = fundamentally dependent on a new prefix being allocated for this purpose, r= ather than changing the purpose of one of the prefixes within the ULA prefi= x.=A0I consider the number of changes I'd have to make my draft use a ULA p= refix significant, such that I'd end up pretty much writing your proposal, = rather than mine. I've spent quite a lot of my own time and effort on this,= I don't want to spend significantly more (if you compare draft 00 with 01,= you can see that was an almost complete rewrite).=0A=0ASo if you think usi= ng prefix from within the ULA prefix is the better solution, then I think i= t would be better if you wrote up an ID to propose it and provide the corre= sponding details.=0A=0ARegards,=0AMark.=0A=0A=0A=0A> Owen=0A> =0A> On Feb 2= 0, 2013, at 11:27 , Mark Smith wrote:=0A> =0A>>= Hi,=0A>> =0A>> Here is a new version of my larger IPv6 loopback prefix d= raft. Changes =0A> since the last version are relatively minor:=0A>> =0A>> = =A0 =A0 o=A0 usability references (DOET and EASY-NUMBERS)=0A>> =A0 =0A>> = =A0 =A0 o=A0 minor clarifications=0A>> =A0 =0A>> =A0 =A0 o=A0 grammar corre= ctions=0A>> =0A>> Further review welcome and appreciated.=0A>> =0A>> Rega= rds,=0A>> Mark.=0A>> =0A>> =0A>> ----- Forwarded Message -----=0A>>> Fro= m: "internet-drafts@ietf.org" =0A> =0A>>> To: ma= rkzzzsmith@yahoo.com.au=0A>>> Cc: =0A>>> Sent: Thursday, 21 February 2013= 6:17 AM=0A>>> Subject: New Version Notification for =0A> draft-smith-v6op= s-larger-ipv6-loopback-prefix-04.txt=0A>>> =0A>>> =0A>>> A new version of = I-D, =0A> draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt=0A>>> has b= een successfully submitted by Mark Smith and posted to the=0A>>> IETF repo= sitory.=0A>>> =0A>>> Filename:=A0 =A0 draft-smith-v6ops-larger-ipv6-loopb= ack-prefix=0A>>> Revision:=A0 =A0 04=0A>>> Title:=A0 =A0 =A0 =A0 A Larg= er Loopback Prefix for IPv6=0A>>> Creation date:=A0 =A0 2013-02-20=0A>>> = Group:=A0 =A0 =A0 =A0 Individual Submission=0A>>> Number of pages: 12=0A= >>> URL:=A0 =A0 =A0 =A0 =A0 =A0 =0A>>> =0A> http://www.ietf.org/internet-d= rafts/draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt=0A>>> Status:= =A0 =A0 =A0 =A0 =A0 =0A>>> =0A> http://datatracker.ietf.org/doc/draft-smith= -v6ops-larger-ipv6-loopback-prefix=0A>>> Htmlized:=A0 =A0 =A0 =A0 =0A>>> = =0A> http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-pref= ix-04=0A>>> Diff:=A0 =A0 =A0 =A0 =A0 =A0 =0A>>> =0A> http://www.ietf.org/r= fcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback-prefix-04=0A>>> =0A>>>= Abstract:=0A>>> =A0 =A0 During the development and testing of a network a= pplication, it can=0A>>> =A0 =A0 be useful to run multiple instances of the= application using the =0A> same=0A>>> =A0 =A0 transport layer protocol por= t on the same development host, while=0A>>> =A0 =A0 also having network acc= ess to the application instances limited to=0A>>> =A0 =A0 the local host.= =A0 Under IPv4, this has commonly been possible by =0A> using=0A>>> =A0 =A0= different loopback addresses within 127/8.=A0 It is not possible under=0A>= >> =A0 =A0 IPv6, as the loopback prefix of ::1/128 only provides a single= =0A>>> =A0 =A0 loopback address.=A0 This memo proposes a new larger loopbac= k prefix=0A>>> =A0 =A0 that will provide many IPv6 loopback addresses.=A0 T= he processing =0A> rules=0A>>> =A0 =A0 for this new larger loopback prefix = also allow sending or forwarding=0A>>> =A0 =A0 of packets containing these = addresses beyond the originating router=0A>>> =A0 =A0 under certain circums= tances.=0A>>> =0A>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =0A> =A0 =A0 =A0 =A0 =0A>>> =A0 =0A>>> =0A>>> =0A>>> The = IETF Secretariat=0A>>> =0A>> _____________________________________________= __=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org= /mailman/listinfo/v6ops=0A> From jhw@apple.com Wed Feb 20 12:34: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 3776D21E8030 for ; Wed, 20 Feb 2013 12:34:16 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cSmeMd0yb+k for ; Wed, 20 Feb 2013 12:34:15 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id A684021F86AD for ; Wed, 20 Feb 2013 12:34:15 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MIJ00B48D53CTJ1@mail-out.apple.com> for v6ops@ietf.org; Wed, 20 Feb 2013 12:34:15 -0800 (PST) X-AuditID: 11807130-b7fb36d00000433f-44-512533475148 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 7D.05.17215.74335215; Wed, 20 Feb 2013 12:34:15 -0800 (PST) Received: from ba0301a-dhcp70.apple.com ([17.193.14.198]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MIJ005G5D52I310@spicerack.apple.com> for v6ops@ietf.org; Wed, 20 Feb 2013 12:34:15 -0800 (PST) From: james woodyatt In-reply-to: <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 12:34:14 -0800 Message-id: <124E75D0-AE92-4202-893A-7A854CB1391C@apple.com> References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> To: v6ops v6ops WG X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FCsoeturBpo8OuEkMXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsb7jAHPBD5mK//3TWRoYH4l1MXJwSAiYSBxtseti5AQyxSQu 3FvP1sXIxSEkMINJYvmfP2wgCSGBRUwSZyfog9jMAjoSvd+/MYPYvAJ6EtvmbgOrERbIkOjd +5sVxGYTUJH4dvkuE4jNKeAp8bl5MiOIzSKgKrFpyj0WiDnaEk/eXWCFmGMjMeP2YVaIxQ2M Emfm7wQbKiKgLPHk0BwmiOtkJV4/f8MygZF/FpI7ZiG5YxaSuQsYmVcxChal5iRWGhrqJRYU 5KTqJefnbmIEh1ihwQ7GtT/5DzEKcDAq8fAufKkSKMSaWFZcmXuIUYKDWUmE92cHUIg3JbGy KrUoP76oNCe1+BCjNAeLkjjvfh3VQCGB9MSS1OzU1ILUIpgsEwenVAMjb9SKuVWdJyY6Xgjc wHI/dVN8ln7xzv1us/o9PQy6y2aG28fWnOWIaTA5+/7KLytd/ylRwru5j+y/67bkR3Wwnl/q 1rct9UInFm7d/jxe6/uOtXolNsyCR7pu9x/XF9j0XePG7pMLhCyn9G1reVneq1h7yqXzb/kJ nW8XrnHp/42Tusi+2e2zEktxRqKhFnNRcSIAfMlKKy0CAAA= Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:34:16 -0000 On Feb 20, 2013, at 11:27 , Mark Smith wrote: > > Here is a new version of my larger IPv6 loopback prefix draft. [...] > Further review welcome and appreciated. I see no need for a shorter prefix for a node-local addressing scope. I think using fe80::/10 on loopback interfaces is sufficient for this purpose. Consider the output of ifconfig lo0 on the OS X 10.8 machine I'm using to write this message: >> $ ifconfig lo0 >> lo0: flags=8049 mtu 16384 >> options=3 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >> inet 127.0.0.1 netmask 0xff000000 >> inet6 ::1 prefixlen 128 There are already two interface addresses attached to the single loopback interface on my system, and room in the number space for another 2^118 - 1 addresses, which is certainly well beyond the capacity of my host operating system to field. Because the interface is loopback, the reachability of fe80::1%lo0 is constrained to node-local peers. Additional loopback interfaces would entail additional addresses with a different scope identifier. Worth noting, IPv6 Scoped Address Architecture [RFC 4007] makes several references to a loopback interface. It may not be formally required by the standard, but it seems to be a common feature, and it would make more sense to formalize existing practice than to carve out a whole new address allocation for node-local scopes. Section 2.5.3 of IP Version 6 Addressing Architecture [RFC 4291] also mentions a conceptual loopback interface. It's worth looking at how this section has evolved in the progression from RFC 1884, the first published IPv6 Addressing Architecture document. [RFC 1884] >> >> 2.4.3 The Loopback Address >> >> The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. >> It may be used by a node to send an IPv6 datagram to itself. It may >> never be assigned to any interface. >> >> The loopback address must not be used as the source address in IPv6 >> datagrams that are sent outside of a single node. An IPv6 datagram >> with a destination address of loopback must never be sent outside of >> a single node. Notice that the original concept was an address that was not assigned to any interface. No mention of a loopback interface is present. This was found to be too limiting, and the restriction was modified in RFC 2373 to apply only to "physical" interfaces, and this language has been carried forward to RFC 4291, the current standard. [RFC 4291] >> >> 2.5.3 The Loopback Address >> >> The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. >> It may be used by a node to send an IPv6 packet to itself. It may >> never be assigned to any physical interface. It is treated as >> having link-local scope, and may be thought of as the link-local >> unicast address of a virtual interface (typically called "the >> loopback interface") to an imaginary link that goes nowhere. >> >> The loopback address must not be used as the source address in IPv6 >> packets that are sent outside of a single node. An IPv6 packet with >> a destination address of loopback must never be sent outside of a >> single node and must never be forwarded by an IPv6 router. A packet >> received on an interface with destination address of loopback must be >> dropped. I don't see how this new proposed draft improves on existing operational practice. -- james woodyatt core os networking From pkern@hub.kern.lc Wed Feb 20 14:01: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 B528421E8049 for ; Wed, 20 Feb 2013 14:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0begWNDzyGAx for ; Wed, 20 Feb 2013 14:01:08 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FC321E8048 for ; Wed, 20 Feb 2013 14:01:08 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U8Hiq-0007JB-Kz; Wed, 20 Feb 2013 23:01:04 +0100 Received: from pkern by hub.kern.lc with local (Exim 4.80) (envelope-from ) id 1U8His-0002IC-0g; Wed, 20 Feb 2013 23:01:06 +0100 Date: Wed, 20 Feb 2013 23:01:06 +0100 From: Philipp Kern To: james woodyatt Message-ID: <20130220220105.GA8609@hub.kern.lc> References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <124E75D0-AE92-4202-893A-7A854CB1391C@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <124E75D0-AE92-4202-893A-7A854CB1391C@apple.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Philipp Kern Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:01:09 -0000 On Wed, Feb 20, 2013 at 12:34:14PM -0800, james woodyatt wrote: > Because the interface is loopback, the reachability of > fe80::1%lo0 is constrained to node-local peers. Additional loopback > interfaces would entail additional addresses with a different scope > identifier. Was the interface specification standarized already? AFAIK applications need to implement manual parsing to support them instead of just passing an address to the OS API. Kind regards Philipp Kern From bill.jouris@insidethestack.com Wed Feb 20 14:20: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 8CDB221E8030 for ; Wed, 20 Feb 2013 14:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXp4NdTBeHw0 for ; Wed, 20 Feb 2013 14:20:52 -0800 (PST) Received: from nm20-vm0.access.bullet.mail.sp2.yahoo.com (nm20-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.174]) by ietfa.amsl.com (Postfix) with ESMTP id C82CD21F8798 for ; Wed, 20 Feb 2013 14:20:52 -0800 (PST) Received: from [98.139.44.105] by nm20.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Feb 2013 22:20:46 -0000 Received: from [98.139.44.68] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Feb 2013 22:20:46 -0000 Received: from [127.0.0.1] by omp1005.access.mail.sp2.yahoo.com with NNFMP; 20 Feb 2013 22:20:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 934932.19986.bm@omp1005.access.mail.sp2.yahoo.com Received: (qmail 8953 invoked by uid 60001); 20 Feb 2013 22:20:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361398846; bh=cs3pw1T3DsyVdFSCEL4wdOFnSVizVh6seWQOcny3OE0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g56HcQGHHdfzXdgC7PdPqYPkCIBGVpiFw+EYYNn68VqoODPQA0Z4ZREaHlkMpAT/yk+aJhRsmLVGJm8Pafvy73SF/lN7k3ak4EsOWWJCBWqhlDWqs9jf/wir/hl5sa3J87k//Qo2Z+pRx7IB4Q3+ErYqAACvQKlEywykOAWaS6Q= X-YMail-OSG: Zq23g7wVM1ldSd30aLMOZHQUgy6kehgMhslcYLHX8BNZEvk Hq_7hzpxY5.M9F2epb4ZW0HjzVKrNI0elZ6k_8KAsZcJ6OeUtQpsD4MZj8YC ebDAloUO1ChUmrrmrmkaWbCa0robbQsR7HJ1857c71BXfntlhSw0rggcEi5H dzbBD4ErQ.lKUAm9.pTh7ECCBOS8dAz3LERYCFkZaaF9oXkGCCVWnQRY1kXb cJKgVHYSGGEYx5XZh6joH44fmt00eux4cnf17yuA7GghxmaxyYkCala8plXD .Q_1hvf3n5M59U_E340GkueiYZ87wBsJHXYq0zukSAAGiEPL7lBIyOJL8QXR yFQ2TFMdpWE78srnCrKmOVhiTGndrj98FAPrZ_o4dW_aek2_eAuJ7mHDO4xs QyhH_wpnGeO5TT8s_AWH_ow0V6ometg6BZd0fXgTlfjGv2VC2GZqHwPDqJpT YzNaomijGC4CViW1VEoUzpfJvrEZbtSmkZA4FMcsrJJgN_QuCnIsAcCcRWCb oxMnSHpNDzcz5ljuz7an_EPAoZwmuC0krXfzYETH0GvG96tGYx25y8jxbo0K aXXblVQQ5kOgFbSZQNZsMe1FcNPb48bs- Received: from [50.148.178.232] by web2814.biz.mail.ne1.yahoo.com via HTTP; Wed, 20 Feb 2013 14:20:46 PST X-Rocket-MIMEInfo: 001.001, T3dlbiwgDQoNClNvIHdoYXQgeW91IHNlZW0gdG8gYmUgc2F5aW5nIGlzOiBJZiBtYW51ZmFjdHVyZXJzIHdhbnQgdG8gdXNlIGEgc3BlY2lmaWMgcGFydCBvZiB0aGVpciBjb21wYW55IGFsbG9jYXRpb24gb2YgYWRkcmVzc2VzIHRvIGdpdmUgYWRkcmVzc2VzIHRvIHRoZSBjYXJzIHRoYXQgdGhleSBtYWtlIGJhc2VkIG9uIFZJTiBudW1iZXJzLCB0aGF0IGlzIHVwIHRvIHRoZW0uwqAgQnV0IElFVEYgc2hvdWxkIG5vdCBtYW5kYXRlIGFsbG9jYXRpbmcgcGFydCBvZiB0aGUgb3ZlcmFsbCBzcGVjdHJ1bSBvZiABMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.134.513 Message-ID: <1361398846.4312.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> Date: Wed, 20 Feb 2013 14:20:46 -0800 (PST) From: Bill Jouris To: v6ops@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="180689402-544203361-1361398846=:4312" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 22:20:53 -0000 --180689402-544203361-1361398846=:4312 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Owen,=20 So what you seem to be saying is: If manufacturers want to use a specific p= art of their company allocation of addresses to give addresses to the cars = that they make based on VIN numbers, that is up to them.=A0 But IETF should= not mandate allocating part of the overall spectrum of addresses to them. If so, perhaps we should at least suggest to the SAE (Society of Automotive= Engineers), which makes standards for that industry, that they look at whe= ther it makes sense for all of the companies to take a uniform approach to = how they do that. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) > On Feb 19, 2013, at 5:09 PM, Owen DeLong wrote: I do not support allocating globally unique prefixes for things that are no= t networks. Perhaps that will better explain my position. I think that overloading the IPv6 prefix space with semantics for arbitrary= collections of things is a really bad idea that has tremendous potential t= o consume vast amounts of addresses while yielding no network benefit in re= turn. Will it exhaust the IPv6 space immediately, probably not. Could we easily e= xhaust the ASN space if we start promoting the idea of claiming ASNs to sup= port this? Yeah, we could probably burn 4 billion ASNs that way without too= much trouble. --180689402-544203361-1361398846=:4312 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --180689402-544203361-1361398846=:4312-- From ietf-ipr@ietf.org Wed Feb 20 14:29: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 1642921E8048; Wed, 20 Feb 2013 14:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyAebEKZdJ1R; Wed, 20 Feb 2013 14:29:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90FB21E8030; Wed, 20 Feb 2013 14:29:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: mawatari@jpix.ad.jp, kawashimam@vx.jp.nec.com, cameron.byrne@t-mobile.com X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130220222909.18845.7945.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 14:29:09 -0800 Cc: v6ops@ietf.org, fred.baker@cisco.com, ipr-announce@ietf.org Subject: [v6ops] IPR Disclosure: China Mobile Communications Corporation's Statement about IPR related to draft-ietf-v6ops-464xlat-09 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2013 22:29:10 -0000 Dear Masataka Mawatari, Masanobu Kawashima, Cameron Byrne: An IPR disclosure that pertains to your Internet-Draft entitled "464XLAT: Combination of Stateful and Stateless Translation" (draft-ietf-v6ops-464xla= t) was submitted to the IETF Secretariat on 2013-02-04 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1970/). The title of the IPR disclosure is "China Mobile Communications Corporation's Statement about IPR related to d= raft- ietf-v6ops-464xlat-09.""); The IETF Secretariat From sarikaya2012@gmail.com Wed Feb 20 14:45: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 BFC4821E803A for ; Wed, 20 Feb 2013 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPtetJdJ-6y5 for ; Wed, 20 Feb 2013 14:45:43 -0800 (PST) Received: from mail-la0-x22e.google.com (la-in-x022e.1e100.net [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82A21E8037 for ; Wed, 20 Feb 2013 14:45:43 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so8068681lab.5 for ; Wed, 20 Feb 2013 14:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T8ZoawSqG4VOn3Zkz8SJ9F61uVEG+yQul3JMneDwwCc=; b=fX6SmD14OhVhDGiW1vUYNYXdXMgu905LGSzHJ5EsaAQ+SHNzkhnhsl5msVrbnIn5iZ d0imqsWpgQutdGvdSMst9OQLTnbbU2/ptG5sxa76u+oOZf5t0x+7drP7NRBVl8izlIVu 6jLlPN/75VmHRy/JJMWOH9zOCZCmPbLx0b7GNxf9tlyRMjqpXpdBv0hieAcPomJYF5l9 rwmjugVTL9ZJeoOt4yIvDYCy2I81FI7mak725HxzYu4vYCm/qdFMAz64C9czXmjn2Z+p nppcpzGG8dgPlXMQYClw7cMBUPpYVMafetk4m4VE+bzLex/yJ+1MT96hs55kTtmbcXUL oe+Q== MIME-Version: 1.0 X-Received: by 10.112.87.66 with SMTP id v2mr9584184lbz.130.1361400342026; Wed, 20 Feb 2013 14:45:42 -0800 (PST) Received: by 10.114.28.168 with HTTP; Wed, 20 Feb 2013 14:45:41 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 16:45:41 -0600 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: multipart/alternative; boundary=f46d040169ffc8998a04d62fb7f7 Cc: IPv6 Ops WG Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:45:44 -0000 --f46d040169ffc8998a04d62fb7f7 Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron, sorry for my belated reply. On Sun, Feb 3, 2013 at 7:37 PM, Cameron Byrne wrote: > > > Since a lot of folks talk about IPv6 in mobile, i figured i would pen > my own view and experience here. It hopefully will set some context > for the WG work products draft-ietf-v6ops-464xlat, > draft-ietf-v6ops-64share, > draft-binet-v6ops-cellular-host-requirements. Please do note 464XLAT > is not 3GPP/mobile specific. > > AFAIK, there is exactly 1 provider in the world of 3GPP that offers > dual-stack service by default, Verizon Wireless (hat tip). I did not > count, but there is probably more that 50 LTE networks out there today > http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be some > others that support default-on dual-stack, i but i don't know of them. > > So, conclusion #1 is that that LTE does not require or even help IPv6 > deployment. Look at the facts. There is a long list of LTE networks > that definitely do not have IPv6 or dual-stack by default: AT&T, > Sprint, EE, T-Mobile DE, Rogers, Vodafone, .. > > Maybe they realized that NAT44 is good enough for them to handle not so many LTE customers they have? They already know NAT44 technology. > I believe a lot of folks, myself included, thought network upgrades > would bring about more IPv6 features and deployment. In my own > experience, this is the exact opposite in reality. Let me explain. > > There are 4 major providers of 3GPP equipment. I will exonerate > Huawei since i don't know anything about them and Cisco because i know > there stuff works (AFAIK). The other 2 providers are specifically > defunct on the IPv4v6 front. One -- has a brand new high capacity > P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6). > And > the other, which is painfully wrecking my IPv4v6 deployment plans, has > a newish (few years old now) high capacity SGSN which does not support > IPv4v6 (also supports v4 or v6). This should be OK for SGSN because you don't even need SGSN to support IPv6 in order to support IPv6 in your network, right? because of the inherent tunneling. Witness, new gear does not result in > v4v6 (dual-stack). I remember you voiced strongly against the dual stack approach. You seemed to have advocated IPv6 only network with 4via6 approaches, v4 users can be supported. This was what you were advocating, and for a good reason. > In fact, the legacy SGSN that i had from the same > vendor does support v4v6, but it is now end of life (at least as far > as my network)! It is just the new one that does not have dual-stack > support. > > Thought i would just share, and dispel any misconceptions folks had > about 3GPP / LTE networks and IPv6, especially about dual-stack. > There is nothing wrong with the 3GPP specs, and i know the network > operators are asking but not getting the features ... That said, > draft-ietf-v6ops-464xlat and draft-ietf-v6ops-64share are both hacks > that try to route around the brokeness of economics, NAT444s, vendors > that don't ship 4+ year old 3GPP defined mandatory features (IPv4v6 > LTE bearers), and > IPV4-only apps like Skype. > > This seems to be the main issue. What a pity :-). Regards, Behcet --f46d040169ffc8998a04d62fb7f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cameron,

sorry for my belated reply.

On Sun, Feb 3, 2013 at 7:37 PM, Cameron Byrne <<= a href=3D"mailto:cb.list6@gmail.com" target=3D"_blank">cb.list6@gmail.com> wrote:
<rant>

Since a lot of folks talk about IPv6 in mobile, i figured i would pen
my own view and experience here. =A0It hopefully will set some context
for the WG work products draft-ietf-v6ops-464xlat,
draft-ietf-v6ops-64share,
draft-binet-v6ops-cellular-host-requirements. =A0Please do note 464XLAT
is not 3GPP/mobile specific.

AFAIK, there is exactly 1 provider in the world of 3GPP that offers
dual-stack service by default, Verizon Wireless (hat tip). =A0I did not
count, but there is probably more that 50 LTE networks out there today
http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be = some
others that support default-on dual-stack, i but i don't know of them.<= br>
So, conclusion #1 is that that LTE does not require or even help IPv6
deployment. =A0Look at the facts. There is a long list of LTE networks
that definitely do not have IPv6 or dual-stack by default: =A0AT&T,
Sprint, EE, T-Mobile DE, Rogers, Vodafone, ..


Maybe they realized that NAT44 is good enough for= them to handle not so many LTE customers they have? They already know NAT4= 4 technology.
=A0
I believe a lot of folks, myself included, thought network upgrades
would bring about more IPv6 features and deployment. =A0In my own
experience, this is the exact opposite in reality. =A0Let me explain.

There are 4 major providers of 3GPP equipment. =A0I will exonerate
Huawei since i don't know anything about them and Cisco because i know<= br> there stuff works (AFAIK). =A0The other 2 providers are specifically
defunct on the IPv4v6 front. =A0One -- has a brand new high capacity
P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6).
=A0
=A0And
the other, which is painfully wrecking my IPv4v6 deployment plans, has
a newish (few years old now) high capacity SGSN which does not support
IPv4v6 (also supports v4 or v6).

=A0This should be OK= for SGSN because you don't even need SGSN to support IPv6 in order to = support IPv6 in your network, right? because of the inherent tunneling.

=A0Witness, new gear does not resu= lt in
v4v6 (dual-stack).

I remember you voiced strongly aga= inst the dual stack approach. You seemed to have advocated IPv6 only networ= k with 4via6 approaches, v4 users can be supported. This was what you were = advocating, and for a good reason.
=A0
=A0In fact, the legacy SGSN tha= t i had from the same
vendor does support v4v6, but it is now end of life (at least as far
as my network)! =A0It is just the new one that does not have dual-stack
support.

Thought i would just share, and dispel any misconceptions folks had
about 3GPP / LTE networks and IPv6, especially about dual-stack.
There is nothing wrong with the 3GPP specs, and i know the network
operators are asking but not getting the features ... That said,
draft-ietf-v6ops-464xlat and draft-ietf-v6ops-64share are both hacks
that try to route around the brokeness of economics, NAT444s, vendors
that don't ship 4+ year old 3GPP defined mandatory features (IPv4v6
LTE bearers), and
=A0
IPV4-only apps like Skype.


This seems to be the main issue.
What a pity = :-).

Regards,

Behcet
--f46d040169ffc8998a04d62fb7f7-- From internet-drafts@ietf.org Wed Feb 20 15:22:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C1C21F88BC; Wed, 20 Feb 2013 15:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3cyjNT9yhSF; Wed, 20 Feb 2013 15:22:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F98821E803A; Wed, 20 Feb 2013 15:22:10 -0800 (PST) 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.40 Message-ID: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 15:22:10 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.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, 20 Feb 2013 23:22:11 -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 : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interfac= e to a LAN Author(s) : Cameron Byrne Dan Drown Ales Vizdal Filename : draft-ietf-v6ops-64share-03.txt Pages : 8 Date : 2013-02-20 Abstract: This document describes three methods for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marka@isc.org Wed Feb 20 17:00:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF46C21E805F for ; Wed, 20 Feb 2013 17:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B25nr+3uLLkn for ; Wed, 20 Feb 2013 17:00:50 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0067021E8049 for ; Wed, 20 Feb 2013 17:00:46 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 78030C944E; Thu, 21 Feb 2013 01:00:35 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361408446; bh=NptmxPq7r0DxkUZexFa+RGdAPuLC01LCU40rdSzEan0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=PVkSFlbZGfG1f1V9nDpfe+Me0lv3AiNmhmjUItw5LC58jdc7gfgP0eAkQatRNAU5j 83AUGID71RzQE28ShWAkoX6RxLsYXNmJ+MxNdHeZye34KlJMntaqYItHLt5pP41pMG CIWtgHYwSFtkvWBmUW7JcyMkpyM4JpK3AvIZwYUI= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 21 Feb 2013 01:00:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c1c8:e29:43a6:6de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B6FEA216C3B; Thu, 21 Feb 2013 01:00:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4CC052FECB01; Thu, 21 Feb 2013 12:00:30 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-reply-to: Your message of "Wed, 20 Feb 2013 11:37:43 -0800." Date: Thu, 21 Feb 2013 12:00:30 +1100 Message-Id: <20130221010030.4CC052FECB01@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:00:51 -0000 In message , Owen DeLong write s: > This version has done nothing to address my previously stated objections and > concerns. > > Owen Agreed. The entire premise of this draft is based on "we did it this way with IPv4 so we need to do it this way with IPv6". IPv6 is very different. * From the start IPv6 has has link local addresses. This includes the loopback interface. * When 127/0 was reserved there weren't RFC 1918 address ranges. There weren't IPv4 link local address ranges. * Today we have ULA address. If you are worried about collisions we can use a centrally assigned unique local address. fc00::/48 is easy enough to remember and type, has never been assigned and is is a existing reserved block of tainted addresses. fc00::/48 could be the first assignment in that range. B.T.W. We do testing of our products over IPv6 loopback interfaces today and have done for years without the need for this draft. We choose a ULA prefix to do this. Mark > On Feb 20, 2013, at 11:27 , Mark Smith wrote: > > > Hi, > > > > Here is a new version of my larger IPv6 loopback prefix draft. Changes sinc > e the last version are relatively minor: > > > > o usability references (DOET and EASY-NUMBERS) > > > > o minor clarifications > > > > o grammar corrections > > > > Further review welcome and appreciated. > > > > Regards, > > Mark. > > > > > > ----- Forwarded Message ----- > >> From: "internet-drafts@ietf.org" > >> To: markzzzsmith@yahoo.com.au > >> Cc: > >> Sent: Thursday, 21 February 2013 6:17 AM > >> Subject: New Version Notification for draft-smith-v6ops-larger-ipv6-loopba > ck-prefix-04.txt > >> > >> > >> A new version of I-D, draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt > >> has been successfully submitted by Mark Smith and posted to the > >> IETF repository. > >> > >> Filename: draft-smith-v6ops-larger-ipv6-loopback-prefix > >> Revision: 04 > >> Title: A Larger Loopback Prefix for IPv6 > >> Creation date: 2013-02-20 > >> Group: Individual Submission > >> Number of pages: 12 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback > -prefix-04.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-pre > fix > >> Htmlized: > >> http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-0 > 4 > >> Diff: > >> http://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-larger-ipv6-loopback-pr > efix-04 > >> > >> Abstract: > >> During the development and testing of a network application, it can > >> be useful to run multiple instances of the application using the same > >> transport layer protocol port on the same development host, while > >> also having network access to the application instances limited to > >> the local host. Under IPv4, this has commonly been possible by using > >> different loopback addresses within 127/8. It is not possible under > >> IPv6, as the loopback prefix of ::1/128 only provides a single > >> loopback address. This memo proposes a new larger loopback prefix > >> that will provide many IPv6 loopback addresses. The processing rules > >> for this new larger loopback prefix also allow sending or forwarding > >> of packets containing these addresses beyond the originating router > >> under certain circumstances. > >> > >> > > >> > >> > >> > >> The IETF Secretariat > >> > > _______________________________________________ > > 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 marka@isc.org Wed Feb 20 17:25: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 765EC21E8084 for ; Wed, 20 Feb 2013 17:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=-2.494, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_SOLTNS=2.3, MANGLED_WHILE=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE7g9sTyy2+s for ; Wed, 20 Feb 2013 17:25:57 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF0E21E8083 for ; Wed, 20 Feb 2013 17:25:57 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 01D325F9916; Thu, 21 Feb 2013 01:25:44 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361409955; bh=7F7IiY88EXsAFSt+N3BuWZ1D+XvLLOfFNoOhflhfKUY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=cmUxLoNGjwnOuCDrEk7PSVtt2jvzyq5zBMpGWZKbqRQOmuwYihd9DfxsEb65Y8+F4 utl/mRsxD/3UfQnZTuZQECuCzDA3LO6YfoUfWQQFhczReH/SJrugCWmOjsV6dk7X6t MRk2wytlKGaBfFtGBe1fTZ5lZ957VtAbqsWaRJJM= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c1c8:e29:43a6:6de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C3B35216C3B; Thu, 21 Feb 2013 01:25:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B3D192FECCED; Thu, 21 Feb 2013 12:25:40 +1100 (EST) To: Mark Smith From: Mark Andrews References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-reply-to: Your message of "Wed, 20 Feb 2013 12:27:59 -0800." <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 21 Feb 2013 12:25:40 +1100 Message-Id: <20130221012540.B3D192FECCED@drugs.dv.isc.org> Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:25:58 -0000 In message <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com>, Mark S mith writes: > Hi Owen, > > > ----- Original Message ----- > > From: Owen DeLong > > To: Mark Smith > > Cc: v6ops v6ops WG > > Sent: Thursday, 21 February 2013 6:37 AM > > Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-l= > arger-ipv6-loopback-prefix-04.txt > > = > > >T his version has done nothing to address my previously stated objections = > and = > > > concerns. > >=A0 > > I didn't intend it to. > > You seem to believe that the best solution to this problem would be to rese= > rve the all-zeros Global ID of the ULA prefix. I disagree with that for qui= > te number of reasons (with another one being that the "Unique" in ULA would= > now be false). Many of the things I have proposed are fundamentally depend= > ent on a new prefix being allocated for this purpose, rather than changing = > the purpose of one of the prefixes within the ULA prefix.=A0I consider the = > number of changes I'd have to make my draft use a ULA prefix significant, s= > uch that I'd end up pretty much writing your proposal, rather than mine. I'= > ve spent quite a lot of my own time and effort on this, I don't want to spe= > nd significantly more (if you compare draft 00 with 01, you can see that wa= > s an almost complete rewrite). Part of presenting a proposal is demonstrating why existing methods do not work. There are a number plain falsehoods in your draft. "Multiple IPv6 loopback addresses are not available to bind application instances to when using the same port on the same host." is a falsehood. There is *nothing* in the IPv6 architecture to prevent the operator of the machine configuring additional loopback addresses. In fact multiple loopback addresses are rarely used and whenever they are used some level of configuration is required. > So if you think using prefix from within the ULA prefix is the better solut= > ion, then I think it would be better if you wrote up an ID to propose it an= > d provide the corresponding details. No. It is your job to demonstrate why existing mechanisms are not sufficient and the first step is to present a honest eveluation of why they are not so. I don't believe you were being intentionally dishonest but there is a lack of rigour in your analysis of the currently available mechanisms. Mark > Regards, > Mark. > > = > > > On Feb 20, 2013, at 11:27 , Mark Smith wrote: > > = > > >> Hi, > >> = > > >> Here is a new version of my larger IPv6 loopback prefix draft. Changes = > > > since the last version are relatively minor: > >> = > > >> =A0 =A0 o=A0 usability references (DOET and EASY-NUMBERS) > >> =A0 = > > >> =A0 =A0 o=A0 minor clarifications > >> =A0 = > > >> =A0 =A0 o=A0 grammar corrections > >> = > > >> Further review welcome and appreciated. > >> = > > >> Regards, > >> Mark. > >> = > > >> = > > >> ----- Forwarded Message ----- > >>> From: "internet-drafts@ietf.org" = > > > > >>> To: markzzzsmith@yahoo.com.au > >>> Cc: = > > >>> Sent: Thursday, 21 February 2013 6:17 AM > >>> Subject: New Version Notification for = > > > draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt > >>> = > > >>> = > > >>> A new version of I-D, = > > > draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt > >>> has been successfully submitted by Mark Smith and posted to the > >>> IETF repository. > >>> = > > >>> Filename:=A0 =A0 draft-smith-v6ops-larger-ipv6-loopback-prefix > >>> Revision:=A0 =A0 04 > >>> Title:=A0 =A0 =A0 =A0 A Larger Loopback Prefix for IPv6 > >>> Creation date:=A0 =A0 2013-02-20 > >>> Group:=A0 =A0 =A0 =A0 Individual Submission > >>> Number of pages: 12 > >>> URL:=A0 =A0 =A0 =A0 =A0 =A0 = > > >>> = > > > http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopbac= > k-prefix-04.txt > >>> Status:=A0 =A0 =A0 =A0 =A0 = > > >>> = > > > http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-pr= > efix > >>> Htmlized:=A0 =A0 =A0 =A0 = > > >>> = > > > http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-= > 04 > >>> Diff:=A0 =A0 =A0 =A0 =A0 =A0 = > > >>> = > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback= > -prefix-04 > >>> = > > >>> Abstract: > >>> =A0 =A0 During the development and testing of a network application, it= > can > >>> =A0 =A0 be useful to run multiple instances of the application using th= > e = > > > same > >>> =A0 =A0 transport layer protocol port on the same development host, whi= > le > >>> =A0 =A0 also having network access to the application instances limited= > to > >>> =A0 =A0 the local host.=A0 Under IPv4, this has commonly been possible = > by = > > > using > >>> =A0 =A0 different loopback addresses within 127/8.=A0 It is not possibl= > e under > >>> =A0 =A0 IPv6, as the loopback prefix of ::1/128 only provides a single > >>> =A0 =A0 loopback address.=A0 This memo proposes a new larger loopback p= > refix > >>> =A0 =A0 that will provide many IPv6 loopback addresses.=A0 The processi= > ng = > > > rules > >>> =A0 =A0 for this new larger loopback prefix also allow sending or forwa= > rding > >>> =A0 =A0 of packets containing these addresses beyond the originating ro= > uter > >>> =A0 =A0 under certain circumstances. > >>> = > > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = > > > =A0 =A0 =A0 =A0 = > > >>> =A0 = > > >>> = > > >>> = > > >>> The IETF Secretariat > >>> = > > >> _______________________________________________ > >> 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 owen@delong.com Wed Feb 20 17:45: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 896F121F8558 for ; Wed, 20 Feb 2013 17:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=1.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvFVtHp3Pxpo for ; Wed, 20 Feb 2013 17:45:47 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2400121F854D for ; Wed, 20 Feb 2013 17:45:46 -0800 (PST) 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 r1L1jBHG012828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2013 17:45:11 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1L1jBHG012828 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361411111; bh=e4sm/f1HN9MPEoWWJe6gvmzkNgo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=y5MZ/IyOQg9KY5/G0C9UjFdSg0ChYsp/u7C9LMymcPjTvJX7iDvgqEIp/MfPpNduN jxlhz54kXQ+CT0iM7iTAjBDKBQP2TWgv+60Fvqbzdv3tX9SxAqxOWH/wfTQo30obMO JFrys9t7Vi+zv0v/uxg+Ji66vza3QA67abQXsQXQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_7203A2AC-CD28-480F-8A5A-2975D758BC3F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1361398846.4312.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> Date: Wed, 20 Feb 2013 17:45:10 -0800 Message-Id: References: <1361398846.4312.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> To: Bill Jouris X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Feb 2013 17:45:11 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 01:45:48 -0000 --Apple-Mail=_7203A2AC-CD28-480F-8A5A-2975D758BC3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Bill I think that sums it up reasonably well. However, if they come back to = the RIR for more space and try to use having put a bunch of numbers on = VINs/Cars addressed by VIN that are not actually networked to the = company using a network that topologically matches the numbering scheme, then, the RIR should rightly count those addresses as not = utilized in determining eligibility for additional space. If you feel that some sort of recommendation to SAE is worth while, go = for it. Personally, I don't understand the need for a car to have a = permanently assigned prefix rather than just a MAC address and then get = its prefix through SLAAC or get its addressing via DHCP. If someone can explain this, I am open to being better convinced. Owen On Feb 20, 2013, at 14:20 , Bill Jouris = wrote: >=20 > Owen,=20 >=20 > So what you seem to be saying is: If manufacturers want to use a = specific part of their company allocation of addresses to give addresses = to the cars that they make based on VIN numbers, that is up to them. = But IETF should not mandate allocating part of the overall spectrum of = addresses to them. >=20 > If so, perhaps we should at least suggest to the SAE (Society of = Automotive Engineers), which makes standards for that industry, that = they look at whether it makes sense for all of the companies to take a = uniform approach to how they do that. >=20 > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) >=20 >=20 > > On Feb 19, 2013, at 5:09 PM, Owen DeLong wrote: >=20 >=20 > I do not support allocating globally unique prefixes for things that = are not networks. >=20 > Perhaps that will better explain my position. >=20 > I think that overloading the IPv6 prefix space with semantics for = arbitrary collections of things is a really bad idea that has tremendous = potential to consume vast amounts of addresses while yielding no network = benefit in return. >=20 > Will it exhaust the IPv6 space immediately, probably not. Could we = easily exhaust the ASN space if we start promoting the idea of claiming = ASNs to support this? Yeah, we could probably burn 4 billion ASNs that = way without too much trouble. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_7203A2AC-CD28-480F-8A5A-2975D758BC3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 bill.jouris@insidethestack.= com> wrote:
Owen,

So what you seem to be saying i= s: If manufacturers want to use a specific part of their company allocation= of addresses to give addresses to the cars that they make based on VIN num= bers, that is up to them.  But IETF should not mandate allocating part= of the overall spectrum of addresses to them.

If so, perhaps we sho= uld at least suggest to the SAE (Society of Automotive Engineers), which ma= kes standards for that industry, that they look at whether it makes sense f= or all of the companies to take a uniform approach to how they do that.
=
Bill Jouris
Inside Products= , Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)


> On = Feb 19, 2013, at 5:09 PM, Owen DeLong <owen@delong.com> wrote:
<= br>
I do not support allocating globally unique prefixes for things that= are not networks.

Perhaps that will better explain my position.
=
I think that overloading the IPv6 prefix space with semantics for arbit= rary collections of things is a really bad idea that has tremendous potenti= al to consume vast amounts of addresses while yielding no network benefit i= n return.

Will it exhaust the IPv6 space immediately, probably not. = Could we easily exhaust the ASN space if we start promoting the idea of cla= iming ASNs to support this? Yeah, we could probably burn 4 billion ASNs tha= t way without too much trouble.


Owen,

So what you seem to be saying is: If = manufacturers want to use a specific part of their company allocation of = addresses to give addresses to the cars that they make based on VIN = numbers, that is up to them.  But IETF should not mandate = allocating part of the overall spectrum of addresses to them.

If = so, perhaps we should at least suggest to the SAE (Society of Automotive = Engineers), which makes standards for that industry, that they look at = whether it makes sense for all of the companies to take a uniform = approach to how they do that.

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


> On Feb 19, 2013, at 5:09 PM, Owen DeLong <owen@delong.com= > wrote:


I do not support allocating globally unique = prefixes for things that are not networks.

Perhaps that will = better explain my position.

I think that overloading the IPv6 = prefix space with semantics for arbitrary collections of things is a = really bad idea that has tremendous potential to consume vast amounts of = addresses while yielding no network benefit in return.

Will it = exhaust the IPv6 space immediately, probably not. Could we easily = exhaust the ASN space if we start promoting the idea of claiming ASNs to = support this? Yeah, we could probably burn 4 billion ASNs that way = without too much = trouble.


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

= --Apple-Mail=_7203A2AC-CD28-480F-8A5A-2975D758BC3F-- From jhw@apple.com Wed Feb 20 19:02: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 69C661F0D08 for ; Wed, 20 Feb 2013 19:02:31 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBII7HHJQQeK for ; Wed, 20 Feb 2013 19:02:30 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA1361F0D0A for ; Wed, 20 Feb 2013 19:02:30 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MIJ00AGNV45CB20@mail-out.apple.com> for v6ops@ietf.org; Wed, 20 Feb 2013 19:02:30 -0800 (PST) X-AuditID: 11807134-b7f546d000005e2f-1f-51258e469811 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id BF.14.24111.64E85215; Wed, 20 Feb 2013 19:02:30 -0800 (PST) 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 <0MIJ005YHV455V60@aniseed.apple.com> for v6ops@ietf.org; Wed, 20 Feb 2013 19:02:30 -0800 (PST) From: james woodyatt In-reply-to: <20130220220105.GA8609@hub.kern.lc> Date: Wed, 20 Feb 2013 19:02:29 -0800 Message-id: <26AFE806-3146-4CB8-AC57-77E376936429@apple.com> References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <124E75D0-AE92-4202-893A-7A854CB1391C@apple.com> <20130220220105.GA8609@hub.kern.lc> To: Philipp Kern X-Mailer: Apple Mail (2.1682) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUi2FAsruvWpxpo8Pe8kMXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVse3RTraCBvaKlrsLmRsY77N2MXJySAiYSBye/4EJwhaTuHBv PVsXIxeHkMAUJom+3ZOZIZwZTBJLbpxhB6liFtCSWL/zOFgHr4CexMyVS8AmCQtkSPTu/Q1m swmoSHy7fBeshlPAQKJry0JGEJtFQFVi28E+qDnKEnse7IOytSWevLvACjHTRuLBnxtg9UIC Nxkldh+oAbFFgOoP7eyAulRW4sOVNvYJjAKzkJw0C8lJs5CMXcDIvIpRsCg1J7HS0EQvsaAg J1UvOT93EyM4+ApNdjAe/Ml/iFGAg1GJh3fRS5VAIdbEsuLK3EOMEhzMSiK8PzuAQrwpiZVV qUX58UWlOanFhxilOViUxHk73VQDhQTSE0tSs1NTC1KLYLJMHJxSDYxuUwXqe47I1b4V+SX2 +IaTumSKre+UC5etbz699s2kZrWtiX76cZZ2nu2uayY+CrgY330ueIOHT+OBzZfiri5+cnTO mY2BL48mPF7NqvDTJO5D11fPrCX+lplvjqvPsT66Sbmz+dhOTtFX92ZP+KcQqzfn78H/b3mq I06oiHJ/Clwm6nCcy/y1EktxRqKhFnNRcSIAN82SeDoCAAA= Cc: v6ops v6ops WG Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 03:02:31 -0000 On Feb 20, 2013, at 14:01 , Philipp Kern wrote: > On Wed, Feb 20, 2013 at 12:34:14PM -0800, james woodyatt wrote: >> Because the interface is loopback, the reachability of >> fe80::1%lo0 is constrained to node-local peers. Additional loopback >> interfaces would entail additional addresses with a different scope >> identifier. > > Was the interface specification standarized already? AFAIK applications need to > implement manual parsing to support them instead of just passing an address to > the OS API. I guess that you're asking about this: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers [I-D.carpenter-6man-uri-zoneid] Looks like it is currently in the AUTH48 state. -- james woodyatt core os networking From markzzzsmith@yahoo.com.au Wed Feb 20 19:07: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 3644A21E8082 for ; Wed, 20 Feb 2013 19:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.929 X-Spam-Level: *** X-Spam-Status: No, score=3.929 tagged_above=-999 required=5 tests=[AWL=-1.773, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, MANGLED_SOLTNS=2.3, MANGLED_WHILE=2.3, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otubEiNFVGj7 for ; Wed, 20 Feb 2013 19:07:30 -0800 (PST) Received: from nm5.bullet.mail.bf1.yahoo.com (nm5.bullet.mail.bf1.yahoo.com [98.139.212.164]) by ietfa.amsl.com (Postfix) with SMTP id BFBDB21E8055 for ; Wed, 20 Feb 2013 19:07:29 -0800 (PST) Received: from [98.139.212.153] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 03:07:29 -0000 Received: from [98.139.212.213] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 03:07:29 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 03:07:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 184653.84705.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 43714 invoked by uid 60001); 21 Feb 2013 03:07:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361416048; bh=IWV0rLs+Q0EPE5fkyP49XxCfMvxiGSSDMNZ+XUbLZCU=; 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=JY4cv4BnoBCy7n6limyLeUTZ6Dodkj1lCc4ASck/vlP9wfpsns4vySd7o9LAFgfSA/ZJNNwI2CdBDBTYZTibpUU62sj4E0CusAX9nAg/1fZ7orlDwlu+soOCRuyXXxpgEO8GdHeyd6ivGnLs62E+NWJbuBfBcpubArttUp+tJFk= 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=enHCVvX0YfyShZIoHsBNzEjnjCkIzd/QA7Dhwxlmj0FqJChr5QWJmXcCaiBCLXvxafjts6BZA/6Cx3FLmhrGHGs7sDFs1HdzG3AkB9TYSgOUwdFtw7buMSxfuTxWBgBG5ofyB49iM+bSXx9nog2dbbk1j3bL/BpklF1MHYZhR/w=; X-YMail-OSG: QD4xxXkVM1n_hL4CmqnqiKrQ8ddXTXPGEGqvXv7bvU2uvN_ DCnXtGJY2Me.yCP.3XEXuN8Ry5C76EDY5ekLDg.BHJQ1sgTmlq2oVVvhuKx9 XKr2cbmV2QO6Wc86s3bvTkrqVZvOyUnlbUmh4MKAyfBTwvHCDKmstRKV.IZT Wq7DtMlMxqxqMjVpko0rDc0oOVA5LKW5zm__iGOCjycSiVBTBRIMBHtaoVke B3f1MVGwtFHeY1mT.JJ37dw5h7q8SdOIEh0W._0zv_LX4abZ7G0fYS9uMIoL Qg1PXBWOI.6BdpB71DoEpXRos_XbVQ_Gu1n04w2hPqL6oDqguVWRbuSnQkaB VTppO8Dxf4.etcuQpndmHyz1mpwpmzhoOBshEtV3JwbqXv69uVjTvqzbvGhf fZEtd5JoKirkMYBPnhvXLD12_UUeJqMnyhZ07aBzWr7W8aZmLdC0NovQYsiw mX6n0vp90VWVlPx27PFE7bPejAEhfvgXgLnVVNpBk47L6xhUAOp47uLDZaSk SG3uWT3aquD426N86Yb2f2AazmZjkZyx7aM5LaKZxFJUBctXr6OFV7XgzYHG aDDiMb0WWQ3jtaAysEfd3QQu6wdvZH7.R2yAiEvxWlYjVA8pxLJ3GHS52G7y 8.S5TzkOsEx2i._EjG5g2eVXBIHcQYo4- Received: from [121.200.231.211] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 20 Feb 2013 19:07:28 PST X-Rocket-MIMEInfo: 001.001, T2suCgpMZXRzIGxvb2sgYXQgdGhlIGV4cGVyaWVuY2UgSSBhbmQgb3RoZXJzIGhhdmUgaGFkIHVzaW5nIDEyNy84CgoxLiBpdCBoYXMgYmVlbiBlYXN5IHRvIHJlbWVtYmVyCgoyLiBpdCBoYXMgYmVlbiAocHJldHR5KSBlYXN5IHRvIHR5cGUKCjMuIGl0IGhhcyBhbHdheXMgYmVlbiB0aGVyZQoKNC4gdGhlcmUgaGFzIGJlZW4gYSB3ZWxsIGtub3duIDEyNy4wLjAuMS84IGF1dG9tYXRpY2FsbHkgY29uZmlndXJlZCBhZGRyZXNzLCB2aXNpYmxlIHRvIHRoZSB1c2VyIGFuZCBhc3Npc3RpbmcgdGhlaXIgbWVtb3IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> Message-ID: <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 19:07:28 -0800 (PST) From: Mark Smith To: Mark Andrews In-Reply-To: <20130221012540.B3D192FECCED@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 03:07:31 -0000 Ok.=0A=0ALets look at the experience I and others have had using 127/8=0A= =0A1. it has been easy to remember=0A=0A2. it has been (pretty) easy to typ= e=0A=0A3. it has always been there=0A=0A4. there has been a well known 127.= 0.0.1/8 automatically configured address, visible to the user and assisting= their memory=0A=0A5. it has uniquely identified the loopback interface=0A= =0A6. common hosts (windows/Linux and probably other unicies (from distant = memory, HP-UX probably)) all addresses within 127/8 have also been conceptu= ally assigned (e.g. http:://127.1.2.3:80/ just worked, as did http://127.8.= 7.6:80, without configuration). IOW, there were plenty of automatically con= figured addresses, and no additional effort required to enable them=0A=0A7.= traffic towards all addresses within 127/8 never leaked from the host, bec= ause it was configured to loop traffic by default at system initialisation= =0A=0A::1/128 provides IPv6 equivalents of 1,2,3,4,5 and 7. It does not pro= vide multiple addresses (6). A larger version of ::/128, that satisfies 1 t= hrough 7 is the motive for this draft.=0A=0AOther prefixes suggested (and o= nes I considered and tried using before I started writing this draft) would= need specification updates to automatically behave as above. Otherwise the= y need manual configuration, possibly in addition to violation of their int= ended use and form.=0A=0AFor example, fe80::1/10 might be automatically con= figured on Mac OS X on the loopback interface, but can you use fe80::2, fe8= 0::3, fe80::4567:1234 and have them all automatically work? Special link-lo= cal behaviour on the loopback interface isn't specified as far as I know, s= o it probably won't=A0So it doesn't satisfy 3 and 5, and since link-local d= oesn't have anything to distinguish the link local prefix on loopback from = eth0, you also have to specify an interface, so it also fails 2.=0A=0AA non= -unique ULA of fd00::/64 fails 3, 4, 5 and 6.=0A=0A=0A=0A=0A=0A=0A----- Ori= ginal Message -----=0A> From: Mark Andrews =0A> To: Mark Smi= th =0A> Cc: Owen DeLong ; v6ops= v6ops WG =0A> Sent: Thursday, 21 February 2013 12:25 PM=0A= > Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-l= arger-ipv6-loopback-prefix-04.txt=0A> =0A> =0A> In message <1361392079.2741= 7.YahooMailNeo@web142501.mail.bf1.yahoo.com>, =0A> Mark S=0A> mith writes:= =0A>> Hi Owen,=0A>> =0A>> =0A>> ----- Original Message -----=0A>> > From= : Owen DeLong =0A>> > To: Mark Smith =0A>> > Cc: v6ops v6ops WG =0A>> > Sent: Thursday,= 21 February 2013 6:37 AM=0A>> > Subject: Re: [v6ops] Fw: New Version Noti= fication for =0A> draft-smith-v6ops-l=3D=0A>> arger-ipv6-loopback-prefix-0= 4.txt=0A>> > =3D=0A>> =0A>> >T his version has done nothing to address my= previously stated =0A> objections =3D=0A>> and =3D=0A>> =0A>> > concerns= .=0A>> >=3DA0=0A>> =0A>> I didn't intend it to.=0A>> =0A>> You seem to b= elieve that the best solution to this problem would be to =0A> rese=3D=0A>>= rve the all-zeros Global ID of the ULA prefix. I disagree with that for = =0A> qui=3D=0A>> te number of reasons (with another one being that the "Un= ique" in =0A> ULA would=3D=0A>> =A0 now be false). Many of the things I hav= e proposed are fundamentally =0A> depend=3D=0A>> ent on a new prefix being= allocated for this purpose, rather than changing =0A> =3D=0A>> the purpos= e of one of the prefixes within the ULA prefix.=3DA0I consider the =0A> =3D= =0A>> number of changes I'd have to make my draft use a ULA prefix =0A> si= gnificant, s=3D=0A>> uch that I'd end up pretty much writing your proposal= , rather than =0A> mine. I'=3D=0A>> ve spent quite a lot of my own time an= d effort on this, I don't want to =0A> spe=3D=0A>> nd significantly more (= if you compare draft 00 with 01, you can see that =0A> wa=3D=0A>> s an alm= ost complete rewrite).=0A> =0A> Part of presenting a proposal is demonstrat= ing why existing methods=0A> do not work.=A0 There are a number plain false= hoods in your draft.=0A> =0A> "Multiple IPv6 loopback addresses are not ava= ilable to bind application=0A> instances to when using the same port on the= same host." is a=0A> falsehood.=0A> =0A> There is *nothing* in the IPv6 ar= chitecture to prevent the operator=0A> of the machine configuring additiona= l loopback addresses.=A0 In fact=0A> multiple loopback addresses are rarely= used and whenever they are=0A> used some level of configuration is require= d.=0A> =0A>> So if you think using prefix from within the ULA prefix is th= e better =0A> solut=3D=0A>> ion, then I think it would be better if you wr= ote up an ID to propose it =0A> an=3D=0A>> d provide the corresponding det= ails.=0A> =0A> No. It is your job to demonstrate why existing mechanisms ar= e not=0A> sufficient and the first step is to present a honest eveluation o= f=0A> why they are not so.=A0 I don't believe you were being intentionally= =0A> dishonest but there is a lack of rigour in your analysis of the=0A> cu= rrently available mechanisms.=0A> =0A> Mark=0A> =0A>> Regards,=0A>> Mark.= =0A>> > =3D=0A>> =0A>> > On Feb 20, 2013, at 11:27 , Mark Smith =0A> wrote:=0A>> > =3D=0A>> =0A>> >>=A0 Hi,=0A>> >> = =3D=0A>> =0A>> >>=A0 Here is a new version of my larger IPv6 loopback pref= ix draft. =0A> Changes =3D=0A>> =0A>> > since the last version are relativ= ely minor:=0A>> >> =3D=0A>> =0A>> >> =3DA0 =3DA0 o=3DA0 usability referen= ces (DOET and EASY-NUMBERS)=0A>> >> =3DA0 =3D=0A>> =0A>> >> =3DA0 =3DA0 o= =3DA0 minor clarifications=0A>> >> =3DA0 =3D=0A>> =0A>> >> =3DA0 =3DA0 o= =3DA0 grammar corrections=0A>> >> =3D=0A>> =0A>> >>=A0 Further review wel= come and appreciated.=0A>> >> =3D=0A>> =0A>> >>=A0 Regards,=0A>> >>=A0 M= ark.=0A>> >> =3D=0A>> =0A>> >> =3D=0A>> =0A>> >>=A0 ----- Forwarded Mess= age -----=0A>> >>>=A0 From: "internet-drafts@ietf.org" =3D=0A>> =0A>> > <= internet-drafts@ietf.org>=0A>> >>>=A0 To: markzzzsmith@yahoo.com.au=0A>> = >>>=A0 Cc: =3D=0A>> =0A>> >>>=A0 Sent: Thursday, 21 February 2013 6:17 AM= =0A>> >>>=A0 Subject: New Version Notification for =3D=0A>> =0A>> > draft= -smith-v6ops-larger-ipv6-loopback-prefix-04.txt=0A>> >>> =3D=0A>> =0A>> >= >> =3D=0A>> =0A>> >>>=A0 A new version of I-D, =3D=0A>> =0A>> > draft-smi= th-v6ops-larger-ipv6-loopback-prefix-04.txt=0A>> >>>=A0 has been successfu= lly submitted by Mark Smith and posted to =0A> the=0A>> >>>=A0 IETF reposi= tory.=0A>> >>> =3D=0A>> =0A>> >>>=A0 Filename:=3DA0 =3DA0=A0 =0A> draft-s= mith-v6ops-larger-ipv6-loopback-prefix=0A>> >>>=A0 Revision:=3DA0 =3DA0=A0= 04=0A>> >>>=A0 Title:=3DA0 =3DA0 =3DA0 =3DA0=A0 A Larger Loopback Prefix = for IPv6=0A>> >>>=A0 Creation date:=3DA0 =3DA0=A0 2013-02-20=0A>> >>>=A0 = Group:=3DA0 =3DA0 =3DA0 =3DA0=A0 Individual Submission=0A>> >>>=A0 Number = of pages: 12=0A>> >>>=A0 URL:=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3D=0A>> = =0A>> >>> =3D=0A>> =0A>> > =0A> http://www.ietf.org/internet-drafts/draft= -smith-v6ops-larger-ipv6-loopbac=3D=0A>> k-prefix-04.txt=0A>> >>>=A0 Stat= us:=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3D=0A>> =0A>> >>> =3D=0A>> =0A>> > =0A>= http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-pr= =3D=0A>> efix=0A>> >>>=A0 Htmlized:=3DA0 =3DA0 =3DA0 =3DA0 =3D=0A>> =0A>>= >>> =3D=0A>> =0A>> > =0A> http://tools.ietf.org/html/draft-smith-v6ops-l= arger-ipv6-loopback-prefix-=3D=0A>> 04=0A>> >>>=A0 Diff:=3DA0 =3DA0 =3DA0= =3DA0 =3DA0 =3DA0 =3D=0A>> =0A>> >>> =3D=0A>> =0A>> > =0A> http://www.ie= tf.org/rfcdiff?url2=3D3Ddraft-smith-v6ops-larger-ipv6-loopback=3D=0A>> -pr= efix-04=0A>> >>> =3D=0A>> =0A>> >>>=A0 Abstract:=0A>> >>> =3DA0 =3DA0 Du= ring the development and testing of a network =0A> application, it=3D=0A>> = =A0 can=0A>> >>> =3DA0 =3DA0 be useful to run multiple instances of the ap= plication =0A> using th=3D=0A>> e =3D=0A>> =0A>> > same=0A>> >>> =3DA0 = =3DA0 transport layer protocol port on the same development =0A> host, whi= =3D=0A>> le=0A>> >>> =3DA0 =3DA0 also having network access to the applic= ation =0A> instances limited=3D=0A>> =A0 to=0A>> >>> =3DA0 =3DA0 the local= host.=3DA0 Under IPv4, this has commonly been =0A> possible =3D=0A>> by = =3D=0A>> =0A>> > using=0A>> >>> =3DA0 =3DA0 different loopback addresses = within 127/8.=3DA0 It is =0A> not possibl=3D=0A>> e under=0A>> >>> =3DA0 = =3DA0 IPv6, as the loopback prefix of ::1/128 only provides =0A> a single= =0A>> >>> =3DA0 =3DA0 loopback address.=3DA0 This memo proposes a new larg= er =0A> loopback p=3D=0A>> refix=0A>> >>> =3DA0 =3DA0 that will provide m= any IPv6 loopback addresses.=3DA0 The =0A> processi=3D=0A>> ng =3D=0A>> = =0A>> > rules=0A>> >>> =3DA0 =3DA0 for this new larger loopback prefix al= so allow sending =0A> or forwa=3D=0A>> rding=0A>> >>> =3DA0 =3DA0 of pack= ets containing these addresses beyond the =0A> originating ro=3D=0A>> uter= =0A>> >>> =3DA0 =3DA0 under certain circumstances.=0A>> >>> =3D=0A>> =0A>= > >>> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 =3DA0 =3DA0 =3DA0 =0A> =3DA0 =3DA0 =3DA0=3D=0A>> =A0 =3DA0 =3DA0 =3DA= 0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 =3DA0 =3DA0 =3D=0A>> =0A>> > =3DA0 =3DA0 =3DA0 =3DA0 =3D=0A>> =0A>> = >>> =3DA0 =3D=0A>> =0A>> >>> =3D=0A>> =0A>> >>> =3D=0A>> =0A>> >>>=A0 T= he IETF Secretariat=0A>> >>> =3D=0A>> =0A>> >>=A0 _______________________= ________________________=0A>> >>=A0 v6ops mailing list=0A>> >>=A0 v6ops@i= etf.org=0A>> >>=A0 https://www.ietf.org/mailman/listinfo/v6ops=0A>> > =3D= =0A>> =0A>> _______________________________________________=0A>> v6ops ma= iling list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/mailman/listinfo= /v6ops=0A> -- =0A> Mark Andrews, ISC=0A> 1 Seymour St., Dundas Valley, NSW = 2117, Australia=0A> PHONE: +61 2 9871 4742=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = INTERNET: marka@isc.org=0A> From mackermann@bcbsm.com Wed Feb 20 20:44: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 7DD2721F8DC9 for ; Wed, 20 Feb 2013 20:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.081 X-Spam-Level: X-Spam-Status: No, score=-5.081 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhjX7g6kjt8i for ; Wed, 20 Feb 2013 20:44:36 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 61DDA21F8DC7 for ; Wed, 20 Feb 2013 20:44:34 -0800 (PST) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id E078C136D8D for ; Wed, 20 Feb 2013 22:44:33 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 7627A136D7E; Wed, 20 Feb 2013 22:44:32 -0600 (CST) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id EE3D12F0049; Wed, 20 Feb 2013 23:44:22 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id DBEF12F0045; Wed, 20 Feb 2013 23:44:22 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Wed, 20 Feb 2013 23:44:31 -0500 From: "Ackermann, Michael" To: Owen DeLong , Bill Jouris Thread-Topic: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn Thread-Index: AQHODsRRcjWPOW9Mv02OI1MfD5D0GZiB93MAgAApPQCAACORAIAAEqyAgAAJUQCAAUcZAIAAORwA///cSxA= Date: Thu, 21 Feb 2013 04:44:31 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A24732A@PWN401EA160.ent.corp.bcbsm.com> References: <1361398846.4312.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A24732APWN401EA160entc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 04:44:37 -0000 --_000_4FC37E442D05A748896589E468752CAA0A24732APWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is very similar to something we were exploring in the = Medical/Insurance realms. That is using IPV6 addresses for = entities/artifacts such as Claim or Subscriber numbers. ARIN did not = like that as rationale for additional or larger address space as alluded = by Owen below. But similar approaches are being considered in = multiple industries. Why would that be preferred over MAC & SLAAC? Not sure at this point as = this is still being explored. but possibly being more predictable, = controlled and self documenting? From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Owen DeLong Sent: Wednesday, February 20, 2013 8:45 PM To: Bill Jouris Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D Comments to = draft-mlevy-v6ops-auto-v6-allocation-per-asn Bill I think that sums it up reasonably well. However, if they come back to the = RIR for more space and try to use having put a bunch of numbers on = VINs/Cars addressed by VIN that are not actually networked to the company = using a network that topologically matches the numbering scheme, then, the RIR should rightly count those addresses as not utilized = in determining eligibility for additional space. If you feel that some sort of recommendation to SAE is worth while, go for = it. Personally, I don't understand the need for a car to have a = permanently assigned prefix rather than just a MAC address and then get = its prefix through SLAAC or get its addressing via DHCP. If someone can explain this, I am open to being better convinced. Owen On Feb 20, 2013, at 14:20 , Bill Jouris = >= wrote: Owen, So what you seem to be saying is: If manufacturers want to use a specific = part of their company allocation of addresses to give addresses to the = cars that they make based on VIN numbers, that is up to them. But IETF = should not mandate allocating part of the overall spectrum of addresses to = them. If so, perhaps we should at least suggest to the SAE (Society of = Automotive Engineers), which makes standards for that industry, that they = look at whether it makes sense for all of the companies to take a uniform = approach to how they do that. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) > On Feb 19, 2013, at 5:09 PM, Owen DeLong = > wrote: I do not support allocating globally unique prefixes for things that are = not networks. Perhaps that will better explain my position. I think that overloading the IPv6 prefix space with semantics for = arbitrary collections of things is a really bad idea that has tremendous = potential to consume vast amounts of addresses while yielding no network = benefit in return. Will it exhaust the IPv6 space immediately, probably not. Could we easily = exhaust the ASN space if we start promoting the idea of claiming ASNs to = support this? Yeah, we could probably burn 4 billion ASNs that way without = too much trouble. _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A24732APWN401EA160entc_ 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-->

This is very similar to something we were = exploring in the Medical/Insurance realms.   That is using IPV6 = addresses for  entities/artifacts such as Claim or Subscriber numbers.    ARIN did not like that as rationale = for additional or larger address space as alluded by Owen = below.      But similar approaches are =  being considered in multiple industries.  

 

Why would that be preferred over MAC & = SLAAC?    Not sure at this point as this is still being = explored.  but possibly being more predictable, controlled and self documenting?     

 

From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Owen DeLong
Sent: Wednesday, February 20, 2013 8:45 PM
To: Bill Jouris
Cc: v6ops=40ietf.org
Subject: Re: =5Bv6ops=5D Comments to = draft-mlevy-v6ops-auto-v6-allocation-per-asn

 

Bill

 

I think that sums it up reasonably well. = However, if they come back to the RIR for more space and try to use having = put a bunch of numbers on VINs/Cars addressed by VIN that are not actually = networked to the company using a network that topologically matches the numbering

scheme, then, the RIR should rightly count = those addresses as not utilized in determining eligibility for additional = space.

 

If you feel that some sort of recommendation to = SAE is worth while, go for it. Personally, I don't understand the need for = a car to have a permanently assigned prefix rather than just a MAC address = and then get its prefix through SLAAC or get its addressing via DHCP.

 

If someone can explain this, I am open to being = better convinced.

 

Owen

 

On Feb 20, 2013, at 14:20 , Bill Jouris <bill.jouris=40insideth= estack.com> wrote:



Owen,

So what you seem to be saying is: If manufacturers want to use a specific = part of their company allocation of addresses to give addresses to the = cars that they make based on VIN numbers, that is up to them.  But = IETF should not mandate allocating part of the overall spectrum of addresses to them.

If so, perhaps we should at least suggest to the SAE (Society of = Automotive Engineers), which makes standards for that industry, that they = look at whether it makes sense for all of the companies to take a uniform = approach to how they do that.

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


> On Feb 19, 2013, at 5:09 PM, Owen DeLong <owen=40delong.= com> wrote:


I do not support allocating globally unique prefixes for things that are = not networks.

Perhaps that will better explain my position.

I think that overloading the IPv6 prefix space with semantics for = arbitrary collections of things is a really bad idea that has tremendous = potential to consume vast amounts of addresses while yielding no network = benefit in return.

Will it exhaust the IPv6 space immediately, probably not. Could we easily = exhaust the ASN space if we start promoting the idea of claiming ASNs to = support this? Yeah, we could probably burn 4 billion ASNs that way without = too much trouble.

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

 


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

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

--_000_4FC37E442D05A748896589E468752CAA0A24732APWN401EA160entc_-- From marka@isc.org Wed Feb 20 21:29: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 5049E21F8CE3 for ; Wed, 20 Feb 2013 21:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_50=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwgrQLdzM4AN for ; Wed, 20 Feb 2013 21:29:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 509F621E809B for ; Wed, 20 Feb 2013 21:29:42 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 66BB3C9503; Thu, 21 Feb 2013 05:29:33 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361424580; bh=2/U3i9h9GIgCf5gXUodDA3qn0f5khiIrRf3Wnkv0LlI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=p6cmAD99nSoDjDkiqIHdyyPWhm/wOQZJi+DLUvH4GBBrQawg0LGcNSh9hnYBk8Kxk pq+lnr/jRzzZ3r4Y3mJLV3kVNoQXa13JD532/ZFHnIV3m1MMWzfJzNNaohRb7yV4Lv ntqC/7SHgXwGG6S+4bMTUjW0g4C7su6LEVKJLVOg= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 21 Feb 2013 05:29:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CDC30216C3B; Thu, 21 Feb 2013 05:29:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 57DD52FEE70B; Thu, 21 Feb 2013 16:29:19 +1100 (EST) To: Mark Smith From: Mark Andrews References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-reply-to: Your message of "Wed, 20 Feb 2013 19:07:28 -0800." <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 21 Feb 2013 16:29:18 +1100 Message-Id: <20130221052919.57DD52FEE70B@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 05:29:43 -0000 In message <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com>, Mark S mith writes: > Ok. > > Lets look at the experience I and others have had using 127/8 > > 1. it has been easy to remember so is fc00::/48 > 2. it has been (pretty) easy to type so is fc00::/48 > 3. it has always been there > > 4. there has been a well known 127.0.0.1/8 automatically configured > address, visible to the user and assisting their memory So is ::1 if you have IPv6 enabled. Note 127.0.0.1/8 may not be available on some nodes as they remove IPv4 support. > 5. it has uniquely identified the loopback interface As would fc00::/48 if it was assigned for that purpose. > 6. common hosts (windows/Linux and probably other unicies (from distant > memory, HP-UX probably)) all addresses within 127/8 have also been > conceptually assigned (e.g. http:://127.1.2.3:80/ just worked, as did > http://127.8.7.6:80, without configuration). IOW, there were plenty of > automatically configured addresses, and no additional effort required to > enable them Having addresses other than 127.0.0.1 usable in any form by default is implementation dependent. > 7. traffic towards all addresses within 127/8 never leaked from the host, > because it was configured to loop traffic by default at system > initialisation And one can achieve that with a ULA address and a firewall if you want to. > ::1/128 provides IPv6 equivalents of 1,2,3,4,5 and 7. It does not provide > multiple addresses (6). A larger version of ::/128, that satisfies 1 > through 7 is the motive for this draft. > Other prefixes suggested (and ones I considered and tried using before I > started writing this draft) would need specification updates to > automatically behave as above. Otherwise they need manual configuration, > possibly in addition to violation of their intended use and form. Well you can't meet 3 as it was not backed into the original design > For example, fe80::1/10 might be automatically configured on Mac OS X on > the loopback interface, but can you use fe80::2, fe80::3, fe80::4567:1234 > and have them all automatically work? Special link-local behaviour on the > loopback interface isn't specified as far as I know, so it probably won't > So it doesn't satisfy 3 and 5, and since link-local doesn't have anything > to distinguish the link local prefix on loopback from eth0, you also have > to specify an interface, so it also fails 2. > > A non-unique ULA of fd00::/64 fails 3, 4, 5 and 6. Nothing can meet 3 unless you have a time machine. fd00::/64 or fc00::/64 will meet 4 and that is just a matter of familiarity with whatever address range is choosen. There was nothing special about 10/8 or 172.16/12 or 192.168/16 apart from 10/8 being available. Most people involved with configuring machines can identify these ranges. fc00::/64 can meet 5 as can any prefix that gets reserved. 6 is a implementation detail that is not required for RFC conformance and is not implemented on many platforms. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From markzzzsmith@yahoo.com.au Wed Feb 20 22:22: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 8E4D521F8DEB for ; Wed, 20 Feb 2013 22:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.582 X-Spam-Level: * X-Spam-Status: No, score=1.582 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqg2GkhDHqaT for ; Wed, 20 Feb 2013 22:22:23 -0800 (PST) Received: from nm16-vm0.bullet.mail.bf1.yahoo.com (nm16-vm0.bullet.mail.bf1.yahoo.com [98.139.212.253]) by ietfa.amsl.com (Postfix) with SMTP id 7B11F21F8DE3 for ; Wed, 20 Feb 2013 22:22:23 -0800 (PST) Received: from [98.139.212.146] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 06:22:22 -0000 Received: from [98.139.212.202] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 06:22:22 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 06:22:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 910064.39378.bm@omp1011.mail.bf1.yahoo.com Received: (qmail 29763 invoked by uid 60001); 21 Feb 2013 06:22:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361427742; bh=XB1VYv6JLpcLy7rEMZabT/TLUP7LPEve7/ub4bQXZ/4=; 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=kFv6O7H8CRDaOA7O/f4SibNmRRWM7yR68ivAqWDs6P4UKO3gNEBVRd+9kjBlwXEqRsw7KOIJVIWuM5dTIoIfJ62dvNt+Dq/x78mQyMvjfvPX732aYetVkOO1KLORRqwNLELrP+Rl+DCrLwofRX6peALINieVbsJ6Rqf1C6YeRyc= 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=Pd8YuIbAgvIaT3OPnV4v8BbQaOxSBgGFcFtQOtbLX8wsPgpx0iSvxhgOUMH33FCsjMOCz2gfuzJ47P5Tsdqf8GXuHKREvaI5rQ6pwlkEbiiPK0/OsEo4CKYSH+L6Peg+UrU8KcIcmdCJdMeuOcOdNfuo/rffcUkNgdzA201GQsQ=; X-YMail-OSG: kVHEZZwVM1lj7mmfwmlB4dtf0kT12BgiR0zGHqCBGBz6BCY 8bRoJRECIVEuTrjnmYwn.XP47gFUeo0L_LQdnsF99IJ7Sg01Yu6eBSOXOoZR rq5PwUmRhFbdTHHPP5DiCJsevIBBllUYeEhMgLVJqcmbM20ixi5Xmn1IssZb JOAbFy14eG1lJViwY6BC3TadF9yeNuuhdsDrxMKRuzgLLlUuR_JaTZ9WIYJ_ 9q.Xb3tkb.T6yk6Par4ofy1zjlGXgQIMuNuhvmfX0HzU6pAV.7RqlXkjk06i PkADSgV.3q3_th8_t.2ykW88Hw8.UD.HnMdjG7ZwcRucKWwmF4kwBoixUUQI sgAwJiwo3zZjhskECBu3y6.M39B0F9_u41FQVo1pY9kwcRaoupomnfjfUmqj kV0Q0cQDOnxFvrRILmyxLmaDuCU2l_qvNqgsJr.pSu.7UsePJU6UVRUph75E q3UsAyaBxzo9uWOGa97__V0HtwX6PaTSqBPHUzoiEft0KR4IRZ5eiezk25SN _YrU64q8JKiY2QA_Mh7OC9bbchODaNvKIFAjGA_7D6C7JCVhPUykvuFTnvjf CLgQhQSh_Jg5KXDWnxpJJl2Mo0gHqWGUCng7JAIUUpjvb0uEtW95Tentbihm f2BTott_wnAAKI6OpqEZYt6Qm0F483nE- Received: from [121.200.231.211] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 20 Feb 2013 22:22:22 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIEFuZHJld3MgPG1hcmthQGlzYy5vcmc.Cj4gVG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6IE93ZW4gRGVMb25nIDxvd2VuQGRlbG9uZy5jb20.OyB2Nm9wcyB2Nm9wcyBXRyA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogVGh1cnNkYXksIDIxIEZlYnJ1YXJ5IDIwMTMgNDoyOSBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> <20130221052919.57DD52FEE70B@drugs.dv.isc.org> Message-ID: <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 22:22:22 -0800 (PST) From: Mark Smith To: Mark Andrews In-Reply-To: <20130221052919.57DD52FEE70B@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:22:27 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mark Andrews =0A> To: Mark Smith =0A> Cc: Owen DeLong ; v6ops v6ops WG =0A> Sent: Thursday, 21 Febr= uary 2013 4:29 PM=0A> Subject: Re: [v6ops] Fw: New Version Notification for= draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt=0A> =0A> =0A> In mess= age <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com>, =0A> Mark= S=0A> mith writes:=0A>> Ok.=0A>> =0A>> Lets look at the experience I and= others have had using 127/8=0A>> =0A>> 1. it has been easy to remember=0A= > =0A> so is fc00::/48=0A>=A0=0A=0Asigh. RFC4193:=0A=0A"3.2. Global ID=0AT= he allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT be as= signed sequentially or with well-known numbers."=0A=0AGiven your name is on= the top of RFC6303, I'd have thought you'd agree it is important to follow= what is in them.=0A=0A>> 2. it has been (pretty) easy to type=0A> =0A> so= is fc00::/48=0A> =0A>> 3. it has always been there=0A>> =0A>> 4. there h= as been a well known 127.0.0.1/8 automatically configured =0A>> address, v= isible to the user and assisting their memory=0A> =0A> So is ::1 if you hav= e IPv6 enabled.=A0 Note 127.0.0.1/8 may not be=0A> available on some nodes = as they remove IPv4 support.=0A> =0A>> 5. it has uniquely identified the l= oopback interface=0A> =0A> As would fc00::/48 if it was assigned for that p= urpose.=0A> =0A>> 6. common hosts (windows/Linux and probably other unicie= s (from distant =0A>> memory, HP-UX probably)) all addresses within 127/8 = have also been =0A>> conceptually assigned (e.g. http:://127.1.2.3:80/ jus= t worked, as did =0A>> http://127.8.7.6:80, without configuration). IOW, t= here were plenty of =0A>> automatically configured addresses, and no addit= ional effort required to =0A>> enable them=0A> =0A> Having addresses other= than 127.0.0.1 usable in any form by default=0A> is implementation depende= nt.=0A> =0A>> 7. traffic towards all addresses within 127/8 never leaked f= rom the host, =0A>> because it was configured to loop traffic by default a= t system =0A>> initialisation=0A> =0A> And one can achieve that with a ULA= address and a firewall if you want to. =0A> =0A>> ::1/128 provides IPv6 e= quivalents of 1,2,3,4,5 and 7. It does not provide =0A>> multiple addresse= s (6). A larger version of ::/128, that satisfies 1 =0A>> through 7 is the= motive for this draft.=0A> =0A>> Other prefixes suggested (and ones I con= sidered and tried using before I =0A>> started writing this draft) would n= eed specification updates to =0A>> automatically behave as above. Otherwis= e they need manual configuration, =0A>> possibly in addition to violation = of their intended use and form.=0A> =0A> Well you can't meet 3 as it was no= t backed into the original design=0A> =0A>> For example, fe80::1/10 might = be automatically configured on Mac OS X on =0A>> the loopback interface, b= ut can you use fe80::2, fe80::3, fe80::4567:1234 =0A>> and have them all a= utomatically work? Special link-local behaviour on the =0A>> loopback inte= rface isn't specified as far as I know, so it probably =0A> won't =0A>> So= it doesn't satisfy 3 and 5, and since link-local doesn't have =0A> anythin= g =0A>> to distinguish the link local prefix on loopback from eth0, you al= so have =0A>> to specify an interface, so it also fails 2.=0A>> =0A>> A n= on-unique ULA of fd00::/64 fails 3, 4, 5 and 6.=0A> =0A> Nothing can meet 3= unless you have a time machine.=0A> =0A> fd00::/64 or fc00::/64 will meet = 4 and that is just a matter of=0A> familiarity with whatever address range = is choosen.=A0 There was=0A> nothing special about 10/8 or 172.16/12 or 192= .168/16 apart from=0A> 10/8 being available.=A0 Most people involved with c= onfiguring machines=0A> can identify these ranges.=0A> =0A> fc00::/64 can m= eet 5 as can any prefix that gets reserved.=0A> =0A> 6 is a implementation = detail that is not required for RFC conformance=0A> and is not implemented = on many platforms.=0A> =0A> Mark=0A> -- =0A> Mark Andrews, ISC=0A> 1 Seymou= r St., Dundas Valley, NSW 2117, Australia=0A> PHONE: +61 2 9871 4742=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org=0A> From marka@isc.org Wed Feb 20 23:03: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 2C1A421F84C6 for ; Wed, 20 Feb 2013 23:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKApiiftlUi6 for ; Wed, 20 Feb 2013 23:03:38 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 4515521F88FD for ; Wed, 20 Feb 2013 23:03:38 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7DCAE5F991D; Thu, 21 Feb 2013 07:03:26 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361430217; bh=+sPN6p2upJ7S6uPEAe4LNqd18HyZQyX2KZnGUPR2yAg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=P9pfBNPHq7kIh+bJa8FlWxXbPk1rZwon+ho5qwlPrC1WFdkFItRIGQoU3SoLKQ/B9 fZFL2gRgP7FNgD/mPn8b2rHZyt+T1k6Ij5uIoojyGba45BIbDfoM6qJ+Dd/Ryj1Jit zIfa8fvaQ1dDqjKanbVLgkj4vBxcNZAE/t/IWcTE= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 77264216C3B; Thu, 21 Feb 2013 07:03:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2F47C2FEF2AC; Thu, 21 Feb 2013 18:03:14 +1100 (EST) To: Mark Smith From: Mark Andrews References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> <20130221052919.57DD52FEE70B@drugs.dv.isc.org> <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-reply-to: Your message of "Wed, 20 Feb 2013 22:22:22 -0800." <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 21 Feb 2013 18:03:14 +1100 Message-Id: <20130221070314.2F47C2FEF2AC@drugs.dv.isc.org> Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 07:03:39 -0000 In message <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com>, Mark S mith writes: > ----- Original Message ----- > > From: Mark Andrews > > To: Mark Smith > > Cc: Owen DeLong ; v6ops v6ops WG > > Sent: Thursday, 21 February 2013 4:29 PM > > Subject: Re: [v6ops] Fw: New Version Notification for > draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt > > > > > > In message > <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com>, > > Mark S > > mith writes: > >> Ok. > >> > >> Lets look at the experience I and others have had using 127/8 > >> > >> 1. it has been easy to remember > > > > so is fc00::/48 > > > > sigh. RFC4193: > > "3.2. Global ID > The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT be > assigned sequentially or with well-known numbers." > > Given your name is on the top of RFC6303, I'd have thought you'd agree it > is important to follow what is in them. Reserving fc00::/48 for loopback purposes would have no impact on RFC6303 you will note the 127.in-addr.arpa is one of the listed prefixes. And if you were to read the rest of the section you quotes you will see that fc00::/48 is still reserved. "This document defines a specific local method to allocate Global IDs, indicated by setting the L bit to 1. Another method, indicated by clearing the L bit, may be defined later." fc00::/48 is still fair game for this purpose. ULA locally or centrally assigned are all potentially ambigious. Neither are expected to be routed over the Internet. A reserved loopback prefix by definion is always ambigious. fc00::/48 would not be ambigous within the context of a node. fc00::/48 has the advantage that leaked packets / routes are already subject to filtering restrictions. 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 Wed Feb 20 23:07: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 C9C6521F8E06 for ; Wed, 20 Feb 2013 23:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqiM4V1aFNLR for ; Wed, 20 Feb 2013 23:07:59 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 30C4821F8C6B for ; Wed, 20 Feb 2013 23:07:57 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id ta14so8586716obb.0 for ; Wed, 20 Feb 2013 23:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uH1h486mFPdJw2Lm0y+0b1FfBqOnq+v+ShO9FbXrSas=; b=HhkNhjbd4GKC4BoBLne8lziCnlVodHricK7xVU57bXzf+HRKTmE0tl7Q6xy2a1vVJ/ KOiWZ5YRdf4lLmfmKOiT775IcjJiAK91MkYpeR7pHNZ+9g8YINsugbdUvQyGFNKSlLsn VoG/J/JmmV3lTU+gY2zWVZj8sTk3Z0Rb0uIGt/dJPKHew7CFgqLQa/nXVF7o8dlwtOI9 eeGcw7q0JuH31VHWMMVhxRFZ/n0npcnb2NuoBFNmDzi8Ud7JzRwwcIxIzbqhknEtJjyc twnNM6NwIPHhilS0zZ/A9yojjlmscd5zWBVDcUCgdKu/R1gUKd2qWB6DegUB6AQ2oR+l /biA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=uH1h486mFPdJw2Lm0y+0b1FfBqOnq+v+ShO9FbXrSas=; b=YdUPlEb5ZyVN3IL3BhHeIYmiovnT040DNPk0/uVungTumIAcRd/MNb3UPvzGSr/GpU HIvwaffeojwk6sWMVYLul3am5fbmBEMqZ3nLaY9/u5NG7BGg9WQcAXytsE4rIDhvUZ6g iQDFzFCZIUIWPw/otA0GIoFV4jjMnCcS8wHyxGXhty+enuLlF5DaCWMNjyC3T3Cil3nA je8LUJ14e5vAXLWgClp8GeUiLYyuLoxoCMTYbjEvttxL6LBhO8v4zCZ5koxCDWNdwbP9 gsQx2gfmnPAB3i3vHmOkSGAAwGIVacZ2q9uWweuS/vyK0MkY80kCBHUj/7AEiToWgCpt tLLw== X-Received: by 10.60.172.18 with SMTP id ay18mr10301427oec.126.1361430474439; Wed, 20 Feb 2013 23:07:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 20 Feb 2013 23:07:33 -0800 (PST) In-Reply-To: <20130221070314.2F47C2FEF2AC@drugs.dv.isc.org> References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> <20130221052919.57DD52FEE70B@drugs.dv.isc.org> <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com> <20130221070314.2F47C2FEF2AC@drugs.dv.isc.org> From: Lorenzo Colitti Date: Thu, 21 Feb 2013 16:07:33 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=bcaec54fae48d0bdb704d636bba2 X-Gm-Message-State: ALoCoQnLJfV7UmYJ6env+U2pwWZVnFqEg3F1AmuFS3sFB4UpbLp9QAanIsm8x6QOnliAYN+/U9QXnDuRBBytW4L/V/6Unk5Oqxxnkfm4DxlQa6NaXslPbMwz6kiOONWE8bWn5ujTGenylJHHMTvIAvOmO+N3oDdfK5ZeQFFvfXdkMQZE8r+24szQjHRMYIBcm/a6eemd3AZB Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 07:08:00 -0000 --bcaec54fae48d0bdb704d636bba2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 21, 2013 at 4:03 PM, Mark Andrews wrote: > fc00::/48 is still fair game for this purpose. ULA locally or > centrally assigned are all potentially ambigious. If that were so, ULA addresses would not be specified as having global scope. Even if we do assign fc00::/48 as a loopback prefix, it will be considered to have global scope for all implementations that have not yet been updated. That seems undesirable. --bcaec54fae48d0bdb704d636bba2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 21, 2013 at 4:03 PM, Mark Andrews <marka@isc.org<= /a>> wrote:
fc00::/48 is still fair game for this purpose. =A0ULA locally or
centrally assigned are all potentially ambigious.

If that were so, ULA addresses would not be specified as havin= g global scope.

Even if we do assign f= c00::/48 as a loopback prefix, it will be considered to have global scope f= or all implementations that have not yet been updated. That seems undesirab= le.
--bcaec54fae48d0bdb704d636bba2-- From owen@delong.com Wed Feb 20 23:10: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 E32A021F8DD7 for ; Wed, 20 Feb 2013 23:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiNN8uZ2W34V for ; Wed, 20 Feb 2013 23:10:43 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A1CA521F8E0A for ; Wed, 20 Feb 2013 23:10:43 -0800 (PST) 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 r1L76BX6018096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2013 23:06:11 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1L76BX6018096 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361430371; bh=cxFdPSm+3OB4QeICkMSLELwFF5A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZUemLRRAm2AgT2VnglV2r+rlcIE7fEuJp+oeG/TobI3qR1Urtl0Fxw1HsgWhqmY0a s0bdKsacs9zpAqSWQFwNK5wTu/jyniJP30jC+PrQ54xYec6ZgHevlUk+jV+WDtUjn6 gwTcu+aZ0ntlNvLBSBB5lI4WHF8fcFd2MiaE0rx4= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 23:06:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5B975716-59C8-4F7C-9C6F-373A150EE4D1@delong.com> References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> <20130221052919.57DD52FEE70B@drugs.dv.isc.org> <1361427742.78324.YahooMailNeo@web142504.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Feb 2013 23:06:11 -0800 (PST) Cc: v6ops v6ops WG Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 07:10:45 -0000 >>>=20 >>> 1. it has been easy to remember >>=20 >> so is fc00::/48 >> =20 >=20 > sigh. RFC4193: >=20 > "3.2. Global ID > The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT = be assigned sequentially or with well-known numbers." >=20 > Given your name is on the top of RFC6303, I'd have thought you'd agree = it is important to follow what is in them. >=20 RFC4193 does not apply to fc00::/48. It only applies to fd00::8. = fc00::/8 currently has no RFCs specifying it other than the part of 4193 = that says it is intended for globally unique registered ULA. However, = the companion RFC that provided for that failed to gain consensus, so = fc00::/8 is actually in limbo. As far as I'm concerned, this would be a = perfectly fine use of fc00::/48 as the first registered ULA. Further, when considering RFCs in a particular use case, I think it is = important to apply the context of WHY the RFC says what it says. In this = case, there is no downside to (mis)using ULA in this way on a local = basis because you can choose a non-conflicting ULA prefix pretty easily. = Afterall, all that is required is that it not conflict with ULA in use = by any of the machines that your test subject will be sending packets = to. Blind adherence to the RFCs without context is almost as silly as blind = ignorance of them. Owen From joelja@bogus.com Wed Feb 20 23:22: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 2DE2C21F8E08 for ; Wed, 20 Feb 2013 23:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYqbuoOYcF-w for ; Wed, 20 Feb 2013 23:22:19 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1258121F8E07 for ; Wed, 20 Feb 2013 23:22:18 -0800 (PST) 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 r1L7MHgo034091 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 21 Feb 2013 07:22:17 GMT (envelope-from joelja@bogus.com) Message-ID: <5125CB24.1090104@bogus.com> Date: Wed, 20 Feb 2013 23:22:12 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Bill Jouris , v6ops@ietf.org References: <1361398846.4312.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> In-Reply-To: <1361398846.4312.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 21 Feb 2013 07:22:17 +0000 (UTC) Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 07:22:20 -0000 On 2/20/13 2:20 PM, Bill Jouris wrote: > Owen, > > So what you seem to be saying is: If manufacturers want to use a > specific part of their company allocation of addresses to give > addresses to the cars that they make based on VIN numbers, that is up > to them. But IETF should not mandate allocating part of the overall > spectrum of addresses to them. > The assignment of global unicast v6 addresses to Registries, LIRs, service providers and direct assignments is done elsewhere. We have examples of aircraft and other large structures such as airports/tunnels and buildings receiving prefixes from their manufacturers which had originally been obtained from RIRs. > If so, perhaps we should at least suggest to the SAE (Society of > Automotive Engineers), which makes standards for that industry, that > they look at whether it makes sense for all of the companies to take a > uniform approach to how they do that. > > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) > > > > On Feb 19, 2013, at 5:09 PM, Owen DeLong > wrote: > > > I do not support allocating globally unique prefixes for things > that are not networks. > > Perhaps that will better explain my position. > > I think that overloading the IPv6 prefix space with semantics for > arbitrary collections of things is a really bad idea that has > tremendous potential to consume vast amounts of addresses while > yielding no network benefit in return. > > Will it exhaust the IPv6 space immediately, probably not. Could we > easily exhaust the ASN space if we start promoting the idea of > claiming ASNs to support this? Yeah, we could probably burn 4 > billion ASNs that way without too much trouble. > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Thu Feb 21 00:43: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 C34AC21F8414 for ; Thu, 21 Feb 2013 00:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.081 X-Spam-Level: X-Spam-Status: No, score=-3.081 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVWRl0RUNjBk for ; Thu, 21 Feb 2013 00:43:03 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5702221F8DD7 for ; Thu, 21 Feb 2013 00:43:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8D741870098; Thu, 21 Feb 2013 09:37:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 6OS0t5r2YLP2; Thu, 21 Feb 2013 09:37:25 +0100 (CET) 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 3F56A870081; Thu, 21 Feb 2013 09:37:25 +0100 (CET) Message-ID: <5125DCBE.40902@globis.net> Date: Thu, 21 Feb 2013 09:37:18 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: "Ackermann, Michael" References: <1361398846.4312.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A24732A@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A24732A@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 08:43:18 -0000 I have been trying hard to understand this thread and I have to admit that the background motivation still remains opaque to me. If I understand correctly, a car already has an L8 ID: the VIN. Why is there any good architectural reason to tie the VIN or any other L8 identifier to any L2 LAN hardware or L3 addressing at all? And especially via a static mapping? I can think of many counter-reasons. It's forbidden in Europe to use any government assigned L8 ID associated with an individual (e.g. medical insurance number) for any purpose other than that for which it was specifically intended: Article 24 WBP. Vice versa is also true: you have to keep the personal data private, so leaking personal data into L2/L3 is also a no-go. Medical ID's are especially sensitive, and fall under the rules for processing "special personal data". IMHO We should almost certainly explicitly tell these "multiple industries" NOT to assume ANY link between L2/L3 and L8, or make any assumptions about the structure of the IPv6 addressing space beyond that documented in RFCs. If they want to have some industry-specific L8 idents for use in an application or DB, they should arrange these themselves via an appropriate industry-specific group. If they want to communicate industry-specific L8 ID's over a network, they should encode these within the application-layer protocol, not in the transport layer. regards, RayH Ackermann, Michael wrote: > > This is very similar to something we were exploring in the > Medical/Insurance realms. That is using IPV6 addresses for > entities/artifacts such as Claim or Subscriber numbers. ARIN did > not like that as rationale for additional or larger address space as > alluded by Owen below. But similar approaches are being > considered in multiple industries. > > > > Why would that be preferred over MAC & SLAAC? Not sure at this > point as this is still being explored. but possibly being more > predictable, controlled and self documenting? > > > > *From:*v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On > Behalf Of *Owen DeLong > *Sent:* Wednesday, February 20, 2013 8:45 PM > *To:* Bill Jouris > *Cc:* v6ops@ietf.org > *Subject:* Re: [v6ops] Comments to > draft-mlevy-v6ops-auto-v6-allocation-per-asn > > > > Bill > > > > I think that sums it up reasonably well. However, if they come back to > the RIR for more space and try to use having put a bunch of numbers on > VINs/Cars addressed by VIN that are not actually networked to the > company using a network that topologically matches the numbering > > scheme, then, the RIR should rightly count those addresses as not > utilized in determining eligibility for additional space. > > > > If you feel that some sort of recommendation to SAE is worth while, go > for it. Personally, I don't understand the need for a car to have a > permanently assigned prefix rather than just a MAC address and then > get its prefix through SLAAC or get its addressing via DHCP. > > > > If someone can explain this, I am open to being better convinced. > > > > Owen > > > > On Feb 20, 2013, at 14:20 , Bill Jouris > > wrote: > > > > Owen, > > So what you seem to be saying is: If manufacturers want to use a > specific part of their company allocation of addresses to give > addresses to the cars that they make based on VIN numbers, that is up > to them. But IETF should not mandate allocating part of the overall > spectrum of addresses to them. > > If so, perhaps we should at least suggest to the SAE (Society of > Automotive Engineers), which makes standards for that industry, that > they look at whether it makes sense for all of the companies to take a > uniform approach to how they do that. > > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) > > > > On Feb 19, 2013, at 5:09 PM, Owen DeLong > wrote: > > > I do not support allocating globally unique prefixes for things that > are not networks. > > Perhaps that will better explain my position. > > I think that overloading the IPv6 prefix space with semantics for > arbitrary collections of things is a really bad idea that has > tremendous potential to consume vast amounts of addresses while > yielding no network benefit in return. > > Will it exhaust the IPv6 space immediately, probably not. Could we > easily exhaust the ASN space if we start promoting the idea of > claiming ASNs to support this? Yeah, we could probably burn 4 billion > ASNs that way without too much trouble. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > The information contained in this communication is highly confidential > and is intended solely for the use of the individual(s) to whom this > communication is directed. If you are not the intended recipient, you > are hereby notified that any viewing, copying, disclosure or > distribution of this information is prohibited. Please notify the > sender, by electronic mail or telephone, of any unintended receipt and > delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan > are nonprofit corporations and independent licensees of the Blue Cross > and Blue Shield Association. > From ales.vizdal@t-mobile.cz Thu Feb 21 01:43: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 CC57C21F8DF0 for ; Thu, 21 Feb 2013 01:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4cXTUxkapVc for ; Thu, 21 Feb 2013 01:43:19 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9F21F8921 for ; Thu, 21 Feb 2013 01:43:16 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 28CDE28582D; Thu, 21 Feb 2013 10:43:15 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 21 Feb 2013 10:43:15 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "sarikaya@ieee.org" , Cameron Byrne Date: Thu, 21 Feb 2013 10:43:17 +0100 Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks Thread-Index: Ac4PvBVq66YhToHST1+YkYPafxu/XQAWmi/w Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFB3C073@SRVHKE02.rdm.cz> References: 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_1808340F7EC362469DDFFB112B37E2FCC6CFB3C073SRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Ops WG Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 09:43:19 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCC6CFB3C073SRVHKE02rdmcz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Behcet, From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of B= ehcet Sarikaya Sent: Wednesday, February 20, 2013 11:46 PM To: Cameron Byrne Cc: IPv6 Ops WG Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks Hi Cameron, sorry for my belated reply. On Sun, Feb 3, 2013 at 7:37 PM, Cameron Byrne > wrote: Since a lot of folks talk about IPv6 in mobile, i figured i would pen my own view and experience here. It hopefully will set some context for the WG work products draft-ietf-v6ops-464xlat, draft-ietf-v6ops-64share, draft-binet-v6ops-cellular-host-requirements. Please do note 464XLAT is not 3GPP/mobile specific. AFAIK, there is exactly 1 provider in the world of 3GPP that offers dual-stack service by default, Verizon Wireless (hat tip). I did not count, but there is probably more that 50 LTE networks out there today http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be some others that support default-on dual-stack, i but i don't know of them. So, conclusion #1 is that that LTE does not require or even help IPv6 deployment. Look at the facts. There is a long list of LTE networks that definitely do not have IPv6 or dual-stack by default: AT&T, Sprint, EE, T-Mobile DE, Rogers, Vodafone, .. Maybe they realized that NAT44 is good enough for them to handle not so man= y LTE customers they have? They already know NAT44 technology. I would simply assume that IPv6/Dual-Stack would take much more time to imp= lement, so the launch date would be in danger. I believe a lot of folks, myself included, thought network upgrades would bring about more IPv6 features and deployment. In my own experience, this is the exact opposite in reality. Let me explain. There are 4 major providers of 3GPP equipment. I will exonerate Huawei since i don't know anything about them and Cisco because i know there stuff works (AFAIK). The other 2 providers are specifically defunct on the IPv4v6 front. One -- has a brand new high capacity P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6). And the other, which is painfully wrecking my IPv4v6 deployment plans, has a newish (few years old now) high capacity SGSN which does not support IPv4v6 (also supports v4 or v6). This should be OK for SGSN because you don't even need SGSN to support IPv= 6 in order to support IPv6 in your network, right? because of the inherent = tunneling. You don't need IPv6 support at the user plane level as the traffic is tunne= lled in GTP (transparent to the SGSN/SGW), but you still need IPv6/Dual-Sta= ck support on the control plane level and that's the issue. This seems to be the main issue. What a pity :-). Regards, Behcet Cheers, Ales --_000_1808340F7EC362469DDFFB112B37E2FCC6CFB3C073SRVHKE02rdmcz_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Behcet,

 

From: v6= ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Be= hcet Sarikaya
Sent: Wednesday, February 20, 2013 11:46 PM
T= o: Cameron Byrne
Cc: IPv6 Ops WG
Subject: Re: [v6op= s] State of IPv6 in Mobile Cellular Networks

 

Hi Cameron,

sorry for my belated reply.

On Sun, Feb 3, 2013 at 7:37 PM, Cameron B= yrne <cb.list6@g= mail.com> wrote:

<rant>

Since a lot of folks talk about IPv6 in = mobile, i figured i would pen
my own view and experience here.  It = hopefully will set some context
for the WG work products draft-ietf-v6op= s-464xlat,
draft-ietf-v6ops-64share,
draft-binet-v6ops-cellular-host-= requirements.  Please do note 464XLAT
is not 3GPP/mobile specific.<= br>
AFAIK, there is exactly 1 provider in the world of 3GPP that offers<= br>dual-stack service by default, Verizon Wireless (hat tip).  I did n= ot
count, but there is probably more that 50 LTE networks out there toda= y
http://en.wikipedia.org/wiki/List_of_LTE_networks .. There = may be some
others that support default-on dual-stack, i but i don't kno= w of them.

So, conclusion #1 is that that LTE does not require or ev= en help IPv6
deployment.  Look at the facts. There is a long list o= f LTE networks
that definitely do not have IPv6 or dual-stack by default= :  AT&T,
Sprint, EE, T-Mobile DE, Rogers, Vodafone, ..


Maybe they realized that NAT44 is good = enough for them to handle not so many LTE customers they have? They already= know NAT44 technology.
 

 

I would simply ass= ume that IPv6/Dual-Stack would take much more time to implement, so the lau= nch date would be in danger.

 

 

I believe a lot of folks, myself included, thought network = upgrades
would bring about more IPv6 features and deployment.  In m= y own
experience, this is the exact opposite in reality.  Let me ex= plain.

There are 4 major providers of 3GPP equipment.  I will e= xonerate
Huawei since i don't know anything about them and Cisco because= i know
there stuff works (AFAIK).  The other 2 providers are speci= fically
defunct on the IPv4v6 front.  One -- has a brand new high c= apacity
P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6). =

 

=

 And
the other, which is painfully wrecking my IPv4v6 deploymen= t plans, has
a newish (few years old now) high capacity SGSN which does = not support
IPv4v6 (also supports v4 or v6).


 This sh= ould be OK for SGSN because you don't even need SGSN to support IPv6 in ord= er to support IPv6 in your network, right? because of the inherent tunnelin= g.

 

You don't need IPv6 support at the user plane lev= el as the traffic is tunnelled in GTP (transparent to the SGSN/SGW), but yo= u still need IPv6/Dual-Stack

support on the control plane level and that's the issue.

 


This seems to be the main issue.
What a pity :-).
=
Regards,

Behcet

 

Cheers,

Ales

= --_000_1808340F7EC362469DDFFB112B37E2FCC6CFB3C073SRVHKE02rdmcz_-- From david.binet@orange.com Thu Feb 21 02:42: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 B91ED21F8E64 for ; Thu, 21 Feb 2013 02:42:57 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqZxL6ws6fIF for ; Thu, 21 Feb 2013 02:42:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EDAC621F8E63 for ; Thu, 21 Feb 2013 02:42:56 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 82B4A22D174 for ; Thu, 21 Feb 2013 11:42:55 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6346C4C07F for ; Thu, 21 Feb 2013 11:42:55 +0100 (CET) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 21 Feb 2013 11:42:55 +0100 From: To: "v6ops@ietf.org" Date: Thu, 21 Feb 2013 11:42:53 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt Thread-Index: Ac4PwSJqFU2PkHSmQi6Wg6jFZboJMwAXBckg Message-ID: <21515_1361443375_5125FA2F_21515_1492_2_1B2E7539FECD9048B261B791B1B24A7C49B6CC62BF@PUEXCB1A.nanterre.francetelecom.fr> References: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> In-Reply-To: <20130220232210.10264.23244.idtracker@ietfa.amsl.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.2.19.124517 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.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, 21 Feb 2013 10:42:57 -0000 Hi all, This document proposes some means to enable some prefix sharing when PD is = not enabled or possible but I do not clearly understand how to "consider" t= he various scenarios. For example, we will have some smartphones, some CPEs= and other type of devices that may require such /64 prefix sharing capabi= lities and do we have to consider that these different devices should suppo= rt one given scenario.=20 I think it would be more efficient and more simple to only consider one sce= nario (for example the second one) to simplify relationships and requiremen= ts towards UE vendors as well as UEs behaviors considering that such capabi= lity should be a temporary solution. If several LAN interfaces are enabled on the UE, could we consider that som= e different scenarios could be retained by these different LAN interfaces ?= For example, if there is some Wi-Fi LAN and some bluetooth LAN, is there a= ny requirement about the IPv6 address to be configured or not on these vari= ous LAN interfaces.=20 David=20=20=20=20=20=20=20=20 > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > De la part de internet-drafts@ietf.org > Envoy=E9 : jeudi 21 f=E9vrier 2013 00:22 > =C0 : i-d-announce@ietf.org > Cc : v6ops@ietf.org > Objet : [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working=20 > Group of the IETF. >=20 > Title : Extending an IPv6 /64 Prefix from a=20 > 3GPP Mobile Interface to a LAN > Author(s) : Cameron Byrne > Dan Drown > Ales Vizdal > Filename : draft-ietf-v6ops-64share-03.txt > Pages : 8 > Date : 2013-02-20 >=20 > Abstract: > This document describes three methods for extending an IPv6 /64 > prefix from a User Equipment 3GPP radio interface to a LAN. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ales.vizdal@t-mobile.cz Thu Feb 21 04:22:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A1F21F8CA7 for ; Thu, 21 Feb 2013 04:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv0r3nbEqg+u for ; Thu, 21 Feb 2013 04:22:02 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id EB08721F8C9E for ; Thu, 21 Feb 2013 04:22:01 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id E4BDB285826; Thu, 21 Feb 2013 13:22:00 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 21 Feb 2013 13:22:00 +0100 From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: "david.binet@orange.com" , "v6ops@ietf.org" Date: Thu, 21 Feb 2013 13:22:03 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt Thread-Index: Ac4PwSJqFU2PkHSmQi6Wg6jFZboJMwAXBckgAAI7q7A= Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFB3C12E@SRVHKE02.rdm.cz> References: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> <21515_1361443375_5125FA2F_21515_1492_2_1B2E7539FECD9048B261B791B1B24A7C49B6CC62BF@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: <21515_1361443375_5125FA2F_21515_1492_2_1B2E7539FECD9048B261B791B1B24A7C49B6CC62BF@PUEXCB1A.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.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, 21 Feb 2013 12:22:03 -0000 SGkgRGF2aWQsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZg0KPiBkYXZpZC5iaW5ldEBvcmFuZ2UuY29tDQo+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAyMSwgMjAxMyAxMTo0MyBBTQ0KPiBUbzogdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02NHNoYXJlLTAzLnR4dA0KPiAN Cj4gIEhpIGFsbCwNCj4gDQo+IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgc29tZSBtZWFucyB0byBl bmFibGUgc29tZSBwcmVmaXggc2hhcmluZyB3aGVuIFBEIGlzIG5vdA0KPiBlbmFibGVkIG9yIHBv c3NpYmxlIGJ1dCBJIGRvIG5vdCBjbGVhcmx5IHVuZGVyc3RhbmQgaG93IHRvICJjb25zaWRlciIg dGhlIHZhcmlvdXMNCj4gc2NlbmFyaW9zLiANCg0KU2NlbmFyaW9zIHNoYWxsIGJlIHVuZGVyc3Rv b2QgYXMgb3B0aW9ucywgc28geW91IGNhbiBwaWNrIHRoZSBvbmUgdGhhdCBmaXRzIHRoZSBtb3N0 DQp0byB5b3VyIHVzZS1jYXNlLg0KDQo+IEZvciBleGFtcGxlLCB3ZSB3aWxsIGhhdmUgc29tZSBz bWFydHBob25lcywgc29tZSBDUEVzIGFuZCBvdGhlciB0eXBlIG9mDQo+IGRldmljZXMgdGhhdCBt YXkgcmVxdWlyZSBzdWNoIC82NCBwcmVmaXggc2hhcmluZyAgY2FwYWJpbGl0aWVzIGFuZCBkbyB3 ZSBoYXZlIHRvDQo+IGNvbnNpZGVyIHRoYXQgdGhlc2UgZGlmZmVyZW50IGRldmljZXMgc2hvdWxk IHN1cHBvcnQgb25lIGdpdmVuIHNjZW5hcmlvLg0KDQpJZiB5b3VyIHVzZS1jYXNlIHJlcXVpcmVz IHN0YWJsZSBHVUEgYWRkcmVzcyBvbiB0aGUgM0dQUCBsaW5rIHRvIG5vdCB0byBhZmZlY3QgYW55 IA0KcnVubmluZyBzZXJ2aWNlcyB5b3UgbWlnaHQgZ28gZm9yIHNjZW5hcmlvIDMsIGZvciBhIHRl dGhlcmluZyBib3ggc2NlbmFyaW8gMSAmIDIgY291bGQgDQpiZSBtb3JlIGFwcHJvcHJpYXRlLiAN Cg0KPiBJIHRoaW5rIGl0IHdvdWxkIGJlIG1vcmUgZWZmaWNpZW50IGFuZCBtb3JlIHNpbXBsZSB0 byBvbmx5IGNvbnNpZGVyIG9uZSBzY2VuYXJpbyAoZm9yDQo+IGV4YW1wbGUgdGhlIHNlY29uZCBv bmUpIHRvIHNpbXBsaWZ5IHJlbGF0aW9uc2hpcHMgYW5kIHJlcXVpcmVtZW50cyB0b3dhcmRzIFVF IHZlbmRvcnMNCj4gYXMgd2VsbCBhcyBVRXMgYmVoYXZpb3JzIGNvbnNpZGVyaW5nIHRoYXQgc3Vj aCBjYXBhYmlsaXR5IHNob3VsZCBiZSBhIHRlbXBvcmFyeQ0KPiBzb2x1dGlvbi4NCg0KV2hhdCdz IHRoZSBpc3N1ZSB3aXRoIG11bHRpcGxlIG9wdGlvbnMgYXZhaWxhYmxlIHRvIHRoZW0sIHNvIHRo ZXkgY2FuIHBpY2sgYW5kIGNob29zZT8NCg0KPiBJZiBzZXZlcmFsIExBTiBpbnRlcmZhY2VzIGFy ZSBlbmFibGVkIG9uIHRoZSBVRSwgY291bGQgd2UgY29uc2lkZXIgdGhhdCBzb21lIGRpZmZlcmVu dA0KPiBzY2VuYXJpb3MgY291bGQgYmUgcmV0YWluZWQgYnkgdGhlc2UgZGlmZmVyZW50IExBTiBp bnRlcmZhY2VzID8gRm9yIGV4YW1wbGUsIGlmIHRoZXJlIGlzDQo+IHNvbWUgV2ktRmkgTEFOIGFu ZCBzb21lIGJsdWV0b290aCBMQU4sIGlzIHRoZXJlIGFueSByZXF1aXJlbWVudCBhYm91dCB0aGUg SVB2Ng0KPiBhZGRyZXNzIHRvIGJlIGNvbmZpZ3VyZWQgb3Igbm90IG9uIHRoZXNlIHZhcmlvdXMg TEFOIGludGVyZmFjZXMuDQoNCklmIHNldmVyYWwgTEFOIGludGVyZmFjZXMgYXJlIHJlcXVpcmVk IHRvIGJlIG51bWJlcmVkIHRoYW4gREhDUC1QRCBzaGFsbCBiZSB1c2VkLiBJbiBzdWNoIA0KYSBj YXNlIHRoaXMgZHJhZnQgY2FuIG9ubHkgaGVscCBpZiB0aGUgTEFOIGludGVyZmFjZXMgd2lsbCBi ZSBpLmUuIGJyaWRnZWQuDQoNClRvIG15IGV4cGVyaWVuY2UsIHRoZSB0ZXRoZXJpbmcgZnVuY3Rp b24gaXMgdXN1YWxseSBib3VuZCB0byBvbmUgTEFOIGludGVyZmFjZSAoVVNCLCBXTEFOLCAuLi4p DQphbmQgdGhlIGhvbWUgQ1BFcyBhcmUgdXN1YWxseSBicmlkZ2luZyB3aXJlZCAmIHdpcmVsZXNz IExBTiBpbnRlcmZhY2VzLg0KDQo+IERhdmlkDQoNCkNoZWVycywNCkFsZXMNCg== From david.binet@orange.com Thu Feb 21 06: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 85CF621F8DC7 for ; Thu, 21 Feb 2013 06:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcRY-OeFAgjY for ; Thu, 21 Feb 2013 06:07:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AD37921F8DC3 for ; Thu, 21 Feb 2013 06:07:50 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BFF573B463C; Thu, 21 Feb 2013 15:07:49 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9F46323805C; Thu, 21 Feb 2013 15:07:49 +0100 (CET) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 21 Feb 2013 15:07:49 +0100 From: To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= , "v6ops@ietf.org" Date: Thu, 21 Feb 2013 15:07:48 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt Thread-Index: Ac4PwSJqFU2PkHSmQi6Wg6jFZboJMwAXBckgAAI7q7AABR/EsA== Message-ID: <20497_1361455669_51262A35_20497_112_1_1B2E7539FECD9048B261B791B1B24A7C49B6CC645D@PUEXCB1A.nanterre.francetelecom.fr> References: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> <21515_1361443375_5125FA2F_21515_1492_2_1B2E7539FECD9048B261B791B1B24A7C49B6CC62BF@PUEXCB1A.nanterre.francetelecom.fr> <1808340F7EC362469DDFFB112B37E2FCC6CFB3C12E@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFB3C12E@SRVHKE02.rdm.cz> 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-2" 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.2.19.124517 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.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, 21 Feb 2013 14:07:52 -0000 Hi Ales, Some comments below=20 Cheers David > > Hi all, > >=20 > > This document proposes some means to enable some prefix=20 > sharing when=20 > > PD is not enabled or possible but I do not clearly=20 > understand how to=20 > > "consider" the various scenarios. >=20 > Scenarios shall be understood as options, so you can pick the=20 > one that fits the most to your use-case. Actually I can have a use case in mind and vendors may have other use cases= . At the end they may provide some devices compliant with RFCxxx but that w= ill not answer my needs.=20 >=20 > > For example, we will have some smartphones, some CPEs and=20 > other type=20 > > of devices that may require such /64 prefix sharing=20=20 > capabilities and=20 > > do we have to consider that these different devices should=20 > support one given scenario. >=20 > If your use-case requires stable GUA address on the 3GPP link=20 > to not to affect any running services you might go for=20 > scenario 3, for a tethering box scenario 1 & 2 could be more=20 > appropriate.=20 I would prefer to get a solution that answer all kinds of requirements, inc= luding global connectivity for all devices that get their IP connectivity t= hanks to mobile networks, than some specific solutions for sub-not so much = defined use cases. I have the feeling that we create some scenarios because= of some specific implementation in some devices. I do no think we should c= are so much about specific devices characteristics.=20 =20 >=20 > > I think it would be more efficient and more simple to only consider=20 > > one scenario (for example the second one) to simplify relationships=20 > > and requirements towards UE vendors as well as UEs behaviors=20 > > considering that such capability should be a temporary solution. >=20 > What's the issue with multiple options available to them, so=20 > they can pick and choose? Multiple options in one reference document leads to some variety in impleme= ntations and some possible issues for service delivery. As far as this docu= ment details a temporary solution before PD is possible/enabled, I think it= should be as simple as possible.=20 >=20 > > If several LAN interfaces are enabled on the UE, could we consider=20 > > that some different scenarios could be retained by these=20 > different LAN=20 > > interfaces ? For example, if there is some Wi-Fi LAN and some=20 > > bluetooth LAN, is there any requirement about the IPv6=20 > address to be configured or not on these various LAN interfaces. >=20 > If several LAN interfaces are required to be numbered than=20 > DHCP-PD shall be used. In such a case this draft can only=20 > help if the LAN interfaces will be i.e. bridged. >=20 > To my experience, the tethering function is usually bound to=20 > one LAN interface (USB, WLAN, ...) and the home CPEs are=20 > usually bridging wired & wireless LAN interfaces. It could be useful to make it clear in the document to avoid any possible m= isunderstanding and configuration issues.=20 >=20 > > David >=20 > Cheers, > Ales >=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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bill.jouris@insidethestack.com Thu Feb 21 06:25: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 215A521F8D0D for ; Thu, 21 Feb 2013 06:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks+yjdg-bsid for ; Thu, 21 Feb 2013 06:25:27 -0800 (PST) Received: from nm9.access.bullet.mail.sp2.yahoo.com (nm9.access.bullet.mail.sp2.yahoo.com [98.139.44.136]) by ietfa.amsl.com (Postfix) with ESMTP id 4796F21F865D for ; Thu, 21 Feb 2013 06:25:27 -0800 (PST) Received: from [98.139.44.100] by nm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 21 Feb 2013 14:25:27 -0000 Received: from [98.139.44.65] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 21 Feb 2013 14:25:26 -0000 Received: from [127.0.0.1] by omp1002.access.mail.sp2.yahoo.com with NNFMP; 21 Feb 2013 14:25:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 137376.66033.bm@omp1002.access.mail.sp2.yahoo.com Received: (qmail 6241 invoked by uid 60001); 21 Feb 2013 14:25:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361456725; bh=QrA0ZLAizEacmGtJ9iPDgaaRPptoRgUBf+Co+tNDxvk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FP+3AAMPk6aYD4oR521A+b/SfQ2lW1VReRGLCbpn7qWA86NcxAcODDGKBIyVGYH+/ihioPIiBOys/9mu0WNjtzXDWCg6VjGYPVPpC/kFpc6MjJEQB1fegEeHSBGX8qAVQzVulWhRhgxhqtATXj+z0kmYPZKuuzTlJCkih3xhtJk= X-YMail-OSG: ZeBocYEVM1m2etOrvzc7zsg8ssSzNFv_3GcaXekxovAT979 06oaMVjK8eYxLnmgmNr.Co3ENILY1YbuVxIe3SKcSp7fut9u3uTEpK4kwAyE GscbBI5Rxq6sn1IjoRnnVZOMCpcoTEcDr5a_Y.mvuXZrOC4VLYi_WkFDz.8t uKAv35RJLraETlXF2nILw.psk.a1aUXminELArgyAFabDSpzxWWQpVSBofx8 t4ttgQxCz75b.9BUHn4LjdKxAh4ZXRtI1DC.LUM_Ha3N0UILNfu2vyx6kweS IukO6xDbwkTqWrTg9PNpbAGdDzL07AZM8Rb7JvAXGXVY_Y8AWf2u6CfamKQP UKWcowXKraB_Binia.4iHA5D6zli26APOYHhECBYpbzQy3qxqWw09KFBUSSL g9xinmokEmZMiS5Seyvh75lXj0ACJi0WRFtbSChbB1MWPSFNNSkVWWJWcw_S qE0ZsIEigu4Jbptr7KQsSG9V0fJaGxdh5kHuxABM.h45BqIK01cZtzB.L1wI xttG1t6q0peNTVcGVmbOz_22GdoGzX3HR3N4qMGhGshIBnHE4DyjZpOKeIa1 W8.ALEs4dGZLNLnQIvsj1G_9utf4FSLM- Received: from [50.148.178.232] by web2803.biz.mail.ne1.yahoo.com via HTTP; Thu, 21 Feb 2013 06:25:24 PST X-Rocket-MIMEInfo: 001.001, VGhhdCBiZWluZyB0aGUgY2FzZSwgd291bGRuJ3Qgd2UgYmUgc3RlcHBpbmcgYXdheSBmcm9tIHRoZSB3aG9sZSBpZGVhIG9mIGhhdmluZyBJUHY2IGFkZHJlc3NlcyByZWxhdGVkIHRvIFZJTiBudW1iZXJzP8KgIExlYXZlIGl0IHRvIHRoZSBhdXRvIGluZHVzdHJ5IHRvIGZpZ3VyZSBvdXQgaG93IHRoZXkgd2FudCB0byBkZWFsIHdpdGggdGhlIHN1YmplY3Q_DQoNCg0KQmlsbCBKb3VyaXMNCkluc2lkZSBQcm9kdWN0cywgSW5jLg0Kd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQ0KODMxLTY1OS04MzYwDQo5MjUtODUBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.134.513 Message-ID: <1361456724.31374.YahooMailClassic@web2803.biz.mail.ne1.yahoo.com> Date: Thu, 21 Feb 2013 06:25:24 -0800 (PST) From: Bill Jouris To: v6ops@ietf.org, joel jaeggli In-Reply-To: <5125CB24.1090104@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-868201502-1361456724=:31374" Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 14:25:28 -0000 ---1551098171-868201502-1361456724=:31374 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable That being the case, wouldn't we be stepping away from the whole idea of ha= ving IPv6 addresses related to VIN numbers?=A0 Leave it to the auto industr= y to figure out how they want to deal with the subject? Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Wed, 2/20/13, joel jaeggli wrote: From: joel jaeggli Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-a= sn To: "Bill Jouris" , v6ops@ietf.org Date: Wednesday, February 20, 2013, 11:22 PM On 2/20/13 2:20 PM, Bill Jouris wrote: > Owen, >=20 > So what you seem to be saying is: If manufacturers want to use a specific= part of their company allocation of addresses to give addresses to the car= s that they make based on VIN numbers, that is up to them.=A0 But IETF shou= ld not mandate allocating part of the overall spectrum of addresses to them= . >=20 The assignment of global unicast v6 addresses to Registries, LIRs, service = providers and direct assignments is done elsewhere. We have examples of aircraft and other large structures such as airports/tu= nnels and buildings receiving prefixes from their manufacturers which had o= riginally been obtained from RIRs. > If so, perhaps we should at least suggest to the SAE (Society of Automoti= ve Engineers), which makes standards for that industry, that they look at w= hether it makes sense for all of the companies to take a uniform approach t= o how they do that. >=20 > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) >=20 >=20 >=A0 =A0=A0=A0> On Feb 19, 2013, at 5:09 PM, Owen DeLong =A0 =A0=A0=A0> wrote: >=20 >=20 >=A0 =A0=A0=A0I do not support allocating globally unique prefixes for thin= gs >=A0 =A0=A0=A0that are not networks. >=20 >=A0 =A0=A0=A0Perhaps that will better explain my position. >=20 >=A0 =A0=A0=A0I think that overloading the IPv6 prefix space with semantics= for >=A0 =A0=A0=A0arbitrary collections of things is a really bad idea that has >=A0 =A0=A0=A0tremendous potential to consume vast amounts of addresses whi= le >=A0 =A0=A0=A0yielding no network benefit in return. >=20 >=A0 =A0=A0=A0Will it exhaust the IPv6 space immediately, probably not. Cou= ld we >=A0 =A0=A0=A0easily exhaust the ASN space if we start promoting the idea o= f >=A0 =A0=A0=A0claiming ASNs to support this? Yeah, we could probably burn 4 >=A0 =A0=A0=A0billion ASNs that way without too much trouble. >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops ---1551098171-868201502-1361456724=:31374 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That being the case, wouldn't we be stepping = away from the whole idea of having IPv6 addresses related to VIN numbers?&n= bsp; Leave it to the auto industry to figure out how they want to deal with= the subject?


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


--- On Wed, 2/20/13, joel jaeggli= <joelja@bogus.com> wrote:
From: joel jaeggli <joelja@bogus.com>
Subject: Re: [v6ops] Commen= ts to draft-mlevy-v6ops-auto-v6-allocation-per-asn
To: "Bill Jouris" <= ;bill.jouris@insidethestack.com>, v6ops@ietf.org
Date: Wednesday, Feb= ruary 20, 2013, 11:22 PM

On 2/20/13 2:20 PM= , Bill Jouris wrote:
> Owen,
>
> So what you seem to be saying= is: If manufacturers want to use a specific part of their company allocati= on of addresses to give addresses to the cars that they make based on VIN n= umbers, that is up to them.  But IETF should not mandate allocating pa= rt of the overall spectrum of addresses to them.
>
The assignment= of global unicast v6 addresses to Registries, LIRs, service providers and = direct assignments is done elsewhere.

We have examples of aircraft a= nd other large structures such as airports/tunnels and buildings receiving = prefixes from their manufacturers which had originally been obtained from R= IRs.
> If so, perhaps we should at least suggest to the SAE (Society = of Automotive Engineers), which makes standards for that industry, that the= y look at whether it makes sense for all of the companies to take a uniform= approach to how they do that.
>
> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com
> 831-659-8360<= br>> 925-855-9512 (direct)
>
>
>    &= nbsp;> On Feb 19, 2013, at 5:09 PM, Owen DeLong <owen@delong.com=
>     </mc/compose?to=3Dowen@delong.= com>> wrote:
>
>
>     I = do not support allocating globally unique prefixes for things
> =    that are not networks.
>
>   &nbs= p; Perhaps that will better explain my position.
>
> = ;    I think that overloading the IPv6 prefix space with sem= antics for
>     arbitrary collections of things = is a really bad idea that has
>     tremendous po= tential to consume vast amounts of addresses while
>     = ;yielding no network benefit in return.
>
>    =  Will it exhaust the IPv6 space immediately, probably not. Could we>     easily exhaust the ASN space if we start prom= oting the idea of
>     claiming ASNs to support = this? Yeah, we could probably burn 4
>     billio= n ASNs that way without too much trouble.
>
>
>
>= ;
> _______________________________________________
> v6ops ma= iling list
> v6ops@ietf.org
> https://www.ietf.org/mailma= n/listinfo/v6ops

---1551098171-868201502-1361456724=:31374-- From ales.vizdal@t-mobile.cz Thu Feb 21 07:28: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 1F6A821F8233 for ; Thu, 21 Feb 2013 07:28:25 -0800 (PST) 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.151, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwtaEONtkIL9 for ; Thu, 21 Feb 2013 07:28:24 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9742021F8E90 for ; Thu, 21 Feb 2013 07:28:22 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 795C328583B; Thu, 21 Feb 2013 16:28:06 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 21 Feb 2013 16:28:06 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "david.binet@orange.com" , "v6ops@ietf.org" Date: Thu, 21 Feb 2013 16:28:08 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt Thread-Index: Ac4PwSJqFU2PkHSmQi6Wg6jFZboJMwAXBckgAAI7q7AABR/EsAACJBuQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFB3C217@SRVHKE02.rdm.cz> References: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> <21515_1361443375_5125FA2F_21515_1492_2_1B2E7539FECD9048B261B791B1B24A7C49B6CC62BF@PUEXCB1A.nanterre.francetelecom.fr> <1808340F7EC362469DDFFB112B37E2FCC6CFB3C12E@SRVHKE02.rdm.cz> <20497_1361455669_51262A35_20497_112_1_1B2E7539FECD9048B261B791B1B24A7C49B6CC645D@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: <20497_1361455669_51262A35_20497_112_1_1B2E7539FECD9048B261B791B1B24A7C49B6CC645D@PUEXCB1A.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.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, 21 Feb 2013 15:28:25 -0000 Hi David, thanks for your feedback and please see below. > -----Original Message----- > From: david.binet@orange.com [mailto:david.binet@orange.com] > Sent: Thursday, February 21, 2013 3:08 PM > To: V=EDzdal Ale=B9; v6ops@ietf.org > Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.txt >=20 > Hi Ales, >=20 > Some comments below >=20 > Cheers > David > > > Scenarios shall be understood as options, so you can pick the > > one that fits the most to your use-case. > > Actually I can have a use case in mind and vendors may have other use cas= es. At the > end they may provide some devices compliant with RFCxxx but that will not= answer my > needs. You still can point them to RFC section/chapter if you're after that. > I would prefer to get a solution that answer all kinds of requirements, i= ncluding global > connectivity for all devices that get their IP connectivity thanks to mob= ile networks, > than some specific solutions for sub-not so much defined use cases. I hav= e the feeling > that we create some scenarios because of some specific implementation in = some > devices. I do no think we should care so much about specific devices char= acteristics. I am not sure if this draft shall be perceived as 'a solution', to me it is= describing the way how to extend a prefix from one interface to another. A solution would need= to go bit further. > > What's the issue with multiple options available to them, so > > they can pick and choose? > > Multiple options in one reference document leads to some variety in imple= mentations > and some possible issues for service delivery. As far as this document de= tails a > temporary solution before PD is possible/enabled, I think it should be as= simple as > possible. OK, do you see any issue with any of the options specified in the document? If so, please point it out. =20 > > > If several LAN interfaces are enabled on the UE, could we consider > > > that some different scenarios could be retained by these > > different LAN > > > interfaces ? For example, if there is some Wi-Fi LAN and some > > > bluetooth LAN, is there any requirement about the IPv6 > > address to be configured or not on these various LAN interfaces. > > > > If several LAN interfaces are required to be numbered than > > DHCP-PD shall be used. In such a case this draft can only > > help if the LAN interfaces will be i.e. bridged. > > > > To my experience, the tethering function is usually bound to > > one LAN interface (USB, WLAN, ...) and the home CPEs are > > usually bridging wired & wireless LAN interfaces. > > It could be useful to make it clear in the document to avoid any possible > misunderstanding and configuration issues. =20 OK. > > > David > > > > Cheers, > > Ales Cheers, Ales From cb.list6@gmail.com Thu Feb 21 07:58: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 AB9EA21F876E for ; Thu, 21 Feb 2013 07:58:51 -0800 (PST) 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.021, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZmu0FwovXTE for ; Thu, 21 Feb 2013 07:58:50 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 66DB921F8E05 for ; Thu, 21 Feb 2013 07:58:48 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id z6so1655086yhz.16 for ; Thu, 21 Feb 2013 07:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=G/TgatODQ7/Dm7c1mr8c6I64Muyb8awKpq2YexrPZ1g=; b=HAA8XoMjaPnPRLjvF4R4vDkZC/jZG3/DlJAAbGU9U+bKLzIfwPNsSdUJNHFrKcV6xq jNi7nC7OLSqRdBWYmw23qz8/myj0fOzckTcbXeLjWcU+jRX38NWL6KNUCqrmfxUUeKCX 68EACWlSE3+nGPb2Mbl7/42S9GKQ64msNPqw0k8qTnTXy75V1htxyensSL/n4hYPu1hK nHNK5WqdAMbJ+FGqpIFLECoqD2LoF1YIrfesMmHBvv+zlsxvCCF49VKKZ7qfr6lMm+5w g6W+wLVnHpKqVWay+PvbQc6WwGf1jjS50RwVJvci+Z7JUDF4/0Wgq23sFptM5E3yjDpz ee6g== MIME-Version: 1.0 X-Received: by 10.236.84.52 with SMTP id r40mr44699949yhe.94.1361462327755; Thu, 21 Feb 2013 07:58:47 -0800 (PST) Received: by 10.236.172.233 with HTTP; Thu, 21 Feb 2013 07:58:47 -0800 (PST) In-Reply-To: <20497_1361455669_51262A35_20497_112_1_1B2E7539FECD9048B261B791B1B24A7C49B6CC645D@PUEXCB1A.nanterre.francetelecom.fr> References: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> <21515_1361443375_5125FA2F_21515_1492_2_1B2E7539FECD9048B261B791B1B24A7C49B6CC62BF@PUEXCB1A.nanterre.francetelecom.fr> <1808340F7EC362469DDFFB112B37E2FCC6CFB3C12E@SRVHKE02.rdm.cz> <20497_1361455669_51262A35_20497_112_1_1B2E7539FECD9048B261B791B1B24A7C49B6CC645D@PUEXCB1A.nanterre.francetelecom.fr> Date: Thu, 21 Feb 2013 07:58:47 -0800 Message-ID: From: Cameron Byrne To: david.binet@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.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, 21 Feb 2013 15:58:53 -0000 David, I believe i understand your concerns, but the whole idea here is that 64share is a well known set of hacks that are needed until DHCP-PD is available in 3GPP networks. The document is only informational. On Thu, Feb 21, 2013 at 6:07 AM, wrote: > Hi Ales, > > Some comments below > > Cheers > David > >> > Hi all, >> > >> > This document proposes some means to enable some prefix >> sharing when >> > PD is not enabled or possible but I do not clearly >> understand how to >> > "consider" the various scenarios. >> >> Scenarios shall be understood as options, so you can pick the >> one that fits the most to your use-case. > Actually I can have a use case in mind and vendors may have other use cas= es. At the end they may provide some devices compliant with RFCxxx but that= will not answer my needs. >> As an individual submission i only cared about use-case #3, since it best fits my primary needs and we have running open source code. As a working group document, we included more scenarios to capture other needs as well. >> > For example, we will have some smartphones, some CPEs and >> other type >> > of devices that may require such /64 prefix sharing >> capabilities and >> > do we have to consider that these different devices should >> support one given scenario. >> >> If your use-case requires stable GUA address on the 3GPP link >> to not to affect any running services you might go for >> scenario 3, for a tethering box scenario 1 & 2 could be more >> appropriate. > I would prefer to get a solution that answer all kinds of requirements, i= ncluding global connectivity for all devices that get their IP connectivity= thanks to mobile networks, than some specific solutions for sub-not so muc= h defined use cases. I have the feeling that we create some scenarios becau= se of some specific implementation in some devices. I do no think we should= care so much about specific devices characteristics. > This is not a standards creation document. It is also not a best practice. It is simply an informational document on what can be achieved. With this information on-hand, we believe 3GPP network operators can deploy more IPv6 quicker. >> >> > I think it would be more efficient and more simple to only consider >> > one scenario (for example the second one) to simplify relationships >> > and requirements towards UE vendors as well as UEs behaviors >> > considering that such capability should be a temporary solution. >> While the document is not a BCP, it does declare that the best solution is DHCP-PD. If you cannot do DHCP-PD, then there are 3 scenarios with various features and trade-offs that the WG has vetted as viable. The real goal here is to spur IPv6 deployment by removing one more roadblock. These 3 scenarios are seen as highly achievable with existing frameworks or already achieved (scenario #3). CB >> What's the issue with multiple options available to them, so >> they can pick and choose? > Multiple options in one reference document leads to some variety in imple= mentations and some possible issues for service delivery. As far as this do= cument details a temporary solution before PD is possible/enabled, I think = it should be as simple as possible. > >> >> > If several LAN interfaces are enabled on the UE, could we consider >> > that some different scenarios could be retained by these >> different LAN >> > interfaces ? For example, if there is some Wi-Fi LAN and some >> > bluetooth LAN, is there any requirement about the IPv6 >> address to be configured or not on these various LAN interfaces. >> >> If several LAN interfaces are required to be numbered than >> DHCP-PD shall be used. In such a case this draft can only >> help if the LAN interfaces will be i.e. bridged. >> >> To my experience, the tethering function is usually bound to >> one LAN interface (USB, WLAN, ...) and the home CPEs are >> usually bridging wired & wireless LAN interfaces. > It could be useful to make it clear in the document to avoid any possible= misunderstanding and configuration issues. > >> >> > David >> >> Cheers, >> Ales >> > _________________________________________________________________________= ________________________________________________ > > 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, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. > > 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Thu Feb 21 08:22: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 3F05221F8EFD for ; Thu, 21 Feb 2013 08:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg7Q5tnfYpVq for ; Thu, 21 Feb 2013 08:22:43 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCE521F8EE6 for ; Thu, 21 Feb 2013 08:22:42 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1LGJqB6052681 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 16:19:53 GMT (envelope-from nick@inex.ie) Message-ID: <512649CC.1080108@inex.ie> Date: Thu, 21 Feb 2013 16:22:36 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bill Jouris References: <1361456724.31374.YahooMailClassic@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1361456724.31374.YahooMailClassic@web2803.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 16:22:44 -0000 On 21/02/2013 14:25, Bill Jouris wrote: > That being the case, wouldn't we be stepping away from the whole idea of > having IPv6 addresses related to VIN numbers? Leave it to the auto > industry to figure out how they want to deal with the subject? I don't think the IETF has any competence to deal with VINs, has it? If the car-makers want to register an ipv6 prefix for whatever reason from their RIR and have a 1:1 mapping between VINs and ipv6 addresses, then that is entirely their concern but I don't see why the IETF should take any part in this. Nick > > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) > > > --- On *Wed, 2/20/13, joel jaeggli //* wrote: > > > From: joel jaeggli > Subject: Re: [v6ops] Comments to > draft-mlevy-v6ops-auto-v6-allocation-per-asn > To: "Bill Jouris" , v6ops@ietf.org > Date: Wednesday, February 20, 2013, 11:22 PM > > On 2/20/13 2:20 PM, Bill Jouris wrote: > > Owen, > > > > So what you seem to be saying is: If manufacturers want to use a > specific part of their company allocation of addresses to give > addresses to the cars that they make based on VIN numbers, that is up > to them. But IETF should not mandate allocating part of the overall > spectrum of addresses to them. > > > The assignment of global unicast v6 addresses to Registries, LIRs, > service providers and direct assignments is done elsewhere. > > We have examples of aircraft and other large structures such as > airports/tunnels and buildings receiving prefixes from their > manufacturers which had originally been obtained from RIRs. > > If so, perhaps we should at least suggest to the SAE (Society of > Automotive Engineers), which makes standards for that industry, that > they look at whether it makes sense for all of the companies to take a > uniform approach to how they do that. > > > > Bill Jouris > > Inside Products, Inc. > > www.insidethestack.com > > 831-659-8360 > > 925-855-9512 (direct) > > > > > > > On Feb 19, 2013, at 5:09 PM, Owen DeLong > > >> wrote: > > > > > > I do not support allocating globally unique prefixes for things > > that are not networks. > > > > Perhaps that will better explain my position. > > > > I think that overloading the IPv6 prefix space with semantics for > > arbitrary collections of things is a really bad idea that has > > tremendous potential to consume vast amounts of addresses while > > yielding no network benefit in return. > > > > Will it exhaust the IPv6 space immediately, probably not. Could we > > easily exhaust the ASN space if we start promoting the idea of > > claiming ASNs to support this? Yeah, we could probably burn 4 > > billion ASNs that way without too much trouble. > > > > > > > > > > _______________________________________________ > > 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 > -- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie From bill.jouris@insidethestack.com Thu Feb 21 08:45: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 65B0221F8E74 for ; Thu, 21 Feb 2013 08:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKA6bzrJgGjg for ; Thu, 21 Feb 2013 08:45:45 -0800 (PST) Received: from nm25.access.bullet.mail.mud.yahoo.com (nm25.access.bullet.mail.mud.yahoo.com [66.94.237.90]) by ietfa.amsl.com (Postfix) with ESMTP id 5319D21F865D for ; Thu, 21 Feb 2013 08:45:45 -0800 (PST) Received: from [66.94.237.200] by nm25.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 16:45:44 -0000 Received: from [66.94.237.108] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 16:45:44 -0000 Received: from [127.0.0.1] by omp1013.access.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 16:45:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 751621.80952.bm@omp1013.access.mail.mud.yahoo.com Received: (qmail 41013 invoked by uid 60001); 21 Feb 2013 16:45:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361465144; bh=7YhGJQVcrLF0lg86jq/hy3k+nRKcMlMyL7U8uKDJFac=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MvnNIYRUuDcqI1w4A8zQvIYN2GWBCTHBdIzdLJZkzBlXrXoasRunszm6OUg3ONq3GYe75VAwySAb4eyK88ywMR2eVxarE8az2MXJLGJbD+2380fm9k3N0uzoow6gHBwUHRkoVQFXZjrPdmpMiEGJTYS7It45YR/SoFW5zJUu+ww= X-YMail-OSG: _czGtnEVM1lGiwsncqmCqc7eLDnNL13WoozhLjMHu_KtMEe 2wSq8KYYHd60S5D9OIY_chMW9XnfXcG.TO0YeCQChFjkgSpZgvwLcPH2yYlL G6KiKAilcuosJ4ZR4Jbe.rmeqMdxea8KOjWP2muhDBm2CyMGoZsANw2PP3aY 6B6fmNr3I3Oy_aR3qKSZmrr75APr_JRYy.rgkpnvNXO2Ke1kBQFZlttN.9iQ 2zH_SJA21v6FxLc4T0DfU8AFXCtlSi8G8mKHzh5vpWRMaG6RSN_JiWT6qRk2 HWOY_aJ0rTD8B14KOKi8XhHvftpmzK3JK430w1_CbRmpp0LHYs8VbdvOh4DD _fluXJ87Jd7FbqGOGWna12uZKCoktNVByuRzgLgnwMIlpgwGNCpbVXmYukVK J4HzF52eMII0VOUQwFKz4vckt9WSP1U9ADTsPMNzTdkoFaPT6lb_px9l4yIZ RHkqOG.tVj8aohmEqHnu1xE0vQk9JtXvSrFy6WFKnV0FYwEm_JZDd3ckVd8t SJfPRZUKjSA84JvfX6Xy8Slw_x426JNGFV2xIq6HZrurVxDtvGcYht5W1VrR LuafoYAlexFvFzNjxYUPZ4q3J0tsUZIs- Received: from [50.148.178.232] by web2806.biz.mail.ne1.yahoo.com via HTTP; Thu, 21 Feb 2013 08:45:43 PST X-Rocket-MIMEInfo: 001.001, RmFpciBlbm91Z2guwqAgQnV0IGluIHRoYXQgY2FzZSwgdGhlIHdob2xlIGRyYWZ0IHdvdWxkIHNlZW0gdG8gYmUgb3V0c2lkZSBvdXIgY29tcGV0ZW5jZS7CoCANCg0KQWxsIEknbSBzYXlpbmcgaXMgdGhhdCwgaWYgdGhlIElFVEYgaXMgZ29pbmcgdG8gc2F5IGFueXRoaW5nIGFib3V0IHJlbGF0aW5nIElQdjYgYWRkcmVzc2VzIHRvIFZJTiBudW1iZXJzLCB0aGUgU0FFIGZvbGtzIG91Z2h0IHRvIGJlIGludm9sdmVkIGFzIHdlbGwuDQoNCkJpbGwgDQoNCi0tLSBPbiBUaHUsIDIvMjEvMTMsIE5pY2sgSGlsbGkBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.134.513 Message-ID: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> Date: Thu, 21 Feb 2013 08:45:43 -0800 (PST) From: Bill Jouris To: Nick Hilliard In-Reply-To: <512649CC.1080108@inex.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-925425516-1361465143=:30805" Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 16:45:46 -0000 --1510626085-925425516-1361465143=:30805 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fair enough.=A0 But in that case, the whole draft would seem to be outside = our competence.=A0=20 All I'm saying is that, if the IETF is going to say anything about relating= IPv6 addresses to VIN numbers, the SAE folks ought to be involved as well. Bill=20 --- On Thu, 2/21/13, Nick Hilliard wrote: From: Nick Hilliard Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-a= sn To: "Bill Jouris" Cc: v6ops@ietf.org, "joel jaeggli" Date: Thursday, February 21, 2013, 8:22 AM On 21/02/2013 14:25, Bill Jouris wrote: > That being the case, wouldn't we be stepping away from the whole idea of > having IPv6 addresses related to VIN numbers?=A0 Leave it to the auto > industry to figure out how they want to deal with the subject? I don't think the IETF has any competence to deal with VINs, has it?=A0 If the car-makers want to register an ipv6 prefix for whatever reason from their RIR and have a 1:1 mapping between VINs and ipv6 addresses, then that is entirely their concern but I don't see why the IETF should take any part in this. Nick >=20 > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) >=20 >=20 > --- On *Wed, 2/20/13, joel jaeggli //* wrote: >=20 >=20 >=A0 =A0=A0=A0From: joel jaeggli >=A0 =A0=A0=A0Subject: Re: [v6ops] Comments to >=A0 =A0=A0=A0draft-mlevy-v6ops-auto-v6-allocation-per-asn >=A0 =A0=A0=A0To: "Bill Jouris" , v6ops@iet= f.org >=A0 =A0=A0=A0Date: Wednesday, February 20, 2013, 11:22 PM >=20 >=A0 =A0=A0=A0On 2/20/13 2:20 PM, Bill Jouris wrote: >=A0 =A0=A0=A0> Owen, >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> So what you seem to be saying is: If manufacturers want to = use a >=A0 =A0=A0=A0specific part of their company allocation of addresses to giv= e >=A0 =A0=A0=A0addresses to the cars that they make based on VIN numbers, th= at is up >=A0 =A0=A0=A0to them.=A0 But IETF should not mandate allocating part of th= e overall >=A0 =A0=A0=A0spectrum of addresses to them. >=A0 =A0=A0=A0> >=A0 =A0=A0=A0The assignment of global unicast v6 addresses to Registries, = LIRs, >=A0 =A0=A0=A0service providers and direct assignments is done elsewhere. >=20 >=A0 =A0=A0=A0We have examples of aircraft and other large structures such = as >=A0 =A0=A0=A0airports/tunnels and buildings receiving prefixes from their >=A0 =A0=A0=A0manufacturers which had originally been obtained from RIRs. >=A0 =A0=A0=A0> If so, perhaps we should at least suggest to the SAE (Socie= ty of >=A0 =A0=A0=A0Automotive Engineers), which makes standards for that industr= y, that >=A0 =A0=A0=A0they look at whether it makes sense for all of the companies = to take a >=A0 =A0=A0=A0uniform approach to how they do that. >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> Bill Jouris >=A0 =A0=A0=A0> Inside Products, Inc. >=A0 =A0=A0=A0> www.insidethestack.com >=A0 =A0=A0=A0> 831-659-8360 >=A0 =A0=A0=A0> 925-855-9512 (direct) >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> >=A0 =A0=A0=A0>=A0 =A0=A0=A0> On Feb 19, 2013, at 5:09 PM, Owen DeLong =A0 =A0=A0=A0 >=A0 =A0=A0=A0>=A0 =A0=A0=A0=A0 =A0=A0=A0>> wrote: >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> >=A0 =A0=A0=A0>=A0 =A0=A0=A0I do not support allocating globally unique pre= fixes for things >=A0 =A0=A0=A0>=A0 =A0=A0=A0that are not networks. >=A0 =A0=A0=A0> >=A0 =A0=A0=A0>=A0 =A0=A0=A0Perhaps that will better explain my position. >=A0 =A0=A0=A0> >=A0 =A0=A0=A0>=A0 =A0=A0=A0I think that overloading the IPv6 prefix space = with semantics for >=A0 =A0=A0=A0>=A0 =A0=A0=A0arbitrary collections of things is a really bad= idea that has >=A0 =A0=A0=A0>=A0 =A0=A0=A0tremendous potential to consume vast amounts of= addresses while >=A0 =A0=A0=A0>=A0 =A0=A0=A0yielding no network benefit in return. >=A0 =A0=A0=A0> >=A0 =A0=A0=A0>=A0 =A0=A0=A0Will it exhaust the IPv6 space immediately, pro= bably not. Could we >=A0 =A0=A0=A0>=A0 =A0=A0=A0easily exhaust the ASN space if we start promot= ing the idea of >=A0 =A0=A0=A0>=A0 =A0=A0=A0claiming ASNs to support this? Yeah, we could p= robably burn 4 >=A0 =A0=A0=A0>=A0 =A0=A0=A0billion ASNs that way without too much trouble. >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> >=A0 =A0=A0=A0> _______________________________________________ >=A0 =A0=A0=A0> v6ops mailing list >=A0 =A0=A0=A0> v6ops@ietf.org >=A0 =A0=A0=A0> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --=20 Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 3 Westland Square=A0 =A0 | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland=A0 =A0 | Exchange Association=A0 =A0 | Email: nick@inex.i= e --1510626085-925425516-1361465143=:30805 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fair enough.  But in that case, the whol= e draft would seem to be outside our competence. 

All I'm sayi= ng is that, if the IETF is going to say anything about relating IPv6 addres= ses to VIN numbers, the SAE folks ought to be involved as well.

Bill

--- On Thu, 2/21/13, Nick Hilliard &= lt;nick@inex.ie> wrote:

From: Ni= ck Hilliard <nick@inex.ie>
Subject: Re: [v6ops] Comments to draft-= mlevy-v6ops-auto-v6-allocation-per-asn
To: "Bill Jouris" <bill.jouris= @insidethestack.com>
Cc: v6ops@ietf.org, "joel jaeggli" <joelja@bo= gus.com>
Date: Thursday, February 21, 2013, 8:22 AM

On 21/02/2013 14:25, Bill Jouris wrote:
> That being t= he case, wouldn't we be stepping away from the whole idea of
> having IPv6 ad= dresses related to VIN numbers?  Leave it to the auto
> industry= to figure out how they want to deal with the subject?

I don't think= the IETF has any competence to deal with VINs, has it?  If
the car= -makers want to register an ipv6 prefix for whatever reason from
their R= IR and have a 1:1 mapping between VINs and ipv6 addresses, then that
is = entirely their concern but I don't see why the IETF should take any partin this.

Nick

>
> Bill Jouris
> Inside Produ= cts, Inc.
> www.insidethestack.com
> 831-659-8360
> 925-8= 55-9512 (direct)
>
>
> --- On *Wed, 2/20/13, joel jaegg= li /<joelja@bogus.com>/* wrote:
>
>
>&= nbsp;    From: joel jaeggli <joelja@bogus.com>
>     Subject: Re: = [v6ops] Comments to
>     draft-mlevy-v6ops-auto-= v6-allocation-per-asn
>     To: "Bill Jouris" <= ;bill.jouris@insidethestack.com>,= v6ops@ietf.org
>     Date: Wednesday, Feb= ruary 20, 2013, 11:22 PM
>
>     On 2/20/1= 3 2:20 PM, Bill Jouris wrote:
>     > Owen,>     >
>     > So = what you seem to be saying is: If manufacturers want to use a
> =    specific part of their company allocation of addresses t= o give
>     addresses to the cars that they make = based on VIN numbers, that is up
>     to them.&n= bsp; But IETF should not mandate allocating part of the overall
>&nbs= p;    spectrum of addresses to them.
>   &nb= sp; >
>     The assignment of global unic= ast v6 addresses to Registries, LIRs,
>     servi= ce providers and direct assignments is done elsewhere.
>
>&nbs= p;    We have examples of aircraft and other large structure= s such as
>     airports/tunnels and buildings re= ceiving prefixes from their
>     manufacturers w= hich had originally been obtained from RIRs.
>    &nbs= p;> If so, perhaps we should at least suggest to the SAE (Society of
= >     Automotive Engineers), which makes standards for that industry, that
>     they loo= k at whether it makes sense for all of the companies to take a
> = ;    uniform approach to how they do that.
>  &nb= sp;  >
>     > Bill Jouris
>= ;     > Inside Products, Inc.
>   &n= bsp; > www.insidethestack.com
>     > = 831-659-8360
>     > 925-855-9512 (direct)
= >     >
>     >
&= gt;     >     > On Feb 19, 20= 13, at 5:09 PM, Owen DeLong <owen@delong.com
>  &nb= sp;  </mc/compose?to=3Dowen@delong.com>
>&nb= sp;    >     </mc/compose?to=3Do= wen@delong.com
>     </mc/compose?to=3Dowen@delong.com>>> wrote:
>     &g= t;
>     >
>     >= ;     I do not support allocating globally unique prefi= xes for things
>     >     = ;that are not networks.
>     >
>  =    >     Perhaps that will better exp= lain my position.
>     >
>   =   >     I think that overloading the IPv6 = prefix space with semantics for
>     >     arbitrary collections of things is a really bad idea tha= t has
>     >     tremendo= us potential to consume vast amounts of addresses while
>   = ;  >     yielding no network benefit in re= turn.
>     >
>     = >     Will it exhaust the IPv6 space immediately, pr= obably not. Could we
>     >    = ; easily exhaust the ASN space if we start promoting the idea of
&g= t;     >     claiming ASNs to su= pport this? Yeah, we could probably burn 4
>     = >     billion ASNs that way without too much trouble= .
>     >
>     >=
>     >
>     >
>     > ______________= _________________________________
>     > v6op= s mailing list
>     > v6ops@ietf.org &= lt;/mc/compose?to=3Dv6ops@ietf.org>
>    &nb= sp;> https://www.ietf.org/mailman/listinfo/v6ops
>
> >
> _______________________________________________
> v6op= s mailing list
> v6ops@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/v6ops
>


--
Network Ability Ltd. | = Chief Technical Officer | Tel: +353 1 6169698
3 Westland Square    | INEX - I= nternet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland    | E= xchange Association    | Email: nick@inex.ie
--1510626085-925425516-1361465143=:30805-- From owen@delong.com Thu Feb 21 08:55: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 A46F221F87B1 for ; Thu, 21 Feb 2013 08:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnBLNKWxCMNU for ; Thu, 21 Feb 2013 08:55:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91E21F8E62 for ; Thu, 21 Feb 2013 08:55:49 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1LGqfFh006192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Feb 2013 08:52:41 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1LGqfFh006192 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361465561; bh=KuQYpzoCXv6Y+b+YYtCgS4gPtjw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=gCNofJiVQpVLJV78GTVs0mRIrAALYyyb8TimL9Trslwah4KYOeyj2+ZolAwh7wvnI Ebu0RVYRfefhdKFPL3pcHORntd31aWhjtu3ARqFol+1R1A698Um2Ss4goBrN6ERJ6z CqL9axgW0ur8rcKSTEICZGzrw4ZmfJoZGObbuQRs= Content-Type: multipart/alternative; boundary="Apple-Mail=_1CC5FE37-63AF-45A5-9AD2-A37CA259D866" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> Date: Thu, 21 Feb 2013 08:52:40 -0800 Message-Id: <30C1F558-D6D6-4BFC-BBC7-6EEC5870BB2F@delong.com> References: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> To: Bill Jouris X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Feb 2013 08:52:41 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 16:55:56 -0000 --Apple-Mail=_1CC5FE37-63AF-45A5-9AD2-A37CA259D866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The draft doesn't say anything about VIN numbers. The draft provides a /48 for every ASN automatically by allocating a = /16 prefix to\ which the 32 bit ASN is appended. VINs entered the discussion when someone presented an example of how = this address space might be (mis?)used. Owen On Feb 21, 2013, at 8:45 AM, Bill Jouris = wrote: >=20 > Fair enough. But in that case, the whole draft would seem to be = outside our competence. =20 >=20 > All I'm saying is that, if the IETF is going to say anything about = relating IPv6 addresses to VIN numbers, the SAE folks ought to be = involved as well. >=20 > Bill=20 >=20 > --- On Thu, 2/21/13, Nick Hilliard wrote: >=20 > From: Nick Hilliard > Subject: Re: [v6ops] Comments to = draft-mlevy-v6ops-auto-v6-allocation-per-asn > To: "Bill Jouris" > Cc: v6ops@ietf.org, "joel jaeggli" > Date: Thursday, February 21, 2013, 8:22 AM >=20 > On 21/02/2013 14:25, Bill Jouris wrote: > > That being the case, wouldn't we be stepping away from the whole = idea of > > having IPv6 addresses related to VIN numbers? Leave it to the auto > > industry to figure out how they want to deal with the subject? >=20 > I don't think the IETF has any competence to deal with VINs, has it? = If > the car-makers want to register an ipv6 prefix for whatever reason = from > their RIR and have a 1:1 mapping between VINs and ipv6 addresses, then = that > is entirely their concern but I don't see why the IETF should take any = part > in this. >=20 > Nick >=20 > >=20 > > Bill Jouris > > Inside Products, Inc. > > www.insidethestack.com > > 831-659-8360 > > 925-855-9512 (direct) > >=20 > >=20 > > --- On *Wed, 2/20/13, joel jaeggli //* wrote: > >=20 > >=20 > > From: joel jaeggli > > Subject: Re: [v6ops] Comments to > > draft-mlevy-v6ops-auto-v6-allocation-per-asn > > To: "Bill Jouris" , = v6ops@ietf.org > > Date: Wednesday, February 20, 2013, 11:22 PM > >=20 > > On 2/20/13 2:20 PM, Bill Jouris wrote: > > > Owen, > > > > > > So what you seem to be saying is: If manufacturers want to use = a > > specific part of their company allocation of addresses to give > > addresses to the cars that they make based on VIN numbers, that = is up > > to them. But IETF should not mandate allocating part of the = overall > > spectrum of addresses to them. > > > > > The assignment of global unicast v6 addresses to Registries, = LIRs, > > service providers and direct assignments is done elsewhere. > >=20 > > We have examples of aircraft and other large structures such as > > airports/tunnels and buildings receiving prefixes from their > > manufacturers which had originally been obtained from RIRs. > > > If so, perhaps we should at least suggest to the SAE (Society = of > > Automotive Engineers), which makes standards for that industry, = that > > they look at whether it makes sense for all of the companies to = take a > > uniform approach to how they do that. > > > > > > Bill Jouris > > > Inside Products, Inc. > > > www.insidethestack.com > > > 831-659-8360 > > > 925-855-9512 (direct) > > > > > > > > > > On Feb 19, 2013, at 5:09 PM, Owen DeLong = > > > > > >> wrote: > > > > > > > > > I do not support allocating globally unique prefixes for = things > > > that are not networks. > > > > > > Perhaps that will better explain my position. > > > > > > I think that overloading the IPv6 prefix space with = semantics for > > > arbitrary collections of things is a really bad idea that = has > > > tremendous potential to consume vast amounts of addresses = while > > > yielding no network benefit in return. > > > > > > Will it exhaust the IPv6 space immediately, probably not. = Could we > > > easily exhaust the ASN space if we start promoting the = idea of > > > claiming ASNs to support this? Yeah, we could probably = burn 4 > > > billion ASNs that way without too much trouble. > > > > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 >=20 >=20 > --=20 > Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 > 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 > Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_1CC5FE37-63AF-45A5-9AD2-A37CA259D866 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The = draft doesn't say anything about VIN numbers.

The = draft provides a /48 for every ASN automatically by allocating a =  /16 prefix to\
which the 32 bit ASN is = appended.

VINs entered the discussion when = someone presented an example of how this
address space might = be (mis?)used.

Owen

On = Feb 21, 2013, at 8:45 AM, Bill Jouris <bill.jouris@insidethestack.= com> wrote:

Fair enough.  But in that = case, the whole draft would seem to be outside our competence.  =

All I'm saying is that, if the IETF is going to say anything = about relating IPv6 addresses to VIN numbers, the SAE folks ought to be = involved as well.

Bill

--- On = Thu, 2/21/13, Nick Hilliard <nick@inex.ie> = wrote:

From: Nick Hilliard <nick@inex.ie>
Subject: Re: = [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn
To: = "Bill Jouris" <bill.jouris@insidethestack.= com>
Cc: v6ops@ietf.org, = "joel jaeggli" <joelja@bogus.com>
Date: = Thursday, February 21, 2013, 8:22 AM

On = 21/02/2013 14:25, Bill Jouris wrote:
> That being the case, wouldn't we be stepping away from the whole idea of
> having IPv6 = addresses related to VIN numbers?  Leave it to the auto
> = industry to figure out how they want to deal with the subject?

I = don't think the IETF has any competence to deal with VINs, has it?  = If
the car-makers want to register an ipv6 prefix for whatever reason = from
their RIR and have a 1:1 mapping between VINs and ipv6 = addresses, then that
is entirely their concern but I don't see why = the IETF should take any part
in this.

Nick

> =
> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com
> = 831-659-8360
> 925-855-9512 (direct)
>
>
> --- = On *Wed, 2/20/13, joel jaeggli /<joelja@bogus.com>/* wrote:
>
>
>     From: = joel jaeggli <joelja@bogus.com>
>     Subject: Re: [v6ops] Comments = to
>  =    draft-mlevy-v6ops-auto-v6-allocation-per-asn
>&nbs= p;    To: "Bill Jouris" <bill= .jouris@insidethestack.com>, v6ops@ietf.org>     Date: Wednesday, February 20, 2013, 11:22 = PM
>
>     On 2/20/13 2:20 PM, Bill = Jouris wrote:
>     > Owen,
>  =    >
>     > So what you = seem to be saying is: If manufacturers want to use a
>  =    specific part of their company allocation of addresses = to give
>     addresses to the cars that they = make based on VIN numbers, that is up
>     to = them.  But IETF should not mandate allocating part of the = overall
>     spectrum of addresses to = them.
>     >
>  =    The assignment of global unicast v6 addresses to = Registries, LIRs,
>     service providers and = direct assignments is done elsewhere.
>
>  =    We have examples of aircraft and other large = structures such as
>     airports/tunnels and = buildings receiving prefixes from their
>  =    manufacturers which had originally been obtained from = RIRs.
>     > If so, perhaps we should at = least suggest to the SAE (Society of
>  =    Automotive Engineers), which makes standards for that industry, that
>     they = look at whether it makes sense for all of the companies to take = a
>     uniform approach to how they do = that.
>     >
>  =    > Bill Jouris
>     > = Inside Products, Inc.
>     > www.insidethestack.com
>&= nbsp;    > 831-659-8360
>  =    > 925-855-9512 (direct)
>  =    >
>  =    >
>     >  =    > On Feb 19, 2013, at 5:09 PM, Owen DeLong <owen@delong.com=
>     </mc/compose?to=3Dowen@delong.com= >
>     >     </mc/compose?to=3Dowen@delong.com=
>     </mc/compose?to=3Dowen@delong.com= >>> wrote:
>     >
>  =    >
>     >  =    I do not support allocating globally unique prefixes = for things
>     >  =    that are not networks.
>  =    >
>     >  =    Perhaps that will better explain my = position.
>     >
>  =    >     I think that overloading = the IPv6 prefix space with semantics for
>  =    >     arbitrary collections of things is a really bad idea = that has
>     >  =    tremendous potential to consume vast amounts of = addresses while
>     >  =    yielding no network benefit in return.
>  =    >
>     >  =    Will it exhaust the IPv6 space immediately, probably = not. Could we
>     >  =    easily exhaust the ASN space if we start promoting the = idea of
>     >  =    claiming ASNs to support this? Yeah, we could probably = burn 4
>     >  =    billion ASNs that way without too much = trouble.
>     >
>  =    >
>  =    >
>     >
>     > = _______________________________________________
>  =    > v6ops mailing list
>  =    > v6ops@ietf.org = </mc/compose?to=3Dv6ops@ietf.org&g= t;
>     > https://www.ietf.org/mailman/listinfo/v6ops
> =
>
>
> = _______________________________________________
> v6ops mailing = list
> v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops
> =


--
Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698
3 Westland Square    | INEX = - Internet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland  =   | Exchange Association    | Email: nick@inex.ie
_______________________________= ________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_1CC5FE37-63AF-45A5-9AD2-A37CA259D866-- From nick@inex.ie Thu Feb 21 09:00: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 32B9021F8916 for ; Thu, 21 Feb 2013 09:00:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oul2fayDwqD8 for ; Thu, 21 Feb 2013 08:59:59 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 50CD621F8501 for ; Thu, 21 Feb 2013 08:59:51 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1LGv3L2052928 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 16:57:03 GMT (envelope-from nick@inex.ie) Message-ID: <51265282.1040405@inex.ie> Date: Thu, 21 Feb 2013 16:59:46 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bill Jouris References: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 17:00:12 -0000 On 21/02/2013 16:45, Bill Jouris wrote: > Fair enough. But in that case, the whole draft would seem to be > outside our competence. > > All I'm saying is that, if the IETF is going to say anything about > relating IPv6 addresses to VIN numbers, the SAE folks ought to be > involved as well. Uh, I think Dino mentioned VINs as an example plucked out of thin air for demonstrating potential end-user applications (i.e. nothing to do with the ietf). Nick From farinacci@gmail.com Thu Feb 21 09:08: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 A296021F8DD3 for ; Thu, 21 Feb 2013 09:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYmNJ+bCG7cZ for ; Thu, 21 Feb 2013 09:08:23 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0965821F8A6C for ; Thu, 21 Feb 2013 09:08:23 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so4898638pad.41 for ; Thu, 21 Feb 2013 09:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=VvMtaYrhLtZLz46tTswuXSaoeoL8TyfqeyS7JIYRqOQ=; b=ty+Z0qmn58NM2nuRfz6XwZnVIZ9Bp/TFuKZSF8w9OK662c7Ke5VIheiMmlgsPdUbM5 +KEQ6EwQZ+3SFFGPjwCiAc0gxhcR4UUmv2BZ4SQr8zK2N+wm59J7N2kcM9Zl4knWs30x slIljJxl51JbS5JIJfl/enMtfVrXeAC7rhOgeOet04hGqWGdJliKMADquJTxFNoS/dIA U49jw9+/8uRPePV9q2qGp80JGIfcA0PVtLKa5YOSlZjhZb2dms2EcnqbCnf1+Ad2JhZ4 MrBaMu7ZBZiqkXbsSQl64wMRvGvzoIdmmxSxdxfgNgg3LN4U9iXnsZR6qa1J2wXryt9u Bm7w== X-Received: by 10.66.234.39 with SMTP id ub7mr9248699pac.152.1361466502854; Thu, 21 Feb 2013 09:08:22 -0800 (PST) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPS id vq9sm25903174pbc.36.2013.02.21.09.08.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 09:08:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <51265282.1040405@inex.ie> Date: Thu, 21 Feb 2013 09:08:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <37A0B1BC-ECD5-49A6-AE8D-5FC8F609E864@gmail.com> References: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> <51265282.1040405@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 17:08:23 -0000 > On 21/02/2013 16:45, Bill Jouris wrote: >> Fair enough. But in that case, the whole draft would seem to be >> outside our competence. >>=20 >> All I'm saying is that, if the IETF is going to say anything about >> relating IPv6 addresses to VIN numbers, the SAE folks ought to be >> involved as well. >=20 > Uh, I think Dino mentioned VINs as an example plucked out of thin air = for > demonstrating potential end-user applications (i.e. nothing to do with = the > ietf). >=20 > Nick It is a real user/customer requirement. IETF should not tell users how = to assign their addresses. Just allow part of the address space = available so they can do what they want. I would go one step further, that providers of a service should not = users how to assign their addresses. That is the whole point the user = community is begging for EIDs. Dino >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Thu Feb 21 09:33: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 8122A21F8EE8 for ; Thu, 21 Feb 2013 09:33:16 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxGDwPIe9CwU for ; Thu, 21 Feb 2013 09:33:16 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id B269921F8EC3 for ; Thu, 21 Feb 2013 09:33:15 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1LHURJE053149 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 17:30:28 GMT (envelope-from nick@inex.ie) Message-ID: <51265A57.1000709@inex.ie> Date: Thu, 21 Feb 2013 17:33:11 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dino Farinacci References: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> <51265282.1040405@inex.ie> <37A0B1BC-ECD5-49A6-AE8D-5FC8F609E864@gmail.com> In-Reply-To: <37A0B1BC-ECD5-49A6-AE8D-5FC8F609E864@gmail.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 17:33:16 -0000 On 21/02/2013 17:08, Dino Farinacci wrote: > It is a real user/customer requirement. IETF should not tell users how > to assign their addresses. Just allow part of the address space > available so they can do what they want. if the car makers want a new VIN bin, then they can have it. The only requirement for creating a new bin is a common agreement between them that their chosen range of integers or symbols means something to them. Whether or not this range is a subset of an ietf-assigned ipv6 subnet is completely irrelevant. >From the IETF's point of view, if the car makers come to them and ask them for a range of numbers for car VINs, my reaction would be "wut?" Nick From farinacci@gmail.com Thu Feb 21 09:59: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 DFE1C21F8ED1 for ; Thu, 21 Feb 2013 09:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIoGZY-1wVYx for ; Thu, 21 Feb 2013 09:59:36 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE2721F8EBC for ; Thu, 21 Feb 2013 09:59:29 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kl14so4896718pab.32 for ; Thu, 21 Feb 2013 09:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=mm+t7+1eayX7YamhR6tF4g+VHEHNpi56lpJ6t7a4CD8=; b=bfsjP2dz6wlcpUqlCF0FOYe6MZMxnrRgyam95I51ICvU7iCVIksqYr9Nx8v+C4zifr 8sSY8QWyG6sIR7HPiKGeJ/QA6RTiGPHDl/4i85rezDV3UlfugJK8D+9uQeZR8oVgdwrk V+BU+4o+vrEDRqx0lP8WjL3U75e1W2OqrHNR8C6IvHt2V4xNHP03+fELrlK+CxwaEpaR 57Y3YxlhZ78EwrsQJT3sjYFirXT5JMmwdmOnwzw8N0zEVD9584wbcfMl3s+1rRI47aC7 t4S+DTQ+bkpHUyUPMbodZjhOyfajjs8a4S3pheBEu5kd1kAaGynl3PUtSu6EUfafOEmT nAuw== X-Received: by 10.66.144.137 with SMTP id sm9mr9563672pab.118.1361469568777; Thu, 21 Feb 2013 09:59:28 -0800 (PST) Received: from [192.168.1.10] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id pn9sm19217301pbb.22.2013.02.21.09.59.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 09:59:28 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <51265A57.1000709@inex.ie> Date: Thu, 21 Feb 2013 09:59:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <86AF721F-EC74-46B2-B922-4222E4F599C9@gmail.com> References: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> <51265282.1040405@inex.ie> <37A0B1BC-ECD5-49A6-AE8D-5FC8F609E864@gmail.com> <51265A57.1000709@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 17:59:37 -0000 So let's get back on track: (1) I brought up VIN numbers because people are requesting for rather = opaque addresses. (2) I said that LISP EIDs are typically used as opaque addresses. (3) I said the draft-mlevy-v6ops-auto-v6-allocation-per-asn is a decent = encoding format for EIDs. Nothing more was said, implied, or suggested. Dino On Feb 21, 2013, at 9:33 AM, Nick Hilliard wrote: > On 21/02/2013 17:08, Dino Farinacci wrote: >> It is a real user/customer requirement. IETF should not tell users = how >> to assign their addresses. Just allow part of the address space >> available so they can do what they want. >=20 > if the car makers want a new VIN bin, then they can have it. The only > requirement for creating a new bin is a common agreement between them = that > their chosen range of integers or symbols means something to them. = Whether > or not this range is a subset of an ietf-assigned ipv6 subnet is = completely > irrelevant. >=20 > =46rom the IETF's point of view, if the car makers come to them and = ask them > for a range of numbers for car VINs, my reaction would be "wut?" >=20 > Nick >=20 From bill.jouris@insidethestack.com Thu Feb 21 10: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 E0CEC21F8F33 for ; Thu, 21 Feb 2013 10:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoRDCDxsLyOA for ; Thu, 21 Feb 2013 10:52:36 -0800 (PST) Received: from nm20.access.bullet.mail.mud.yahoo.com (nm20.access.bullet.mail.mud.yahoo.com [66.94.237.221]) by ietfa.amsl.com (Postfix) with ESMTP id F279021F8F20 for ; Thu, 21 Feb 2013 10:52:35 -0800 (PST) Received: from [66.94.237.194] by nm20.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 18:52:35 -0000 Received: from [66.94.237.97] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 18:52:35 -0000 Received: from [127.0.0.1] by omp1002.access.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 18:52:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 510836.57466.bm@omp1002.access.mail.mud.yahoo.com Received: (qmail 85179 invoked by uid 60001); 21 Feb 2013 18:52:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361472755; bh=PejQNc8qEIAa/tLetKevnbIdaoN5W1dTKR8RSlcgWtU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WwA464VJTJQ+dRhHUBdL2K9vhLQdCVIPlpQ+IWoQAKqF3kWWi0hC2gMEz7bkcj8Hb3oS8NhN75Hb3+eZBH5yiSttAoyp/5pBVd+FHgNnWNAz589Wl5tgQG9Pl2jUo7I8lFevCDkTrZ9F2xR5VjDWHx1ttTHKry/RAfbguaE8NuY= X-YMail-OSG: A8VUE_EVM1laF3a_5EbUPiZ1Rrft2nNnCppVCiRc2ZRDf_o YvnfZgHUCKdQtAZgW85OKfU99YwDY8H70c6JZ8ib9WRTeoKxShDyhC_wnOWb BMFfvOvyfYWlMBKulTtBgn2YwH7JXXr4SeBIlXCs2.7BuYkUOWzbjvC9Ju3E K9hn33XssGFOazAC6byNTI6S4NcTh1q6YYJMS1N9v3XNs8wIMpuMrGFtA4.O AFfYgieGd6.6YSoh3xcPptz2JTZmTsH6uB1USL0U_KieSqlkLmtjeBsOcSmh Ab9_hf6LddoQ3nUd.Qa_j_kL2YhbjNvPtRWmrDPuo0xRXtshgxF5W2NiJLeS VD_4tg1JiHQHJX7o9y9mk1BJVt8Mu.JsQnUnRB3U2cSeFRwWu79yASWrZmBi X1THrJ6Kt9wxFPFT44xYdg5TCLvAO_hSD1019Sw7wEFVtrZ7nLjDI7DDBNmH UfNCpCkhvoMMYdXdwal_IREVWyViHd3d.BYVcYoryDecP7DjPVzxO1vzh7I4 z_IzLakUeMyX_FWQGNlub Received: from [50.148.178.232] by web2806.biz.mail.ne1.yahoo.com via HTTP; Thu, 21 Feb 2013 10:52:34 PST X-Rocket-MIMEInfo: 001.001, SnVzdCBhbiBGWUksIDZtYW4gaGFzIGdvdCBub3Qgb25lIGJ1dCBUV08gZHJhZnRzIG9uIFZJTnMgYW5kIElQdjYgYWRkcmVzc2VzOg0KDQoxKSBWZWhpY2xlIElkZW50aWZpY2F0aW9uIE51bWJlci1CYXNlZCBJUHY2IEludGVyZmFjZSBJZGVudGlmaWVyDQooVklJRCksIGF0OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pbWFkYWxpLWl0cy12aW5pcHY2LXZpaWQtMDANCjIpIFZlaGljbGUgSWRlbnRpZmljYXRpb24gTnVtYmVyLUJhc2VkIFVuaXF1ZSBMb2NhbCBJUHY2IFVuaWNhc3QNCkFkZHIBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.134.513 Message-ID: <1361472754.69123.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> Date: Thu, 21 Feb 2013 10:52:34 -0800 (PST) From: Bill Jouris To: Dino Farinacci In-Reply-To: <86AF721F-EC74-46B2-B922-4222E4F599C9@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-285822631-1361472754=:69123" Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 18:52:37 -0000 --1510626085-285822631-1361472754=:69123 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Just an FYI, 6man has got not one but TWO drafts on VINs and IPv6 addresses= : 1) Vehicle Identification Number-Based IPv6 Interface Identifier (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast Addresses (VULA), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00 It must be something in the air, that is putting the same area in everyone'= s heads.... Bill=20 --- On Thu, 2/21/13, Dino Farinacci wrote: From: Dino Farinacci Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-a= sn To: "Nick Hilliard" Cc: v6ops@ietf.org Date: Thursday, February 21, 2013, 9:59 AM So let's get back on track: (1) I brought up VIN numbers because people are requesting for rather opaqu= e addresses. (2) I said that LISP EIDs are typically used as opaque addresses. (3) I said the draft-mlevy-v6ops-auto-v6-allocation-per-asn is a decent enc= oding format for EIDs. Nothing more was said, implied, or suggested. Dino On Feb 21, 2013, at 9:33 AM, Nick Hilliard wrote: > On 21/02/2013 17:08, Dino Farinacci wrote: >> It is a real user/customer requirement. IETF should not tell users how >> to assign their addresses. Just allow part of the address space >> available so they can do what they want. >=20 > if the car makers want a new VIN bin, then they can have it.=A0 The only > requirement for creating a new bin is a common agreement between them tha= t > their chosen range of integers or symbols means something to them.=A0 Whe= ther > or not this range is a subset of an ietf-assigned ipv6 subnet is complete= ly > irrelevant. >=20 > From the IETF's point of view, if the car makers come to them and ask the= m > for a range of numbers for car VINs, my reaction would be "wut?" >=20 > Nick >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --1510626085-285822631-1361472754=:69123 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Just an FYI, 6man has got not one but TWO dra= fts on VINs and IPv6 addresses:

1) Vehicle Identification Number-Bas= ed IPv6 Interface Identifier
(VIID), at: http://tools.ietf.org/html/draf= t-imadali-its-vinipv6-viid-00
2) Vehicle Identification Number-Based Uni= que Local IPv6 Unicast
Addresses (VULA), at:
http://tools.ietf.org/ht= ml/draft-imadali-its-vinipv6-vula-00


It must be something in the= air, that is putting the same area in everyone's heads....

Bill


--- On Thu, 2/21/13, Dino Farinacci = <farinacci@gmail.com> wrote:

= From: Dino Farinacci <farinacci@gmail.com>
Subject: Re: [v6ops] Co= mments to draft-mlevy-v6ops-auto-v6-allocation-per-asn
To: "Nick Hilliar= d" <nick@inex.ie>
Cc: v6ops@ietf.org
Date: Thursday, February 21,= 2013, 9:59 AM

So let's get back on track:<= br>
(1) I brought up VIN numbers because people are requesting for rathe= r opaque addresses.
(2) I said that LISP EIDs are typically used as opaq= ue addresses.
(3) I said the draft-mlevy-v6ops-auto-v6-allocation-per-as= n is a decent encoding format for EIDs.

Nothing more was said, impli= ed, or suggested.

Dino

On Feb 21, 2013, at 9:33 AM, Nick Hill= iard <nick@inex.ie> wrote:

> On 21/02/2013 17:08, Dino F= arinacci wrote:
>> It is a real user/customer requirement. IETF sh= ould not tell users how
>> to assign their addresses. Just allow p= art of the address space
>> available so they can do what they wan= t.
>
> if the car makers want a new VIN bin, then they can hav= e it.  The only
> requirement for creating a new bin is a common = agreement between them that
> their chosen range of integers or symbo= ls means something to them.  Whether
> or not this range is a su= bset of an ietf-assigned ipv6 subnet is completely
> irrelevant.
&= gt;
> From the IETF's point of view, if the car makers come to them = and ask them
> for a range of numbers for car VINs, my reaction would= be "wut?"
>
> Nick
>

__________________________= _____________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops
--1510626085-285822631-1361472754=:69123-- From jhw@apple.com Thu Feb 21 11:33: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 2FC0D21F8EF4 for ; Thu, 21 Feb 2013 11:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -63.971 X-Spam-Level: X-Spam-Status: No, score=-63.971 tagged_above=-999 required=5 tests=[AWL=-46.628, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_GREY=0.25, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_RED=0.001, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U0m2ZZOVyYS for ; Thu, 21 Feb 2013 11:33:15 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id CC6EA21F8984 for ; Thu, 21 Feb 2013 11:33:15 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MIL00FQS4Z0TX42@mail-out.apple.com> for v6ops@ietf.org; Thu, 21 Feb 2013 11:33:15 -0800 (PST) X-AuditID: 1180711d-b7f966d000005f62-50-5126767b0d94 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 37.E4.24418.B7676215; Thu, 21 Feb 2013 11:33:15 -0800 (PST) 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 <0MIL005EF4ZEJS90@aniseed.apple.com> for v6ops@ietf.org; Thu, 21 Feb 2013 11:33:15 -0800 (PST) From: james woodyatt In-reply-to: <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 21 Feb 2013 11:33:14 -0800 Message-id: References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1361392079.27417.YahooMailNeo@web142501.mail.bf1.yahoo.com> <20130221012540.B3D192FECCED@drugs.dv.isc.org> <1361416048.43450.YahooMailNeo@web142504.mail.bf1.yahoo.com> To: v6ops v6ops WG X-Mailer: Apple Mail (2.1682) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FAsrltdphZo8OKwlMXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fTiDeaCfVwVC64GNjBO5ehi5OSQEDCR+Hy+hx3CFpO4cG89 WxcjF4eQwBQmiY1v/zBCODOYJP4cuMcMUsUsoCPR+/0bmM0roCcxc+USVhBbWCBDonfvbzCb TUBF4tvlu0wgNqeAp8SDnqtAgzg4WARUJRbesoMYoy3x5N0FVogxNhI3Zh5kh9j1mEniy86J LCAJEQFliSeH5jBBXCcr8eFKG/sERv5ZSM6YheSMWUjmLmBkXsUoWJSak1hpaKyXWFCQk6qX nJ+7iREcYoWyOxj3/+Q/xCjAwajEw9vqohYoxJpYVlyZe4hRgoNZSYRXPxQoxJuSWFmVWpQf X1Sak1p8iFGag0VJnLfJTTVQSCA9sSQ1OzW1ILUIJsvEwSnVwJinX7J6ySMpvT5pN1lvhQhj Y6s14cGG78udQi63Wk95sSX6WPbtesV4p29/V3JfE/gTv8F2raB2l7ejiMnXum+VvHdnT/JM WrXi/+zZzbxTNttd7H6zwfGD5vckjaXTYx+17lonui3uRVqgGv/ToJWRJa9y/gdn2J9JtC/4 9YL94Mc/PKEdO5RYijMSDbWYi4oTAQ0d7lEtAgAA Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:33:16 -0000 On Feb 20, 2013, at 19:07 , Mark Smith wrote: > For example, fe80::1/10 might be automatically configured on Mac OS X on the loopback interface, but can you use fe80::2, fe80::3, fe80::4567:1234 and have them all automatically work? Have you tried it? [Insert "IT WORKS ON MY MACHINE" LOL-cat graphic here.] > Special link-local behaviour on the loopback interface isn't specified as far as I know [...] As far as you know. Look, if you think what's already there in RFC 4007 and RFC 4291 isn't clear enough, then let's see a draft to clean that up. I'm prepared to support a reasonable effort to do that. > and since link-local doesn't have anything to distinguish the link local prefix on loopback from eth0, you also have to specify an interface, so it also fails 2. Really? Having to use a zone identifier on the address literal is enough to make it too hard to type and remember? I get that looks a little less messy than , but it's really not *that* much worse, is it? Outside the URI syntax, it's even easier. I need a T-shirt that says: THERE'S NO PLACE LIKE ::1 (except fe80::1%lo0, which is just like it) -- james woodyatt core os networking From markzzzsmith@yahoo.com.au Thu Feb 21 12:23: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 BDD4321F890D for ; Thu, 21 Feb 2013 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0cQFe38ewly for ; Thu, 21 Feb 2013 12:23:51 -0800 (PST) Received: from nm39-vm7.bullet.mail.bf1.yahoo.com (nm39-vm7.bullet.mail.bf1.yahoo.com [72.30.239.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6136021F88E2 for ; Thu, 21 Feb 2013 12:23:50 -0800 (PST) Received: from [98.139.214.32] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 20:23:49 -0000 Received: from [98.139.212.240] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 20:23:49 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 21 Feb 2013 20:23:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 431398.89225.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 22238 invoked by uid 60001); 21 Feb 2013 20:23:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361478229; bh=aCJn0QbFBNzZZrCt/O8GFjOQSQ/y0ExfRmafwxNOBL8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dIJbLocjzTjNw4bW6OJjNCwswgUfUgCVKMAhL5MKrgZRvDUTJOl1XkiaANoJyQZFtce2dmjVF2Mhcpu3YQZLhKFWAxMxH37RHe2MDz8hUS/E2YlnnWWauzsEKMYpndt1T6iSyrVyzx8lgNf0cyCC53Fi71LGrPD0G+uv3xCVYd8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=L5Vrt+OnOPvwmVt8QTPd8LG0VfKmGf1XcHDP8pdybTS3GF1XWWsvdPsKXqoNqNBM6vA87VjLkdno4rB+5csT2GhwZ7b9eceQQnBb17+DQQ0mx4f6TUqlV6IAAOKhEcshJ4P1lBjVdaBjsLwIDBHusuj8q/2mJxeKvb+zS5s9pWA=; X-YMail-OSG: LOK7HBUVM1nPuxrPHbCqyCNbxj7v32qmXcdFqgotC4VcAyI TSkBURfVFPWx.DEoxch6EGaTQAwig6jQxQXxBuhRRUrloBHaxEo8xaB.wrPf siVOtNQaBf.5YYuKQZ33osS5jdHDp7wBgY9ST0VEnBNcf4.2P21MBBcw48Zd MfN_tUTBODF__8SSR1VSyW0_PgWIVNIaxE5gt7rKsoIhI.M25jCym5KpPStD ij9vDXyaaV2OXg5A0Y_v4BaVdSRusYcZgKyS0RukSSHG_2AV4usep.AIHbBI O2bVNT4BN0V3GkaR0k5iIXw.KNSoShcAwaGFKuStNlU33nu8jeKr3wIEC7N. GP_Yg3J0ZtXKRXSs0z4IdX1D25zWNY5R.VMr.7vYbIdaJ0A6MHGn7kkq7f8h XNZ9ZShdnW1bDZQtRFs2Pvm__.N0vg_n8u7bwTvsUa_BdWo5ny7hwQLZ544E ZszQHgqr5INBOHuTvkT1fgD5SueBse2c7FffN3TVfY.lCBKoIfHsE0fMwGiC Z8QOiTehgllQHomqbyu.UszWs Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 21 Feb 2013 12:23:49 PST X-Rocket-MIMEInfo: 001.001, SnVzdCBzbyBldmVyeWJvZHkga25vd3MsIEkndmUgZ2l2ZW4gdXAgb24gdGhpcywgYXMgb2J2aW91c2x5IGl0IGlzIG5vdCBnb2luZyB0byBhY2hpZXZlIGNvbnNlbnN1cywgYW5kIEkndmUgc3BlbnQgYXMgbXVjaCBvZiBteSBvd24gdGltZSBvbiBpdCBhcyBJJ20gZ29pbmcgdG8uCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gVG86IHY2b3BzIHY2b3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4KPiBDYzogCj4gU2VudDoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <20130220191706.20280.59416.idtracker@ietfa.amsl.com> <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1361478229.21619.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 21 Feb 2013 12:23:49 -0800 (PST) From: Mark Smith To: v6ops v6ops WG In-Reply-To: <1361388476.43517.YahooMailNeo@web142501.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:23:51 -0000 Just so everybody knows, I've given up on this, as obviously it is not goin= g to achieve consensus, and I've spent as much of my own time on it as I'm = going to.=0A=0A=0A----- Original Message -----=0A> From: Mark Smith =0A> To: v6ops v6ops WG =0A> Cc: =0A> S= ent: Thursday, 21 February 2013 6:27 AM=0A> Subject: Fw: New Version Notifi= cation for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt=0A> =0A> Hi= ,=0A> =0A> Here is a new version of my larger IPv6 loopback prefix draft. C= hanges since the =0A> last version are relatively minor:=0A> =0A> =A0 =A0o = =A0usability references (DOET and EASY-NUMBERS)=0A> =A0=0A> =A0 =A0o =A0min= or clarifications=0A> =A0=0A> =A0 =A0o =A0grammar corrections=0A> =0A> Furt= her review welcome and appreciated.=0A> =0A> Regards,=0A> Mark.=0A> =0A> = =0A> ----- Forwarded Message -----=0A>> From: "internet-drafts@ietf.org" <= internet-drafts@ietf.org>=0A>> To: markzzzsmith@yahoo.com.au=0A>> Cc: =0A= >> Sent: Thursday, 21 February 2013 6:17 AM=0A>> Subject: New Version Not= ification for =0A> draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt=0A>= > =0A>> =0A>> A new version of I-D, draft-smith-v6ops-larger-ipv6-loopback= -prefix-04.txt=0A>> has been successfully submitted by Mark Smith and post= ed to the=0A>> IETF repository.=0A>> =0A>> Filename:=A0=A0=A0=A0 draft-sm= ith-v6ops-larger-ipv6-loopback-prefix=0A>> Revision:=A0=A0=A0=A0 04=0A>> = Title:=A0=A0=A0 =A0=A0=A0=A0 A Larger Loopback Prefix for IPv6=0A>> Creati= on date:=A0=A0=A0=A0 2013-02-20=0A>> Group:=A0=A0=A0 =A0=A0=A0=A0 Individu= al Submission=0A>> Number of pages: 12=0A>> URL:=A0 =A0 =A0 =A0 =A0 =A0 = =0A>> =0A> http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv= 6-loopback-prefix-04.txt=0A>> Status:=A0 =A0 =A0 =A0 =A0 =0A>> =0A> http:/= /datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix=0A>= > Htmlized:=A0 =A0 =A0 =A0 =0A>> http://tools.ietf.org/html/draft-smith-v= 6ops-larger-ipv6-loopback-prefix-04=0A>> Diff:=A0 =A0 =A0 =A0 =A0 =A0 =0A>= > =0A> http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loo= pback-prefix-04=0A>> =0A>> Abstract:=0A>> =A0=A0 During the development a= nd testing of a network application, it can=0A>> =A0=A0 be useful to run m= ultiple instances of the application using the same=0A>> =A0=A0 transport = layer protocol port on the same development host, while=0A>> =A0=A0 also h= aving network access to the application instances limited to=0A>> =A0=A0 t= he local host.=A0 Under IPv4, this has commonly been possible by using=0A>>= =A0=A0 different loopback addresses within 127/8.=A0 It is not possible u= nder=0A>> =A0=A0 IPv6, as the loopback prefix of ::1/128 only provides a s= ingle=0A>> =A0=A0 loopback address.=A0 This memo proposes a new larger loo= pback prefix=0A>> =A0=A0 that will provide many IPv6 loopback addresses.= =A0 The processing rules=0A>> =A0=A0 for this new larger loopback prefix a= lso allow sending or forwarding=0A>> =A0=A0 of packets containing these ad= dresses beyond the originating router=0A>> =A0=A0 under certain circumstan= ces.=0A>> =0A>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =0A> =A0 =A0 =0A>> =A0 =0A>> =0A>> =0A>> The IETF Se= cretariat=0A>> =0A> From cb.list6@gmail.com Thu Feb 21 12:40:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3321D21F8F14 for ; Thu, 21 Feb 2013 12:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceIHTEH-iR-0 for ; Thu, 21 Feb 2013 12:40:38 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3C35821F8688 for ; Thu, 21 Feb 2013 12:40:38 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id q3so1716498yhf.12 for ; Thu, 21 Feb 2013 12:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3O09FVkLT+/Ba7q+B11ABzgNXTBkH+zseUl9Av+8bP4=; b=ZYQKa3e74TxxZ5qWChcfBf5vM1xG/9yboqcPQnecH+FC+W3SUhWKf5UiSQKFzaQQL7 U8h0+FdaeX3v8WTE/kppn6rqzzkaXOHh4j+aiwy8s5OX0HeC4MoLCngfUabzlyehjCGK 5uTGewFChLJefYdFkSCkgmeSH7lLQe3mzTzPyuh6u9ng64f7B2Zx28raMea1HUQryjJ2 m424Yl/Nd0ziwp0p+wc2g6rUznAyqgvPhdGhYFKBODsPpRPoejaIimokFrwF7v29SWrs N1tn+uAGULmvwHOpnQ91qf1EVosGbM+QvJJeuWscg1OJ6SguvId9qerF7RLlx86fdBsV CfMA== MIME-Version: 1.0 X-Received: by 10.101.42.14 with SMTP id u14mr8219900anj.38.1361479237739; Thu, 21 Feb 2013 12:40:37 -0800 (PST) Received: by 10.236.172.233 with HTTP; Thu, 21 Feb 2013 12:40:37 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Feb 2013 12:40:37 -0800 Message-ID: From: Cameron Byrne To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 20:40:39 -0000 Behcet, On Wed, Feb 20, 2013 at 2:45 PM, Behcet Sarikaya wrote: > Hi Cameron, > > sorry for my belated reply. > > On Sun, Feb 3, 2013 at 7:37 PM, Cameron Byrne wrote: >> >> >> >> Since a lot of folks talk about IPv6 in mobile, i figured i would pen >> my own view and experience here. It hopefully will set some context >> for the WG work products draft-ietf-v6ops-464xlat, >> draft-ietf-v6ops-64share, >> draft-binet-v6ops-cellular-host-requirements. Please do note 464XLAT >> is not 3GPP/mobile specific. >> >> AFAIK, there is exactly 1 provider in the world of 3GPP that offers >> dual-stack service by default, Verizon Wireless (hat tip). I did not >> count, but there is probably more that 50 LTE networks out there today >> http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be some >> others that support default-on dual-stack, i but i don't know of them. >> >> So, conclusion #1 is that that LTE does not require or even help IPv6 >> deployment. Look at the facts. There is a long list of LTE networks >> that definitely do not have IPv6 or dual-stack by default: AT&T, >> Sprint, EE, T-Mobile DE, Rogers, Vodafone, .. >> > > Maybe they realized that NAT44 is good enough for them to handle not so many > LTE customers they have? They already know NAT44 technology. > Correct. NAT44 is good enough if you can number users from RFC1918. If users (including M2M ...) and infrastructure exceed RFC1918 space the problem becomes substantially more complicated and NAT44 is not nearly as fit for the problem. For many mobile networks, they have always been on NAT44 so inertia supports staying on NAT44. My specific problem is that i have more users / gear / cell sites than RFC1918, that is my driver for ipv6. >> >> I believe a lot of folks, myself included, thought network upgrades >> would bring about more IPv6 features and deployment. In my own >> experience, this is the exact opposite in reality. Let me explain. >> >> There are 4 major providers of 3GPP equipment. I will exonerate >> Huawei since i don't know anything about them and Cisco because i know >> there stuff works (AFAIK). The other 2 providers are specifically >> defunct on the IPv4v6 front. One -- has a brand new high capacity >> P-GW/GGSN which does not support IPv4v6 (it supports v4 or v6). > > >> >> And >> the other, which is painfully wrecking my IPv4v6 deployment plans, has >> a newish (few years old now) high capacity SGSN which does not support >> IPv4v6 (also supports v4 or v6). > > > This should be OK for SGSN because you don't even need SGSN to support IPv6 > in order to support IPv6 in your network, right? because of the inherent > tunneling. > As Ales noted, the issue is with control plane signalling and handover between 2G/3G/4G. If the features are not synchronized, it does not work well... especially if features such as "CS Fall Back" are used to push between 3G and 4G for voice calls. >> Witness, new gear does not result in >> v4v6 (dual-stack). > > > I remember you voiced strongly against the dual stack approach. You seemed > to have advocated IPv6 only network with 4via6 approaches, v4 users can be > supported. This was what you were advocating, and for a good reason. > This was my "crazy" single-stack perspective, but i think it has become more popular and therefore slightly less crazy :) I am still making progress on rolling out 464XLAT. The missing piece right now is the handset, but it is making progress. As noted in my rant, unforunately many vendors ship new gear without IPv6. It seems counter-intuitive. Many folks thought they might new gear to do IPv6, but in these specific cases new gear removed IPv6 functions. >> >> In fact, the legacy SGSN that i had from the same >> vendor does support v4v6, but it is now end of life (at least as far >> as my network)! It is just the new one that does not have dual-stack >> support. >> >> Thought i would just share, and dispel any misconceptions folks had >> about 3GPP / LTE networks and IPv6, especially about dual-stack. >> There is nothing wrong with the 3GPP specs, and i know the network >> operators are asking but not getting the features ... That said, >> draft-ietf-v6ops-464xlat and draft-ietf-v6ops-64share are both hacks >> that try to route around the brokeness of economics, NAT444s, vendors >> that don't ship 4+ year old 3GPP defined mandatory features (IPv4v6 >> LTE bearers), and > > >> >> IPV4-only apps like Skype. >> > > This seems to be the main issue. > What a pity :-). > A pity indeed. The lesson I learned over the last few years is that it is easier to change the host than the apps. It seems counter-intuitive, but alas we must understand the things we can control and the things we cannot control. CB > Regards, > > Behcet From randy@psg.com Thu Feb 21 13:11: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 94AA821F8EC6 for ; Thu, 21 Feb 2013 13:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5zW+89kbcqe for ; Thu, 21 Feb 2013 13:11:34 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFBC21F8E62 for ; Thu, 21 Feb 2013 13:11:34 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8dQT-0007Z4-EN; Thu, 21 Feb 2013 21:11:33 +0000 Date: Fri, 22 Feb 2013 06:11:32 +0900 Message-ID: From: Randy Bush To: Bill Jouris In-Reply-To: <1361465143.30805.YahooMailClassic@web2806.biz.mail.ne1.yahoo.com> References: <512649CC.1080108@inex.ie> <1361465143.30805.YahooMailClassic@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: IETF v6ops list Subject: Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Feb 2013 21:11:34 -0000 > All I'm saying is that, if the IETF is going to say anything about > relating IPv6 addresses to VIN numbers this case should not arise. this exercise indicates serious confusion on the part of someone. randy From shtsuchi@cisco.com Thu Feb 21 16:23: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 CBCA021F86E8 for ; Thu, 21 Feb 2013 16:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V-zddU9Mi4E for ; Thu, 21 Feb 2013 16:23:18 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1A721F85FD for ; Thu, 21 Feb 2013 16:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2387; q=dns/txt; s=iport; t=1361492597; x=1362702197; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KZwspVZvnZrh0O6tBFWFG8piI7NqNyxTrBjyZFmdEW0=; b=KtAvj76YK53YiFyrsXosCzZ7yltvYVNoSTMUq4Q9PufcaoOmoJKnRMlv iQ3EiJqiDgNVt3SFmDowXKrwYkGD2pOZhAu3oAeOMARe2m36KhnOgAoo1 WM175xoX/LP5NqvuJY1QPkPKo+mWsZtHWoR4hJyAjPTWB+2QM/e2nDw3R M=; X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="25911482" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 22 Feb 2013 00:23:15 +0000 Received: from dhcp-10-141-40-132.cisco.com (dhcp-10-141-40-132.cisco.com [10.141.40.132]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1M0NEcT016788; Fri, 22 Feb 2013 00:23:15 GMT Message-ID: <5126BA74.5080508@cisco.com> Date: Fri, 22 Feb 2013 09:23:16 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Feb 2013 00:23:18 -0000 Ales (2013/02/21 1:00), Vízdal Aleš wrote: > Shishio, > >> -----Original Message----- >> From: Shishio Tsuchiya [mailto:shtsuchi@cisco.com] >> Sent: Tuesday, February 19, 2013 4:41 PM >> To: Vízdal Aleš >> Cc: v6ops@ietf.org; draft-shishio-v6ops-dpvt@tools.ietf.org; shtsuchi@cisco.com >> Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >> >> Ales >> Thank for your interest. >> As I described reply to Fred, > > What you've responded to is a default email that is send to the authors by the tracker > once a new draft is posted. > >> The stateless tunnel and prefix delegation technology provides much scalability >> network to the customer. >> On one hand, these technologies are difficult to plan additional capacity and hard to >> know current deployment >> status unless the devices are completely managed. >> If the BR has state and DHCPv6 server knows detail route,then the merit of these >> technologies would be disappeared. > > Let's take the DHCP-PD case, I assume that the IP resource planning goes hand in hand > with the number of subscribers the ISP is expecting to serve. The operator needs to decide > on the prefix-length to be delegated down to the subscriber and that's it, so they can > plan enough prefixes per access area. The operator does not need to know if/how I am using > my delegated prefix. They should be happy to give/sell me another prefix if needed. > > Can you please clarify what's the benefit from Operator's point of view? Yes,this is ideal planning. And RIR also has published guide line of IPv6 assignment for enduser. http://www.apnic.net/publications/media-library/documents/resource-guidelines/ipv6-guidelines RFC6177 was published as BCP. http://tools.ietf.org/html/rfc6177 Most of ISP used be provided /48 by dhcp-pd and when after RFC3177 obsoleted, they changed it to /56 and more shorter. If the policy would be changed ,then operator should understand how delegated prefix are using. This is reason of the feature could provide to operators benefit ,I thought. Thanks for your feedback. Regards, -Shishio > >> So I thought these technologies need small oam tools. >> >> -confirm only interface configuration from ISP side >> -confirm reachability not use end to end >> >> I would appreciate any comment. >> >> Regards, >> -Shishio > > Cheers, > Ales > From ales.vizdal@t-mobile.cz Fri Feb 22 01:07: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 A04B421F8E77 for ; Fri, 22 Feb 2013 01:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f78THUxAlzws for ; Fri, 22 Feb 2013 01:07:25 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8290D21F867D for ; Fri, 22 Feb 2013 01:07:23 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 2030D285824; Fri, 22 Feb 2013 10:07:21 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Fri, 22 Feb 2013 10:07:20 +0100 From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: Shishio Tsuchiya Date: Fri, 22 Feb 2013 10:07:22 +0100 Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: Ac4QktFK8g3VMJ13Sha/JmWvzo/NpQARfi/A Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CFB3C2EA@SRVHKE02.rdm.cz> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> In-Reply-To: <5126BA74.5080508@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Feb 2013 09:07:26 -0000 U2hpc2hpbywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaGlzaGlv IFRzdWNoaXlhIFttYWlsdG86c2h0c3VjaGlAY2lzY28uY29tXQ0KPiBTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDIyLCAyMDEzIDE6MjMgQU0NCj4gVG86IFbDrXpkYWwgQWxlxaENCj4gQ2M6IFNoaXNo aW8gVHN1Y2hpeWE7IHY2b3BzQGlldGYub3JnOyBkcmFmdC1zaGlzaGlvLXY2b3BzLWRwdnRAdG9v bHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1zaGlz aGlvLXY2b3BzLWRwdnQNCj4gDQo+IEFsZXMNCj4gKDIwMTMvMDIvMjEgMTowMCksIFbDrXpkYWwg QWxlxaEgd3JvdGU6DQo+ID4gU2hpc2hpbywNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+PiBGcm9tOiBTaGlzaGlvIFRzdWNoaXlhIFttYWlsdG86c2h0c3VjaGlAY2lz Y28uY29tXQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxOSwgMjAxMyA0OjQxIFBNDQo+ ID4+IFRvOiBWw616ZGFsIEFsZcWhDQo+ID4+IENjOiB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtc2hp c2hpby12Nm9wcy1kcHZ0QHRvb2xzLmlldGYub3JnOyBzaHRzdWNoaUBjaXNjby5jb20NCj4gPj4g U3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1zaGlzaGlvLXY2b3BzLWRwdnQN Cj4gPj4NCj4gPj4gQWxlcw0KPiA+PiBUaGFuayBmb3IgeW91ciBpbnRlcmVzdC4NCj4gPj4gQXMg SSBkZXNjcmliZWQgcmVwbHkgdG8gRnJlZCwNCj4gPg0KPiA+IFdoYXQgeW91J3ZlIHJlc3BvbmRl ZCB0byBpcyBhIGRlZmF1bHQgZW1haWwgdGhhdCBpcyBzZW5kIHRvIHRoZSBhdXRob3JzIGJ5IHRo ZQ0KPiB0cmFja2VyDQo+ID4gb25jZSBhIG5ldyBkcmFmdCBpcyBwb3N0ZWQuDQo+ID4NCj4gPj4g VGhlIHN0YXRlbGVzcyB0dW5uZWwgYW5kIHByZWZpeCBkZWxlZ2F0aW9uIHRlY2hub2xvZ3kgcHJv dmlkZXMgbXVjaCBzY2FsYWJpbGl0eQ0KPiA+PiBuZXR3b3JrIHRvIHRoZSBjdXN0b21lci4NCj4g Pj4gT24gb25lIGhhbmQsIHRoZXNlIHRlY2hub2xvZ2llcyBhcmUgZGlmZmljdWx0IHRvIHBsYW4g YWRkaXRpb25hbCBjYXBhY2l0eSBhbmQgaGFyZA0KPiB0bw0KPiA+PiBrbm93IGN1cnJlbnQgZGVw bG95bWVudA0KPiA+PiBzdGF0dXMgdW5sZXNzIHRoZSBkZXZpY2VzIGFyZSBjb21wbGV0ZWx5IG1h bmFnZWQuDQo+ID4+IElmIHRoZSBCUiBoYXMgc3RhdGUgYW5kIERIQ1B2NiBzZXJ2ZXIga25vd3Mg ZGV0YWlsIHJvdXRlLHRoZW4gdGhlIG1lcml0IG9mIHRoZXNlDQo+ID4+IHRlY2hub2xvZ2llcyB3 b3VsZCBiZSBkaXNhcHBlYXJlZC4NCj4gPg0KPiA+IExldCdzIHRha2UgdGhlIERIQ1AtUEQgY2Fz ZSwgSSBhc3N1bWUgdGhhdCB0aGUgSVAgcmVzb3VyY2UgcGxhbm5pbmcgZ29lcyBoYW5kIGluDQo+ IGhhbmQNCj4gPiB3aXRoIHRoZSBudW1iZXIgb2Ygc3Vic2NyaWJlcnMgdGhlIElTUCBpcyBleHBl Y3RpbmcgdG8gc2VydmUuIFRoZSBvcGVyYXRvciBuZWVkcyB0bw0KPiBkZWNpZGUNCj4gPiBvbiB0 aGUgcHJlZml4LWxlbmd0aCB0byBiZSBkZWxlZ2F0ZWQgZG93biB0byB0aGUgc3Vic2NyaWJlciBh bmQgdGhhdCdzIGl0LCBzbyB0aGV5DQo+IGNhbg0KPiA+IHBsYW4gZW5vdWdoIHByZWZpeGVzIHBl ciBhY2Nlc3MgYXJlYS4gVGhlIG9wZXJhdG9yIGRvZXMgbm90IG5lZWQgdG8ga25vdyBpZi9ob3cg SQ0KPiBhbSB1c2luZw0KPiA+IG15IGRlbGVnYXRlZCBwcmVmaXguIFRoZXkgc2hvdWxkIGJlIGhh cHB5IHRvIGdpdmUvc2VsbCBtZSBhbm90aGVyIHByZWZpeCBpZiBuZWVkZWQuDQo+ID4NCj4gPiBD YW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoYXQncyB0aGUgYmVuZWZpdCBmcm9tIE9wZXJhdG9yJ3Mg cG9pbnQgb2Ygdmlldz8NCj4gDQo+IFllcyx0aGlzIGlzIGlkZWFsIHBsYW5uaW5nLg0KPiBBbmQg UklSIGFsc28gaGFzIHB1Ymxpc2hlZCBndWlkZSBsaW5lIG9mIElQdjYgYXNzaWdubWVudCBmb3Ig ZW5kdXNlci4NCj4gaHR0cDovL3d3dy5hcG5pYy5uZXQvcHVibGljYXRpb25zL21lZGlhLWxpYnJh cnkvZG9jdW1lbnRzL3Jlc291cmNlLWd1aWRlbGluZXMvaXB2Ni0NCj4gZ3VpZGVsaW5lcw0KPiBS RkM2MTc3IHdhcyBwdWJsaXNoZWQgYXMgQkNQLg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2MTc3DQo+IA0KPiBNb3N0IG9mIElTUCB1c2VkIGJlIHByb3ZpZGVkIC80OCBieSBkaGNw LXBkIGFuZCB3aGVuIGFmdGVyIFJGQzMxNzcgb2Jzb2xldGVkLCB0aGV5DQo+IGNoYW5nZWQgaXQg dG8gLzU2IGFuZCBtb3JlIHNob3J0ZXIuDQo+IElmIHRoZSBwb2xpY3kgd291bGQgYmUgY2hhbmdl ZCAsdGhlbiBvcGVyYXRvciBzaG91bGQgdW5kZXJzdGFuZCBob3cgZGVsZWdhdGVkIHByZWZpeA0K PiBhcmUgdXNpbmcuDQo+IFRoaXMgaXMgcmVhc29uIG9mIHRoZSBmZWF0dXJlIGNvdWxkIHByb3Zp ZGUgdG8gb3BlcmF0b3JzIGJlbmVmaXQgLEkgdGhvdWdodC4NCg0KSSBhbSBub3Qgc3VyZSBJIGZv bGxvdyAuLi4gYnV0IGFyZSB5b3UgdHJ5aW5nIHRvIHNheSB0aGF0IHNob3VsZCB0aGUgUklSIHBv bGljeSBjaGFuZ2UgcmVzdWx0aW5nDQppbiBJU1BzIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQn cyB0aGUgYmVzdCBwcmVmaXggdG8gYmUgYWxsb2NhdGVkIHRvIGFuIGVuZCB1c2VyIHlvdXIgDQp0 b29scyB3b3VsZCBhbGxvdyB0byBmaW5kIG91dCB0aGUgY3VycmVudCB1dGlsaXphdGlvbiBvZiBh bHJlYWR5IGFzc2lnbmVkIHByZWZpeGVzPw0KDQpJZiBzbywgSSBiZWxpZXZlIHRoZXJlIGFyZSBv dGhlciB3YXlzIGhvdyB0byBmaW5kIG91dCB3aXRob3V0IGludm9sdmluZyB0aGUgY3VzdG9tZXIN CnN1Y2ggYXMgbmV0Zmxvdy9pcGZpeC4NCg0KPiBUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suDQo+ IA0KPiBSZWdhcmRzLA0KPiAtU2hpc2hpbw0KDQpDaGVlcnMsDQpBbGVzDQo= From shtsuchi@cisco.com Fri Feb 22 01:26:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34421F8CAB for ; Fri, 22 Feb 2013 01:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.332 X-Spam-Level: X-Spam-Status: No, score=-9.332 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOfaV+Tg50KM for ; Fri, 22 Feb 2013 01:26:32 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 85CEC21F8C5D for ; Fri, 22 Feb 2013 01:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3357; q=dns/txt; s=iport; t=1361525191; x=1362734791; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AR3MYTr0p+48WmiAOMXfGwQa9yY6bgaFgkJIq3eXlz4=; b=H6kA6sRPx3iKbW7jZUDNmdxdyqYO/C0oGwaq0Sd3tppktf/YbKr9de3r Xmeb2l7Wj3DE7OQ51DdUnqykE50FBJQhk+9s9XQhn70BoTX/of07W6Lda D+FfC9VQuguqBoKt1G9kWs4oJN/zh6RBeOCXljmKwNdX9/KzjwnFAT/Es k=; X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; d="scan'208";a="25944543" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 22 Feb 2013 09:26:30 +0000 Received: from dhcp-10-141-40-132.cisco.com (dhcp-10-141-40-132.cisco.com [10.141.40.132]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1M9QTQa024563; Fri, 22 Feb 2013 09:26:29 GMT Message-ID: <512739C5.9090302@cisco.com> Date: Fri, 22 Feb 2013 18:26:29 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3C2EA@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6CFB3C2EA@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Feb 2013 09:26:32 -0000 Ales (2013/02/22 18:07), Vízdal Aleš wrote: > Shishio, > >> -----Original Message----- >> From: Shishio Tsuchiya [mailto:shtsuchi@cisco.com] >> Sent: Friday, February 22, 2013 1:23 AM >> To: Vízdal Aleš >> Cc: Shishio Tsuchiya; v6ops@ietf.org; draft-shishio-v6ops-dpvt@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >> >> Ales >> (2013/02/21 1:00), Vízdal Aleš wrote: >>> Shishio, >>> >>>> -----Original Message----- >>>> From: Shishio Tsuchiya [mailto:shtsuchi@cisco.com] >>>> Sent: Tuesday, February 19, 2013 4:41 PM >>>> To: Vízdal Aleš >>>> Cc: v6ops@ietf.org; draft-shishio-v6ops-dpvt@tools.ietf.org; shtsuchi@cisco.com >>>> Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >>>> >>>> Ales >>>> Thank for your interest. >>>> As I described reply to Fred, >>> >>> What you've responded to is a default email that is send to the authors by the >> tracker >>> once a new draft is posted. >>> >>>> The stateless tunnel and prefix delegation technology provides much scalability >>>> network to the customer. >>>> On one hand, these technologies are difficult to plan additional capacity and hard >> to >>>> know current deployment >>>> status unless the devices are completely managed. >>>> If the BR has state and DHCPv6 server knows detail route,then the merit of these >>>> technologies would be disappeared. >>> >>> Let's take the DHCP-PD case, I assume that the IP resource planning goes hand in >> hand >>> with the number of subscribers the ISP is expecting to serve. The operator needs to >> decide >>> on the prefix-length to be delegated down to the subscriber and that's it, so they >> can >>> plan enough prefixes per access area. The operator does not need to know if/how I >> am using >>> my delegated prefix. They should be happy to give/sell me another prefix if needed. >>> >>> Can you please clarify what's the benefit from Operator's point of view? >> >> Yes,this is ideal planning. >> And RIR also has published guide line of IPv6 assignment for enduser. >> http://www.apnic.net/publications/media-library/documents/resource-guidelines/ipv6- >> guidelines >> RFC6177 was published as BCP. >> http://tools.ietf.org/html/rfc6177 >> >> Most of ISP used be provided /48 by dhcp-pd and when after RFC3177 obsoleted, they >> changed it to /56 and more shorter. >> If the policy would be changed ,then operator should understand how delegated prefix >> are using. >> This is reason of the feature could provide to operators benefit ,I thought. > > I am not sure I follow ... but are you trying to say that should the RIR policy change resulting > in ISPs trying to figure out what's the best prefix to be allocated to an end user your > tools would allow to find out the current utilization of already assigned prefixes? > > If so, I believe there are other ways how to find out without involving the customer > such as netflow/ipfix. Yes, both of dhcp-pd and 6rd cases, operator can use netflow/ipfix to investigate for the utilization of prefixes and traffic. The draft is proposal of simpler way. If the merit is fewer than pain and risk, then the proposal should be withdrawn. So I would like to hear wg comment on IETF86. I really appreciate your many feedback. Let's modify next version. Regards, -Shishio From owen@delong.com Fri Feb 22 01: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 CA04321F8DFF for ; Fri, 22 Feb 2013 01:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5795TImFKhOa for ; Fri, 22 Feb 2013 01:30:56 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6B821F8DFD for ; Fri, 22 Feb 2013 01:30:55 -0800 (PST) Received: from dhcp50-95-223-141.hil-laxahhh.lax.wayport.net (dhcp50-95-223-141.hil-laxahhh.lax.wayport.net [50.95.223.141]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1M9Rh1S032431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Feb 2013 01:27:44 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1M9Rh1S032431 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361525265; bh=YHQmvpIRPd2iMnBqu9v4ddI/2SA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gOKQCp4hUW9odPCZ7OsmG0gSZX8BBnJKHFQNzVl7cf8JFA0qRtyM55cRuJ1SeqmVh UW/7vYF5Pln5yq80NL+QkRLjAij/b/QnWCzmHjsbQ/LgoeHtGOUJV4LcCmXlcNTBG+ qN8TDhRIh3hqQY+eaKioy6KAZ1W8EqSSgffhRih8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5126BA74.5080508@cisco.com> Date: Fri, 22 Feb 2013 01:27:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> To: Shishio Tsuchiya X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 22 Feb 2013 01:27:45 -0800 (PST) Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Feb 2013 09:31:07 -0000 >>=20 >> Let's take the DHCP-PD case, I assume that the IP resource planning = goes hand in hand >> with the number of subscribers the ISP is expecting to serve. The = operator needs to decide >> on the prefix-length to be delegated down to the subscriber and = that's it, so they can >> plan enough prefixes per access area. The operator does not need to = know if/how I am using >> my delegated prefix. They should be happy to give/sell me another = prefix if needed. >>=20 >> Can you please clarify what's the benefit from Operator's point of = view? >=20 > Yes,this is ideal planning. We can agree to disagree on your use of the term "ideal" in this = context. > And RIR also has published guide line of IPv6 assignment for enduser. > = http://www.apnic.net/publications/media-library/documents/resource-guideli= nes/ipv6-guidelines I'm not a particular fan of this document and have given APNIC feedback = on it. > RFC6177 was published as BCP. > http://tools.ietf.org/html/rfc6177 >=20 True. I wasn't participating actively in IETF at the time 6177 was = written. IMHO, it is a travesty of v4 thinking being brought forward = into IPv6 and should be considered harmful rather than BCP. It is = neither common, nor best practice in my experience so far in the IPv6 = world. I will point out that no RIR provides any policy penalty for sticking = with /48s and several of them actually provide benefits if you do so. = Notably, ARIN policy is now based on the smallest prefix you assign to = end users, so if you assign some end-users /64s and some /48s, you have = to justify 65,536 /64s for each of your /48s assigned. OTOH, if you just = give everyone a /48, you can just count up the number of /48s you = assigned and each end user getting a /48 is considered completely legitimate. > Most of ISP used be provided /48 by dhcp-pd and when after RFC3177 = obsoleted, they changed it to /56 and more shorter. I believe you mean and longer. This is an unfortunate change that we can = hopefully reverse before it becomes too entrenched and does too much = harm. > If the policy would be changed ,then operator should understand how = delegated prefix are using. > This is reason of the feature could provide to operators benefit ,I = thought. >=20 There is no policy that prevents assigning /48s. Only a BCP that was = poorly conceived. Owen > Thanks for your feedback. >=20 > Regards, > -Shishio >=20 >=20 >=20 >>=20 >>> So I thought these technologies need small oam tools. >>>=20 >>> -confirm only interface configuration from ISP side >>> -confirm reachability not use end to end >>>=20 >>> I would appreciate any comment. >>>=20 >>> Regards, >>> -Shishio >>=20 >> Cheers, >> Ales >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From victor.kuarsingh@gmail.com Fri Feb 22 10:23: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 6D88421F8648 for ; Fri, 22 Feb 2013 10:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyulvNZQ6sMB for ; Fri, 22 Feb 2013 10:23:25 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 644A321F863F for ; Fri, 22 Feb 2013 10:23:25 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id 15so805363vea.14 for ; Fri, 22 Feb 2013 10:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=APz5qj8k9Icwg57ozioxPUczsjPOykuG/Q/CCiWF11Y=; b=F3ymLvjK1eAFazhd0pAOHJtp8uyz3RcvrfK6aZZfcvebrTRhN3t/jXIILYm6hGmzg5 CW+V2p58oEyfvCYcTU50rtwQRu7Uh21sgaQ95HlKGiibfRMVjYzGtGh/bS08DQtY83zv FnHRnFliagrWWbf8+5jZaiFXlOLPcUt2uamry6y26UsnHIbZRolwSXz4gzIwPgFYcxpp tg3HEtHmGfHftT4E6V3Ra6Su9eGmI1fLSIHQyDkmSeNbShsl8dJn5bUuVNzk7qNOV2m6 H/Ba1gOaa91XoIJkuTQ4Gw7R9ZDoqdEDEMSTWH4S8QwCK2K5d2N21V20SvrkvS5esYLK bA9A== MIME-Version: 1.0 X-Received: by 10.52.26.17 with SMTP id h17mr3374614vdg.101.1361557404768; Fri, 22 Feb 2013 10:23:24 -0800 (PST) Received: by 10.58.69.20 with HTTP; Fri, 22 Feb 2013 10:23:24 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Feb 2013 13:23:24 -0500 Message-ID: From: Victor Kuarsingh To: Philip Matthews Content-Type: multipart/alternative; boundary=20cf307d05687411ba04d6544921 Cc: "v6ops@ietf.org list" Subject: Re: [v6ops] draft-ietf-v6ops-design-choices-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, 22 Feb 2013 18:23:26 -0000 --20cf307d05687411ba04d6544921 Content-Type: text/plain; charset=ISO-8859-1 Mitch, Some Comments
- Additional reasoning for option (b) may be related to limitations in mobile networks (no support for IPv4v6 bearers due to signalling node, UE or gateway limitations). In that case, there are two logical connections (I guess one can argue separate radio resources are used, so you can say physical as well).
- Would it make sense to have the points in the first paragraph (after a, and b options listed) to itemize the supporting points for unnumbered links with bullets? May make is easier for reader to pick out this points. The counter points (support numbered links) is much easier to follow.
- No comment yet. But was thinking about Ralphs draft from 2009 on DHCPv6 use case (which I guess does not technically exist now)
- Also for case B. Some SPs may not use the same physical RRs or have a different RR structure for IPv4 vs. IPv4. This may be related to hardware/software reasons, and/or other factors as they transition. - Option B allows you to retain flexibility to choose a different routing structure for IPv6 (given that it's a different beast - as least in my case it was).
- Not sure if you will agree, but another case for not using LL for peering is related to security as well. Many orgs with well structure ACLs and policy rules built around address ranges used for P2P and LB interfaces. By now mixing that model, they need to make sure they capture/udpate those practices correctly. Not sure if I am making sense on this point. I was also wondering if a new section may be added to discuss how one may deal with or consider modify routing policy for IPv6. Example points of discussion: (1) Perhaps with IPv6, operator may consider chaining how they utilize common Link State protocols vs. BGP for internal routing (given route scale may be different - I.e. Concept of PDs for everyone). (2) For internal routing, on the BGP side, the operator may also choose to select different routing structures (eluded to that in my comment for 2.4) for IPv6. I know that we has considered this to a great deal since we where not trying to solve for some different problems. Just some thoughts based on experience - not sure if anyone will agree here. More comments to come. regards, Victor K On Thu, Feb 14, 2013 at 2:03 PM, Philip Matthews wrote: > Folks: > > I have just submitted draft-ietf-v6ops-design-choices-00, which is a > renamed version of the Design Guidelines draft > (draft-matthews-v6ops-design-guidelines). It should be appearing in the > online drafts repository shortly. > > Though I had hoped to get a more substantial revision out, work intervened > and I was only able to make a few smaller changes. > I have been working on adding more design choices, but ran out of time. > Sorry. > > Comments on the new version are most welcome. > > - Philip > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf307d05687411ba04d6544921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Mitch,


Some=A0Comments


<Section 2.1>

- Additional reasoning for option (b) may be related to lim= itations in mobile networks (no support for IPv4v6 bearers due to signallin= g node, UE or gateway limitations). In that case, there are two logical con= nections (I guess one can argue separate radio resources are used, so you c= an say physical as well).


<Section 2.2>

- Would it make sense to have the points in the first parag= raph (after a, and b options listed) to itemize the supporting points for u= nnumbered links with bullets? May make is easier for reader to pick out thi= s points. The counter points (support numbered links) is much easier to fol= low.


<Section 2.3>

- No comment yet. But was thinking about Ralphs draft from = 2009 on DHCPv6 use case (which I guess does not technically exist now)


<Section 2.4>

- Also for case B. Some SPs may not use the same physical R= Rs or have a different RR structure for IPv4 vs. IPv4. This may be related = to hardware/software reasons, and/or other factors as they transition.

- Option B allows you to retain flexibility to choose a dif= ferent routing structure for IPv6 (given that it's a different beast - = as least in my case it was).


<Section 2.5>

- Not sure if you will agree, but another case for not usin= g LL for peering is related to security as well. Many orgs with well struct= ure ACLs and policy rules built around address ranges used for P2P and LB i= nterfaces. By now mixing that model, they need to make sure they capture/ud= pate those practices correctly. Not sure if I am making sense on this point= .


<New Discussion area>


I was also wondering if a new section may be added to discu= ss how one may deal with or consider modify routing policy for IPv6. =A0Exa= mple points of discussion:


(1) Perhaps with IPv6, operator may consider chaining how t= hey utilize common Link State protocols vs. BGP for internal routing (given= route scale may be different - I.e. Concept of PDs for everyone).

(2) For internal routing, on the BGP side, the operator may= also choose to select different routing structures (eluded to that in my c= omment for 2.4) for IPv6. =A0I know that we has considered this to a great = deal since we where not trying to solve for some different problems.


Just some thoughts based on experience - not sure if anyone= will agree here.



More comments to come.


regards,


Victor K


On Thu, Feb 14, = 2013 at 2:03 PM, Philip Matthews <philip_matthews@magma.ca><= /span> wrote:
Folks:

I have just submitted draft-ietf-v6ops-design-choices-00, which is a rename= d version of the Design Guidelines draft (draft-matthews-v6ops-design-guide= lines). It should be appearing in the online drafts repository shortly.

Though I had hoped to get a more substantial revision out, work intervened = and I was only able to make a few smaller changes.
I have been working on adding more design choices, but ran out of time. Sor= ry.

Comments on the new version are most welcome.

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

--20cf307d05687411ba04d6544921-- From cb.list6@gmail.com Fri Feb 22 11:22: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 C0F5B21F8ABC for ; Fri, 22 Feb 2013 11:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO2lS2MwTgRG for ; Fri, 22 Feb 2013 11:22:04 -0800 (PST) Received: from mail-ye0-f179.google.com (mail-ye0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id BB37F21F8956 for ; Fri, 22 Feb 2013 11:22:02 -0800 (PST) Received: by mail-ye0-f179.google.com with SMTP id m4so181101yen.24 for ; Fri, 22 Feb 2013 11:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=TdrsCSD1U1hoVr3b9i3GYaeU/N9fW488lrSxg5ouKhk=; b=A8UllFJ/pEHR/P5rQmuFIPHQDaaQoUQZhVt+8pTrcGFFuv7nEDlOmnHNXWNPkL735B o7nn3cHeQVgYJr/7BQi5KRcwxsIToK9KjLpfqSwgMKdt4Ku63n/66n+J9k0Dm/bTC4Mx xcgtywLstbUCaHUj/70C3VfLiTEklWMi+bzttENggfUOt1fbvJoei/Zmd/DCYkQwIILw O+l3rR6vKmgbhyWJZxpu+go20xYtV5LANIn/PQfL3e8oIam+SHx9SE5CZ3oN5uqraBgZ ncEBJG30EeVaSQIRaxfeL67IlN3SQL0sif3oZDBr3HS+827opwKb1C6c96spkE6vgfFp nJNQ== MIME-Version: 1.0 X-Received: by 10.100.84.17 with SMTP id h17mr1783960anb.48.1361560921103; Fri, 22 Feb 2013 11:22:01 -0800 (PST) Received: by 10.236.172.233 with HTTP; Fri, 22 Feb 2013 11:22:00 -0800 (PST) In-Reply-To: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> References: <20130220232210.10264.23244.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 11:22:00 -0800 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-03.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: Fri, 22 Feb 2013 19:22:05 -0000 v6ops, I encourage you to have a look at the below draft. We have received a lot of feedback over the last few months since this was presented in Atlanta. I feel the current draft has received enough review and revision to represent something that is pretty close to being mature enough for WGLC. If you have more feedback, please provide it so that we can continue to make progress and understand the WG opinion and the draft's maturity Thanks, Cameron On Wed, Feb 20, 2013 at 3:22 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN > Author(s) : Cameron Byrne > Dan Drown > Ales Vizdal > Filename : draft-ietf-v6ops-64share-03.txt > Pages : 8 > Date : 2013-02-20 > > Abstract: > This document describes three methods for extending an IPv6 /64 > prefix from a User Equipment 3GPP radio interface to a LAN. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Sat Feb 23 02:43: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 D048321F8E03; Sat, 23 Feb 2013 02:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4DmgTrlggvS; Sat, 23 Feb 2013 02:43:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2234921F8F6F; Sat, 23 Feb 2013 02:43:17 -0800 (PST) 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.40 Message-ID: <20130223104317.20351.4269.idtracker@ietfa.amsl.com> Date: Sat, 23 Feb 2013 02:43:17 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-10.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: Sat, 23 Feb 2013 10:43:18 -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 : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-10.txt Pages : 15 Date : 2013-02-23 Abstract: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sm@resistor.net Sat Feb 23 23:44: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 C1ABB21F8FF2; Sat, 23 Feb 2013 23:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiiHg1EE0Q0C; Sat, 23 Feb 2013 23:44:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0921F8FF1; Sat, 23 Feb 2013 23:44:06 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1O7hM7j004864; Sat, 23 Feb 2013 23:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361691810; bh=bHaSNyrKmxDYJTLOcMkzcZ+4JXwTLMDfkKP1H/D7Cpo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wD5LWX9/3vJBvhgB7CY29Gzsc/bbutnodi0T3xVvHtQgsuaOyUswXD2NEjqqy7Cg4 qRS7eKag5ISb3sxlyBOUNVxcqoaMmnOEFQ9c/3g9gdjQ1l43Ctcgv2/WybY5RKbgIY +WqDfh3ZlyUZuWxTolCy1Vr4zqsS6YZdq+Gg3udI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361691810; i=@resistor.net; bh=bHaSNyrKmxDYJTLOcMkzcZ+4JXwTLMDfkKP1H/D7Cpo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OoUANnU9gY55jlkl5IEP6L8YZHkkN/OSfAeEU2SDPp49gq8NKHmvuQhYsICHkUWCc D6P9CVt8oJnt5/BdG+CteVvMbbeOGnqmoegG9v8B/wzNtD4cz4gYqF74faHyn8u5ju 680f7YBOIivQtuwLbmp/FseInHdh/C27LF0sMLm0= Message-Id: <6.2.5.6.2.20130223222210.0ade7d68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 23 Feb 2013 22:31:40 -0800 To: Owen DeLong , Dino Farinacci From: SM In-Reply-To: References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Martin J. Levy" , v6ops@ietf.org, lisp@ietf.org Subject: Re: [v6ops] [lisp] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Feb 2013 07:44:08 -0000 At 17:09 19-02-2013, Owen DeLong wrote: >One of us is misunderstanding the other. My point is that using IPv6 >address space to number things that are not IPv6 hosts is, IMHO, a bad idea. It's not the first time that the idea came up. It's not because there is a seemingly infinite source of integers that they should be assigned to any thing. Regards, -sm From leo.liubing@huawei.com Mon Feb 25 05:15: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 709F321F92F5 for ; Mon, 25 Feb 2013 05:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7TLpgZbcAsc for ; Mon, 25 Feb 2013 05:15:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 75FE821F92F9 for ; Mon, 25 Feb 2013 05:15:20 -0800 (PST) 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 AQA82970; Mon, 25 Feb 2013 13:15:19 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 13:15:17 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 21:15:17 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Mon, 25 Feb 2013 21:15:11 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqQ== Date: Mon, 25 Feb 2013 13:15:11 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DBA22@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Feb 2013 13:15:21 -0000 SGksIGFsbA0KDQpJIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIGRyYWZ0LCBpdCBpcyBhYm91dCBh bmFseXNpcyBhbmQgcmVjb21tZW5kYXRpb25zIG9mIHVzaW5nIFVMQS4NClRoaXMgZG9jdW1lbnQg d2FzIG9uY2UgcHJlc2VudGVkIGluIHY2b3BzIEBpZXRmODIsIEkgZGVsYXllZCB0aGlzIHdvcmsg ZHVlIHRvIHBlcnNvbmFsIGFycmFuZ2VtZW50Lg0KDQpUaGlzIG5ldyB2ZXJzaW9uIGNoYW5nZXMg bm90IGEgZmV3IGluY2x1ZGluZyB0aGUgdGl0bGUsIGFjY29yZGluZyB0byB0aGUgY29tbWVudHMg cmVjZWl2ZWQgaW4gdGhlIG1lZXRpbmcgYW5kIHRoZSBtYWlsaW5nIGxpc3QuDQpUaGUgZHJhZnQg aXMgdG8gc3VwcGxlbWVudCB0aGUgVUxBIGRlZmluaXRpb24gW1JGQzQxOTNdLCBzaW5jZSB0aGVy ZSBhcmUgcGVvcGxlIGNvbmZ1c2luZyBhYm91dCB1c2luZyBVTEEuIFRoZSBwdXJwb3NlcyBvZiB0 aGUgZHJhZnQgYXJlOg0KLSBkaXNjdXNzaW5nIHNjZW5hcmlvcywgcHJvdmlkaW5nIGd1aWRlIG9m IHdoZXJlIHRvIGJlbmVmaWNpYWxseSB1c2luZyBVTEEsIGxldCBtb3JlIHBlb3BsZSBrbm93IFVM QSBpcyBhIHVzZWZ1bCB0b29sIGluIHNvbWUgY2FzZXMNCi0gZWxpbWluYXRpbmcgdGhlIG1pc3Vu ZGVyc3RhbmRpbmcgb2YgdHJlYXRpbmcgVUxBIGVxdWFscyB0byBJUHY2IHZlcnNpb24gb2YgW1JG QzE5MThdIChQcml2YXRlIElQdjQgYWRkcmVzcyBzcGFjZSkgDQoNClBsZWFzZSByZWFkIHRoZSBk cmFmdCBhbmQgY29tbWVudC4gDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMtMDUudHh0 DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bGl1LXY2b3BzLXVsYS11c2FnZS1hbmFseXNpcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzLTA1DQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxp dS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMtMDVNYW55IHRoYW5rcyENCg0KQWxsIHRoZSBiZXN0 LA0KQmluZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMjUsIDIwMTMgODo0NyBQTQ0KVG86IExpdWJpbmcgKExlbykNCkNjOiBj YW1lcm9uLmJ5cm5lQHQtbW9iaWxlLmNvbTsgU2hlbmcgSmlhbmcNClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LXY2b3BzLXVsYS11c2FnZS1hbmFseXNpcy0w NS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LXY2b3BzLXVsYS11c2Fn ZS1hbmFseXNpcy0wNS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmlu ZyBMaXUgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzDQpSZXZpc2lvbjoJIDA1DQpUaXRsZToJ CSBHdWlkYW5jZSBvZiBVc2luZyBVbmlxdWUgTG9jYWwgQWRkcmVzc2VzDQpDcmVhdGlvbiBkYXRl OgkgMjAxMy0wMi0yNQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDEwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWxpdS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMtMDUudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXY2b3Bz LXVsYS11c2FnZS1hbmFseXNpcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzLTA1DQpEaWZmOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpdS12Nm9wcy11 bGEtdXNhZ2UtYW5hbHlzaXMtMDUNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByb3Zp ZGVzIGd1aWRhbmNlIG9mIGhvdyB0byB1c2UgVUxBLiBJdCBhbmFseXplcyBVTEENCiAgIHVzYWdl IHNjZW5hcmlvcyBhbmQgcmVjb21tZW5kcyB1c2UgY2FzZXMgd2hlcmUgVUxBIGFkZHJlc3MgbWF5 IGJlDQogICBiZW5lZmljaWFsbHkgdXNlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From victor.kuarsingh@gmail.com Mon Feb 25 05:29: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 C7FEF21F92FE for ; Mon, 25 Feb 2013 05:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.181 X-Spam-Level: X-Spam-Status: No, score=-0.181 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5KbiGDT0l0K for ; Mon, 25 Feb 2013 05:29:32 -0800 (PST) Received: from mail-ie0-x236.google.com (ie-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 357C021F92F8 for ; Mon, 25 Feb 2013 05:29:32 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so3035685iea.41 for ; Mon, 25 Feb 2013 05:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=wyk/weJ7QWY0NRVSOfaKSC+CSbXFkTDbX7fyJowAdQM=; b=JZKxmTx8DqlV2VjOnBcipofw1B52sbjxJEdPOjW1zBOqU5ePHiEfwljucbX0QkN/DY UA1/FBl04MuCk44Sw2bOVEs4hV5xqJExm5W1NHGmRtm+eNWsvOE7+AkE4f+BuF/EdtrG UxcUAxwOHDDBDuBZUYcQXm0D1cedVWwt/oUq0c5RFnuWa9EvLD0rrZs+Ay15ikLWws48 gpXHiotF8dBeG0+HnzW2p8GmTtCM+QBlW3DQjlBucW0lr9wcX5ujFPSR60+2nabQFbwR yiHKOJCbwSZK8fnm9KTExCbVpPbPmdVQHcPeixu8GhL5BKhVlnlGZ0EnbfBvqTfyNIDS quNA== X-Received: by 10.50.208.40 with SMTP id mb8mr3446413igc.91.1361798971856; Mon, 25 Feb 2013 05:29:31 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id xc3sm3859993igb.10.2013.02.25.05.29.29 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 25 Feb 2013 05:29:31 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 25 Feb 2013 08:29:27 -0500 From: Victor Kuarsingh To: "Liubing (Leo)" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DBA22@nkgeml506-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Feb 2013 13:29:32 -0000 Liubing, I agree in general with this type of draft/document. ULAs have caused quite a bit of confusion from what I have seen and many folks are hesitant to use them for valid parts of they deployment. I think a draft which provides useful guidance as to how they can be used is very useful. I need to however do a more thorough read through for better comments/feedback, but here is all I have for now. - the point in section 2.2.2.1 regarding the notion that ULA != RFC1918 should be moved, or also made in the introduction. I think this is an important point. Regards, Victor Kuarsingh On 2013-02-25 8:15 AM, "Liubing (Leo)" wrote: >Hi, all > >I submitted a new version draft, it is about analysis and recommendations >of using ULA. >This document was once presented in v6ops @ietf82, I delayed this work >due to personal arrangement. > >This new version changes not a few including the title, according to the >comments received in the meeting and the mailing list. >The draft is to supplement the ULA definition [RFC4193], since there are >people confusing about using ULA. The purposes of the draft are: >- discussing scenarios, providing guide of where to beneficially using >ULA, let more people know ULA is a useful tool in some cases >- eliminating the misunderstanding of treating ULA equals to IPv6 version >of [RFC1918] (Private IPv4 address space) > >Please read the draft and comment. >URL: >http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-05. >txt >Status: >http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >Htmlized: >http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-ula-usage-analysis-05Many > thanks! > >All the best, >Bing > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, February 25, 2013 8:47 PM >To: Liubing (Leo) >Cc: cameron.byrne@t-mobile.com; Sheng Jiang >Subject: New Version Notification for >draft-liu-v6ops-ula-usage-analysis-05.txt > > >A new version of I-D, draft-liu-v6ops-ula-usage-analysis-05.txt >has been successfully submitted by Bing Liu and posted to the >IETF repository. > >Filename: draft-liu-v6ops-ula-usage-analysis >Revision: 05 >Title: Guidance of Using Unique Local Addresses >Creation date: 2013-02-25 >Group: Individual Submission >Number of pages: 10 >URL: >http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-05. >txt >Status: >http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >Htmlized: >http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-ula-usage-analysis-05 > >Abstract: > This document provides guidance of how to use ULA. It analyzes ULA > usage scenarios and recommends use cases where ULA address may be > beneficially used. > > > > > >The IETF Secretariat > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From arturo.servin@gmail.com Mon Feb 25 05:58: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 CEAEE21F9239 for ; Mon, 25 Feb 2013 05:58:01 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKtCRXvBPdYJ for ; Mon, 25 Feb 2013 05:58:01 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5ED21F922C for ; Mon, 25 Feb 2013 05:58:01 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fb1so1761305pad.11 for ; Mon, 25 Feb 2013 05:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bR5ETUh6uWDWU9g+wrLjX/PMKGZ4SXmINz5hFzdyWr8=; b=N1cu+GWHLQp0l2g6+AfPW9eD0KO2GjQqjA2C6iQ8Qcyqh4oQc9kTYlvSpM98V7/HVT zUlj6TQbcJwFac3mTy2czSs4dOCT+aVneEZkOE+9yGg6QfyHrnTcWgwwwdhVBssakBua 1qN1p7kvuVsCxc6YVj1F2JXC0mPENvgyyxXO/EbA1N/b5nbk8W5uBXYgauPRxr+M6bQf 8Vw7W4F3bBn0YK4HCz8ZPlU+7hC6cxl6sZHsDWPrSCsz23eNOAiMUl5c9FxsbtEPdE5F VNbptN4PbWbUdCDLmXqhcEwHSl/Hzg/sBqsSd3vQ85yVohOFYFzV7Dq11C3xR9bQfE3B hGyw== X-Received: by 10.68.137.161 with SMTP id qj1mr18273309pbb.168.1361800681259; Mon, 25 Feb 2013 05:58:01 -0800 (PST) Received: from MiniR2D2.local ([203.126.139.254]) by mx.google.com with ESMTPS id k7sm13827621paz.13.2013.02.25.05.57.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 05:57:59 -0800 (PST) Message-ID: <512B6DE4.50201@gmail.com> Date: Mon, 25 Feb 2013 21:57:56 +0800 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Feb 2013 13:58:01 -0000 +1 I apologize though. I haven't read this version of the draft (I did the previous one and I was not very convinced) but I support to make emphasis in this. On 25/02/2013 21:29, Victor Kuarsingh wrote: > - the point in section 2.2.2.1 regarding the notion that ULA != RFC1918 > should be moved, or also made in the introduction. I think this is an > important point. /as From internet-drafts@ietf.org Mon Feb 25 06:05:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FBD21F92E6; Mon, 25 Feb 2013 06:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ludIMn+vz-A2; Mon, 25 Feb 2013 06:05:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ECE21F930C; Mon, 25 Feb 2013 06:05:10 -0800 (PST) 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.40 Message-ID: <20130225140510.30575.52772.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 06:05:10 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-01.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: Mon, 25 Feb 2013 14:05:11 -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 for 3GPP Cellular Hosts Author(s) : Jouni Korhonen Jari Arkko Teemu Savolainen Suresh Krishnan Filename : draft-ietf-v6ops-rfc3316bis-01.txt Pages : 18 Date : 2013-02-25 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 are making 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 functionality that needs to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues relating to the use of these components when operating in these networks. This document obsoletes RFC 3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From swmike@swm.pp.se Mon Feb 25 06:24: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 2392F21F9325 for ; Mon, 25 Feb 2013 06:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhK13rMziu4N for ; Mon, 25 Feb 2013 06:24:08 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DB75421F9337 for ; Mon, 25 Feb 2013 06:24:06 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A1A6F9C; Mon, 25 Feb 2013 15:24:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 93DB19A for ; Mon, 25 Feb 2013 15:24:05 +0100 (CET) Date: Mon, 25 Feb 2013 15:24:05 +0100 (CET) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: <20130225140510.30575.52772.idtracker@ietfa.amsl.com> Message-ID: References: <20130225140510.30575.52772.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-01.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: Mon, 25 Feb 2013 14:24:09 -0000 On Mon, 25 Feb 2013, internet-drafts@ietf.org wrote: > Requirements document. It also discusses some issues relating to the > use of these components when operating in these networks. This > document obsoletes RFC 3316. Would it make sense to discuss the bearer concept regarding IPv4, IPv6 and IPv4v6 in this document? Personally I'd like to see all new devices actually support IPv4, IPv6 (two PDP contexts if one wants dual stack) and IPv4v6 (single dual stack PDP context). -- Mikael Abrahamsson email: swmike@swm.pp.se From tsavo.stds@gmail.com Mon Feb 25 08:46: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 7E1FE21F9521 for ; Mon, 25 Feb 2013 08:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.574 X-Spam-Level: X-Spam-Status: No, score=0.574 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD1RXYWiMV0O for ; Mon, 25 Feb 2013 08:46:15 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id EB36A21F94ED for ; Mon, 25 Feb 2013 08:46:10 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fr10so2916087lab.12 for ; Mon, 25 Feb 2013 08:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:mime-version:to:from:subject:date :content-type; bh=SJA+5MobDu/+/I+5Dn4XJ7JMqXgl0RKwht+keRgZrqs=; b=LjSS+CwCzvAYNa1TOmuoOCT4hytvh6yOUrFx3R3PQ/JLtp7nMIn227hNLxEkCSXTBO e/HcvUYlo7leQI0XB+4BVuJ/fkFOk7HflLC9c09S2D7FpXRUM1mAuw4A1KMNVYwLFH6c IuCnrxfAvA1cqjF7tksroE0+JG7v1Y8f6k4zqwzQVBkBJ1gpaEnBzWk/ysr2DsRGO/WO /ijJVANVKZaAUa5ACwpubi+5CO4SAWYFIgED3BkZCWLI9disDRt5RWeRsSXthA3ZNpH/ rk6dDfKtHvuhXbQ5WAZuw36CYhJV/0ZnrM384UFA4cULFhdnnT/Rs+0WRqfaIApCpW2U Hk0A== X-Received: by 10.152.148.133 with SMTP id ts5mr10617673lab.2.1361810769397; Mon, 25 Feb 2013 08:46:09 -0800 (PST) Received: from [85.156.193.232] (85-156-193-232.elisa-mobile.fi. [85.156.193.232]) by mx.google.com with ESMTPS id fm8sm4329499lbb.17.2013.02.25.08.46.08 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 25 Feb 2013 08:46:08 -0800 (PST) Message-ID: <512b9550.4866700a.0e79.fffff6d6@mx.google.com> MIME-Version: 1.0 To: Mikael Abrahamsson , "v6ops@ietf.org" From: Teemu Savolainen Date: Mon, 25 Feb 2013 18:45:43 +0200 Content-Type: multipart/alternative; boundary="_853ED68E-D981-4D10-820B-711DC36703FC_" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-01.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: Mon, 25 Feb 2013 16:46:15 -0000 --_853ED68E-D981-4D10-820B-711DC36703FC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" RFC6459 should cover the bearer concept part? -----Original Message----- From: "Mikael Abrahamsson" Sent: =E2=80=8E25.=E2=80=8E2.=E2=80=8E2013 16:24 To: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-01.txt On Mon, 25 Feb 2013, internet-drafts@ietf.org wrote: > Requirements document. It also discusses some issues relating to the > use of these components when operating in these networks. This > document obsoletes RFC 3316. Would it make sense to discuss the bearer concept regarding IPv4, IPv6 and= =20 IPv4v6 in this document? Personally I'd like to see all new devices actually support IPv4, IPv6=20 (two PDP contexts if one wants dual stack) and IPv4v6 (single dual stack=20 PDP context). --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_853ED68E-D981-4D10-820B-711DC36703FC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
RFC6459 sho= uld cover the bearer concept part?
From: Mikael Abrahamsson
Sent: =E2=80=8E25.=E2=80=8E2.=E2=80=8E2013 16:24
To: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-01.txt<= BR>
On Mon, 25 Feb 2013, internet-drafts@ietf.org wrote:

&g= t;   Requirements document.  It also discusses some issues r= elating to the
>   use of these components when operating i= n these networks.  This
>   document obsoletes RFC 331= 6.

Would it make sense to discuss the bearer concept regarding IPv4,= IPv6 and
IPv4v6 in this document?

Personally I'd like to see al= l new devices actually support IPv4, IPv6
(two PDP contexts if one want= s dual stack) and IPv4v6 (single dual stack
PDP context).

-- Mikael Abrahamsson    email: swmike@swm.pp.se
__________= _____________________________________
v6ops mailing list
v6ops@ietf.o= rg
https://www.ietf.org/mailman/listinfo/v6ops
= --_853ED68E-D981-4D10-820B-711DC36703FC_-- From internet-drafts@ietf.org Mon Feb 25 13:34: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 3939821E80E5; Mon, 25 Feb 2013 13:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P96hniNY8zjv; Mon, 25 Feb 2013 13:34:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6062D21E80D4; Mon, 25 Feb 2013 13:34:22 -0800 (PST) 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.40 Message-ID: <20130225213422.21043.79291.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:34:22 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-02.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: Mon, 25 Feb 2013 21:34:23 -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 : Enterprise IPv6 Deployment Guidelines Author(s) : Kiran K. Chittimaneni Tim Chown Lee Howard Victor Kuarsingh Yanick Pouffary Eric Vyncke Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-02.txt Pages : 34 Date : 2013-02-25 Abstract: Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and potentially an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ip= v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incremental-= ipv6-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leo.liubing@huawei.com Mon Feb 25 17:36: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 E097F1F0D10 for ; Mon, 25 Feb 2013 17:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4-6KuqU2FQi for ; Mon, 25 Feb 2013 17:36:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DFED11F0D0F for ; Mon, 25 Feb 2013 17:36:34 -0800 (PST) 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 AQB22138; Tue, 26 Feb 2013 01:36:34 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 01:36:30 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 01:36:24 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 09:36:18 +0800 From: "Liubing (Leo)" To: Victor Kuarsingh , "v6ops@ietf.org" Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiKC3OAgAFOPdA= Date: Tue, 26 Feb 2013 01:36:17 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DBD2C@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DBA22@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 01:36:37 -0000 Hi, Victor Thanks for your support and the suggestion, I'll do it in the next version. B.R. Bing > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] > Sent: Monday, February 25, 2013 9:29 PM > To: Liubing (Leo); v6ops@ietf.org > Subject: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 > Liubing, >=20 > I agree in general with this type of draft/document. ULAs have caused > quite a bit of confusion from what I have seen and many folks are hesitan= t > to use them for valid parts of they deployment. >=20 > I think a draft which provides useful guidance as to how they can be used > is very useful. I need to however do a more thorough read through for > better comments/feedback, but here is all I have for now. >=20 >=20 > - the point in section 2.2.2.1 regarding the notion that ULA !=3D RFC1918 > should be moved, or also made in the introduction. I think this is an > important point. >=20 >=20 >=20 > Regards, >=20 > Victor Kuarsingh >=20 > On 2013-02-25 8:15 AM, "Liubing (Leo)" wrote: >=20 > >Hi, all > > > >I submitted a new version draft, it is about analysis and recommendation= s > >of using ULA. > >This document was once presented in v6ops @ietf82, I delayed this work > >due to personal arrangement. > > > >This new version changes not a few including the title, according to the > >comments received in the meeting and the mailing list. > >The draft is to supplement the ULA definition [RFC4193], since there are > >people confusing about using ULA. The purposes of the draft are: > >- discussing scenarios, providing guide of where to beneficially using > >ULA, let more people know ULA is a useful tool in some cases > >- eliminating the misunderstanding of treating ULA equals to IPv6 versio= n > >of [RFC1918] (Private IPv4 address space) > > > >Please read the draft and comment. > >URL: > >http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-0= 5. > >txt > >Status: > >http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > >Htmlized: > >http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05 > >Diff: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-v6ops-ula-usage-analysis-05= Man > y > > thanks! > > > >All the best, > >Bing > > > >-----Original Message----- > >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >Sent: Monday, February 25, 2013 8:47 PM > >To: Liubing (Leo) > >Cc: cameron.byrne@t-mobile.com; Sheng Jiang > >Subject: New Version Notification for > >draft-liu-v6ops-ula-usage-analysis-05.txt > > > > > >A new version of I-D, draft-liu-v6ops-ula-usage-analysis-05.txt > >has been successfully submitted by Bing Liu and posted to the > >IETF repository. > > > >Filename: draft-liu-v6ops-ula-usage-analysis > >Revision: 05 > >Title: Guidance of Using Unique Local Addresses > >Creation date: 2013-02-25 > >Group: Individual Submission > >Number of pages: 10 > >URL: > >http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-0= 5. > >txt > >Status: > >http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > >Htmlized: > >http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05 > >Diff: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-v6ops-ula-usage-analysis-05 > > > >Abstract: > > This document provides guidance of how to use ULA. It analyzes ULA > > usage scenarios and recommends use cases where ULA address may be > > beneficially used. > > > > > > > > > > > >The IETF Secretariat > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops >=20 From leo.liubing@huawei.com Mon Feb 25 17:56: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 7BDCB21E8127 for ; Mon, 25 Feb 2013 17:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR12t1uCya15 for ; Mon, 25 Feb 2013 17:56:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1C121E80E7 for ; Mon, 25 Feb 2013 17:56:57 -0800 (PST) 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 AQB23047; Tue, 26 Feb 2013 01:56:56 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 01:56:53 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 01:56:55 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 09:56:51 +0800 From: "Liubing (Leo)" To: Arturo Servin , "v6ops@ietf.org" Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiKC3OAgAAH9QCAAUo+EA== Date: Tue, 26 Feb 2013 01:56:50 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DBD4B@nkgeml506-mbx.china.huawei.com> References: <512B6DE4.50201@gmail.com> In-Reply-To: <512B6DE4.50201@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 01:56:58 -0000 Hi, Arturo This version took in some valuable comments, key points are: - clearly state ULA!=3DRFC1918 - make clear recommendations of where to beneficially used Your review and comments would be appreciated very much. B.R. Bing > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Arturo Servin > Sent: Monday, February 25, 2013 9:58 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 >=20 > +1 >=20 > I apologize though. I haven't read this version of the draft (I did the > previous one and I was not very convinced) but I support to make > emphasis in this. >=20 > On 25/02/2013 21:29, Victor Kuarsingh wrote: > > - the point in section 2.2.2.1 regarding the notion that ULA !=3D RFC19= 18 > > should be moved, or also made in the introduction. I think this is an > > important point. >=20 > /as > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From leo.liubing@huawei.com Mon Feb 25 17:59: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 8B02D21E8148 for ; Mon, 25 Feb 2013 17:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RBkCkHmNeRv for ; Mon, 25 Feb 2013 17:59:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35B21E812C for ; Mon, 25 Feb 2013 17:59:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOU24452; Tue, 26 Feb 2013 01:59:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 01:58:18 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 09:59:10 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 09:59:05 +0800 From: "Liubing (Leo)" To: Mark Andrews Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiLBJT0gABeIkA= Date: Tue, 26 Feb 2013 01:59:04 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DBD58@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DBA22@nkgeml506-mbx.china.huawei.com> <20130225202051.402F7300AC90@drugs.dv.isc.org> In-Reply-To: <20130225202051.402F7300AC90@drugs.dv.isc.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 01:59:18 -0000 Hi, Mark Thanks for the correction. Will do in the next version. B.R. Bing > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Tuesday, February 26, 2013 4:21 AM > To: Liubing (Leo) > Subject: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 >=20 > Old: > ULA is a useful tool, it have been successfully deployed in a diverse >=20 > New: > ULA is a useful tool, it has been successfully deployed in a diverse >=20 > -- > 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 Feb 25 22: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 9A2CB21F95DD for ; Mon, 25 Feb 2013 22:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6mmMDTk5mED for ; Mon, 25 Feb 2013 22:35:07 -0800 (PST) Received: from mail-ie0-x22b.google.com (ie-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1DA21F95DC for ; Mon, 25 Feb 2013 22:35:06 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 10so4084726ied.2 for ; Mon, 25 Feb 2013 22:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KeK+kO8erAg75dGDSx7NiHlQB73M5npvAWsb2mIq3C0=; b=VJ6nWetyYxGQd2M6WfNTuNDx1bNJ2XP19S+OAAgWueGxivKxw4hpiNP1AOodbjMtga zxzqZkrNCH9Ec1l7eFAyySICyUYxoIOYutpykCLirxx6Ng04MeOx2502HBUdZvHzu9rn puef6KAT4ML8FuUTGlBA5aZNPjbPe/m+e7qkosoOVe/GWxhiTy3+K0+DmPdv8Dm8kE8n 7HAfCT41qM5ni3n4bq1Nyfa9mBVo3Dw36vHjmgTidSm4rDvQRPVp+yk6hur6V6HULS5t Xreb5MYTqWhtEm72RebanxT7K1LaLOWUexOQbXXDBLgUoTYcvc8/p5KcKCBEj/pIhtVB IvBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=KeK+kO8erAg75dGDSx7NiHlQB73M5npvAWsb2mIq3C0=; b=O2pA+KteDX7uLl9gHSRkf9qMiCUIDMfGLpyTbJdywa0i6QVmKBSfXYvrmhBrT+B0pi FIY73ceROgQkN65WvPKyaH5kAekhC12/nvzI5f6uJESfGQ3saIecpu8Iiw9aghl1mOzm ajRG9xUFUbXtDGAEdXbXKHRTQ9IS9LReMa2V0JOvNV6P5dITqJ3b8k00POP+uHxxg9PU E8v1Rlzn+acH4W5br9FmNGK3MYVhaeR/R2rZNEtKWx3JfBpAuBLoG8MOivZhM4ujXi1r L/mhPEj+wTKznmKeZ/U+LmVb+o9Bbeg+BMdgcFa0dEkSr9wsNFA2VFw30v8/yZHNW21W FD+Q== X-Received: by 10.43.118.2 with SMTP id fo2mr1398131icc.41.1361860506515; Mon, 25 Feb 2013 22:35:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.158.73 with HTTP; Mon, 25 Feb 2013 22:34:46 -0800 (PST) In-Reply-To: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> From: Lorenzo Colitti Date: Tue, 26 Feb 2013 15:34:46 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=bcaec517c8acb9a81b04d69adb2b X-Gm-Message-State: ALoCoQkYSZbCnteVCD+q6YqEpR6hehK6V4K2aNVrkoBneVZ2MBAPwP8sszObXmgR6MHatd1fWoGtMciOqhGUiFvq7bazbJE1EgaTxxkU2eUI83/BjGBsijcJcqwihcucewbpg2Vh7i30fTTl/eWKORnQbfeDdzgTnqDwWQzqvh+mUpkJMxjTaT7qWmd7VEwULHo5FJyMVyAu Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 06:35:07 -0000 --bcaec517c8acb9a81b04d69adb2b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 6:27 PM, Owen DeLong wrote: > > RFC6177 was published as BCP. > > http://tools.ietf.org/html/rfc6177 > > > > True. I wasn't participating actively in IETF at the time 6177 was > written. IMHO, it is a travesty of v4 thinking being brought forward into > IPv6 and should be considered harmful rather than BCP. It is neither > common, nor best practice in my experience so far in the IPv6 world. > You may disagree that it is best, but unfortunately, it IS common. The largest IPv6 deployments in the world assign smaller than /48 blocks by default. Examples: AT&T /60, free.fr /60, Verizon Wireless /64 (though to be fair, it's not their fault - 3GPP doesn't support DHCPv6 PD), Comcast /64 (unless they've changed their default recently), NTT Japan /56 or /64, and so on. In fact, I'm not aware of any major residential ISP (not a tunnel broker) that actually assigns /48s. Are you? --bcaec517c8acb9a81b04d69adb2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 6:27 PM, Owen DeLong <owen@delong.c= om> wrote:
> RFC6177 was published as BCP.
> http:= //tools.ietf.org/html/rfc6177
>

True. I wasn't participating actively in IETF at the time 6177 wa= s written. IMHO, it is a travesty of v4 thinking being brought forward into= IPv6 and should be considered harmful rather than BCP. It is neither commo= n, nor best practice in my experience so far in the IPv6 world.

You may disagree that it is best, bu= t unfortunately, it IS common. The largest IPv6 deployments in the world as= sign smaller than /48 blocks by default.

Examples: AT&T /60, free.fr /60, Verizon= Wireless /64 (though to be fair, it's not their fault - 3GPP doesn'= ;t support DHCPv6 PD), Comcast /64 (unless they've changed their defaul= t recently), NTT Japan /56 or /64, and so on.

In fact, I'm not aware of any major res= idential ISP (not a tunnel broker) that actually assigns /48s. Are you?
--bcaec517c8acb9a81b04d69adb2b-- From leo.liubing@huawei.com Mon Feb 25 23:14: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 0C46621F9668; Mon, 25 Feb 2013 23:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JcVsdbBpbf1; Mon, 25 Feb 2013 23:14:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1169E21F960B; Mon, 25 Feb 2013 23:14:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQB42294; Tue, 26 Feb 2013 07:14:31 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 07:13:38 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 07:14:30 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 15:14:27 +0800 From: "Liubing (Leo)" To: "ipv6@ietf.org" , "v6ops@ietf.org" Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cA== Date: Tue, 26 Feb 2013 07:14:27 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> In-Reply-To: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "renum@ietf.org" Subject: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 07:14:44 -0000 SGksIDZtYW4gJiB2Nm9wcw0KDQpXZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyB0 aGUgU0xBQUMvREhDUHY2IGludGVyYWN0aW9uIGdhcHMuDQoNCkFzIHdlIGtub3cgdGhlcmUgYXJl IHNldmVyYWwgZmxhZ3MgaW4gUkEgbWVzc2FnZXMgcmVnYXJkaW5nIHdpdGggdGhlIGhvc3QgY29u ZmlndXJhdGlvbiBiZWhhdmlvciwgd2hpY2ggYXJlIEEgKEF1dG9ub21vdXMpIGZsYWcsIE0gKE1h bmFnZWQpIGZsYWcsIGFuZCBPIChPdGhlcmNvbmZpZykgZmxhZy4NCkZvciBzb21lIHJlYXNvbiwg dGhlIGhvc3QgYmVoYXZpb3Igb2YgaW50ZXJwcmV0aW5nIHRoZSBmbGFncyBpcyBhbWJpZ3VvdXMg aW4gdGhlIHN0YW5kYXJkIChtYWlubHkgUkZDNDg2MikuIEkgcHJlc2VudGVkIGEgZHJhZnQgZGlz Y3Vzc2luZyBNIGZsYWcgYmVoYXZpb3IgaW4gNm1hbiBAaWV0Zjg0LCBhbmQgdGhlcmUgd2VyZSBz b21lIGZlZWRiYWNrcyBhcmd1aW5nIHRoZSBzYW1lIGlzc3VlLiBUaGlzIGRyYWZ0IGFuYWx5emVk IGFsbCB0aGUgdGhyZWUgZmxhZ3MsIGFuZCBwcm92aWRlZCB0ZXN0IHJlc3VsdCBvZiBjdXJyZW50 IGltcGxlbWVudGF0aW9ucywgaXQgc2hvd2VkIHRoZSBiZWhhdmlvciBvZiBkaWZmZXJlbnQgbWFp bnN0cmVhbSBkZXNrdG9wIE9TZXMgaGF2ZSB2YXJpZWQuIFRoZSBhbWJpZ3VvdXMgYW5kIHZhcmlh dGlvbiBtaWdodCBjYXVzZSBvcGVyYXRpb25hbCBwcm9ibGVtcywgc3VjaCBhcyByZW51bWJlcmlu ZyAodXNlZCB0byBkaXNjdXNzIGluIDZyZW51bSBXRyBhbmQgYmVlbiBkb2N1bWVudGVkIGluIHRo ZSBXRyBkcmFmdHMpLCBjb2xkIHN0YXJ0IHByb2JsZW0sIGFuZCBtYW5hZ2VtZW50IGdhcHMgLmV0 Yy4NCg0KWW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIGFwcHJlY2lhdGVkIHZlcnkg bXVjaC4gDQoNCkFsbCB0aGUgYmVzdCwNCkJpbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjUsIDIwMTMgNTo1MiBQ TQ0KPiBUbzogTGl1YmluZyAoTGVvKQ0KPiBDYzogcmJvbmljYUBqdW5pcGVyLm5ldA0KPiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LWxpdS1ib25pY2EtZGhj cHY2LXNsYWFjLXByb2JsZW0tMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDEudHh0DQo+IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmluZyBMaXUgYW5kIHBvc3RlZCB0byB0aGUNCj4g SUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC1saXUtYm9uaWNhLWRoY3B2 Ni1zbGFhYy1wcm9ibGVtDQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkgREhDUHY2L1NMQUFD IEFkZHJlc3MgQ29uZmlndXJhdGlvbiBJbnRlcmFjdGlvbiBQcm9ibGVtDQo+IFN0YXRlbWVudA0K PiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0yNQ0KPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAxMg0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1ib25pY2EtZGhjcHY2LXNsYWFjLXByb2JsZW0t DQo+IDAxLnR4dA0KPiBTdGF0dXM6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPiBIdG1saXplZDoNCj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWJvbmljYS1kaGNwdjYtc2xhYWMtcHJv YmxlbS0wMQ0KPiBEaWZmOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1saXUtYm9uaWNhLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4g ICAgVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgaG9zdCBiZWhhdmlvciBvZiBESENQdjYvU0xB QUMgaW50ZXJhY3Rpb24NCj4gICAgaXNzdWUuIEl0IHJldmlld3MgdGhlIHN0YW5kYXJkIGRlZmlu aXRpb24gb2YgdGhlIGhvc3QgYmVoYXZpb3JzIGFuZA0KPiAgICBwcm92aWRlcyB0aGUgdGVzdCBy ZXN1bHRzIG9mIGN1cnJlbnQgbWFpbnN0cmVhbSBpbXBsZW1lbnRhdGlvbnMuIFNvbWUNCj4gICAg cG90ZW50aWFsIG9wZXJhdGlvbmFsIGdhcHMgb2YgdGhlIGludGVyYWN0aW9uIGFyZSBhbHNvIGRl c2NyaWJlZC4NCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From leo.liubing@huawei.com Tue Feb 26 01: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 E1B1621F86BA; Tue, 26 Feb 2013 01:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVmwubHw7B1E; Tue, 26 Feb 2013 01:53:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 452D821F891D; Tue, 26 Feb 2013 01:53:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOU58190; Tue, 26 Feb 2013 09:53:11 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 09:52:17 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 09:53:10 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 17:53:03 +0800 From: "Liubing (Leo)" To: Arturo Servin , "ipv6@ietf.org" Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiLWU8AgACLyDA= Date: Tue, 26 Feb 2013 09:53:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC132@nkgeml506-mbx.china.huawei.com> References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <512C8044.3050103@gmail.com> In-Reply-To: <512C8044.3050103@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 09:53:17 -0000 Hi, Arturo and all That was my mistake. I derived this draft from a template and forgot to cha= nge it.=20 It should be "Informational", thanks for finding this bug. B.R. Bing > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Arturo Servin > Sent: Tuesday, February 26, 2013 5:29 PM > To: ipv6@ietf.org > Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps >=20 > Dear authors, >=20 > Very interesting document and very valuable to document the current > behavior of the A, M and O flags (that have caused some headaches to > some including myself when troubleshooting IPv6). >=20 > I see that has been submitted as "Proposed Standard" but I failed to > find what you are proposing. >=20 > Would it better to be submitted as "Informational" and then look how > to > indicate the correct behavior of the flags? or just as "Informational"? >=20 > Regards. > as >=20 >=20 > On 26/02/2013 15:14, Liubing (Leo) wrote: > > Hi, 6man & v6ops > > > > We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. > > > > As we know there are several flags in RA messages regarding with the ho= st > configuration behavior, which are A (Autonomous) flag, M (Managed) flag, > and O (Otherconfig) flag. > > For some reason, the host behavior of interpreting the flags is ambiguo= us > in the standard (mainly RFC4862). I presented a draft discussing M flag > behavior in 6man @ietf84, and there were some feedbacks arguing the same > issue. This draft analyzed all the three flags, and provided test result = of > current implementations, it showed the behavior of different mainstream > desktop OSes have varied. The ambiguous and variation might cause > operational problems, such as renumbering (used to discuss in 6renum WG > and been documented in the WG drafts), cold start problem, and > management gaps .etc. > > > > Your review and comments would be appreciated very much. > > > > All the best, > > Bing > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, February 25, 2013 5:52 PM > >> To: Liubing (Leo) > >> Cc: rbonica@juniper.net > >> Subject: New Version Notification for > >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt > >> > >> > >> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt > >> has been successfully submitted by Bing Liu and posted to the > >> IETF repository. > >> > >> Filename: draft-liu-bonica-dhcpv6-slaac-problem > >> Revision: 01 > >> Title: DHCPv6/SLAAC Address Configuration Interaction Problem > >> Statement > >> Creation date: 2013-02-25 > >> Group: Individual Submission > >> Number of pages: 12 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem= - > >> 01.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem > >> Htmlized: > >> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 > >> Diff: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-problem-= 01 > >> > >> Abstract: > >> This document analyzes the host behavior of DHCPv6/SLAAC > interaction > >> issue. It reviews the standard definition of the host behaviors and > >> provides the test results of current mainstream implementations. > Some > >> potential operational gaps of the interaction are also described. > >> > >> > >> > >> > >> The IETF Secretariat > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From arturo.servin@gmail.com Tue Feb 26 02:09: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 3BFF521F89AA; Tue, 26 Feb 2013 02:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGDqvZ9jKZp0; Tue, 26 Feb 2013 02:09:58 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 73F0621F899E; Tue, 26 Feb 2013 02:09:58 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so1951888dal.29 for ; Tue, 26 Feb 2013 02:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BF8Ubp62vq3Nck9h01k6J/XGabaaDnx9AT4AHgeTbG0=; b=xqx8F6+/xfUnLGPo9V0rVSCHJOHmc5VwMP1XxrhSgVyM9FxxJ6sgKMr9c5jOL+r31a 8RaZhCIh78O8h7sgM0SHyr7ZSpODagYThhWrY3mdMwyUrRHYQPv/k7cZuO2uysK7guxC Ys1bFmIuueHNnAyepShpJg5BYomBuQJBlIujWtQ12zJTy7bKytfhyIZiNbpr7Pw8aO2K hjJb2HiVfJKS8IChxVN6UuLIw+wh3o+wKjzTX3+nTmcpEOQ/PjUwVBbJwQkj7kEmN4kF n6xTfeoH6nmG9b4NmJCvXkXSSgE1xwuEDMGNUdS+//P4YBGBdiR+vIPdGE47PXDcnAsZ gC2A== X-Received: by 10.68.191.106 with SMTP id gx10mr23272550pbc.151.1361873397863; Tue, 26 Feb 2013 02:09:57 -0800 (PST) Received: from MiniR2D2.local ([203.126.139.254]) by mx.google.com with ESMTPS id ab1sm432045pbd.37.2013.02.26.02.09.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 02:09:56 -0800 (PST) Message-ID: <512C89EE.8090800@gmail.com> Date: Tue, 26 Feb 2013 18:09:50 +0800 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Liubing (Leo)" References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <512C8044.3050103@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC132@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC132@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 10:09:59 -0000 Good. Regarding a possible next step. Are you guys planning to propose a "correct" behavior of the flags? It may be worth to try. Regards, as On 26/02/2013 17:53, Liubing (Leo) wrote: > Hi, Arturo and all > > That was my mistake. I derived this draft from a template and forgot to change it. > It should be "Informational", thanks for finding this bug. > > B.R. > Bing > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Arturo Servin >> Sent: Tuesday, February 26, 2013 5:29 PM >> To: ipv6@ietf.org >> Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps >> >> Dear authors, >> >> Very interesting document and very valuable to document the current >> behavior of the A, M and O flags (that have caused some headaches to >> some including myself when troubleshooting IPv6). >> >> I see that has been submitted as "Proposed Standard" but I failed to >> find what you are proposing. >> >> Would it better to be submitted as "Informational" and then look how >> to >> indicate the correct behavior of the flags? or just as "Informational"? >> >> Regards. >> as >> >> >> On 26/02/2013 15:14, Liubing (Leo) wrote: >>> Hi, 6man & v6ops >>> >>> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. >>> >>> As we know there are several flags in RA messages regarding with the host >> configuration behavior, which are A (Autonomous) flag, M (Managed) flag, >> and O (Otherconfig) flag. >>> For some reason, the host behavior of interpreting the flags is ambiguous >> in the standard (mainly RFC4862). I presented a draft discussing M flag >> behavior in 6man @ietf84, and there were some feedbacks arguing the same >> issue. This draft analyzed all the three flags, and provided test result of >> current implementations, it showed the behavior of different mainstream >> desktop OSes have varied. The ambiguous and variation might cause >> operational problems, such as renumbering (used to discuss in 6renum WG >> and been documented in the WG drafts), cold start problem, and >> management gaps .etc. >>> >>> Your review and comments would be appreciated very much. >>> >>> All the best, >>> Bing >>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Monday, February 25, 2013 5:52 PM >>>> To: Liubing (Leo) >>>> Cc: rbonica@juniper.net >>>> Subject: New Version Notification for >>>> draft-liu-bonica-dhcpv6-slaac-problem-01.txt >>>> >>>> >>>> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt >>>> has been successfully submitted by Bing Liu and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-liu-bonica-dhcpv6-slaac-problem >>>> Revision: 01 >>>> Title: DHCPv6/SLAAC Address Configuration Interaction Problem >>>> Statement >>>> Creation date: 2013-02-25 >>>> Group: Individual Submission >>>> Number of pages: 12 >>>> URL: >>>> >> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem- >>>> 01.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 >>>> Diff: >>>> >> http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem-01 >>>> >>>> Abstract: >>>> This document analyzes the host behavior of DHCPv6/SLAAC >> interaction >>>> issue. It reviews the standard definition of the host behaviors and >>>> provides the test results of current mainstream implementations. >> Some >>>> potential operational gaps of the interaction are also described. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From victor.kuarsingh@gmail.com Tue Feb 26 05:28: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 EE24821F8942; Tue, 26 Feb 2013 05:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.164 X-Spam-Level: X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Newtwd06mdXF; Tue, 26 Feb 2013 05:28:29 -0800 (PST) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56E21F89A5; Tue, 26 Feb 2013 05:28:29 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id o25so3461359iad.22 for ; Tue, 26 Feb 2013 05:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=iae8H5wdyiqptN1wbjXJHXdtE3oScMSMnXurp5fvnW8=; b=z/oNzNGI/y9cEc//QTyHAfAvyOfuWFmsMmBBv+hdp75reyIZnIdmpcLLLGZKbE6Ucm +ZT0nL7rEmNcaOk/j35tZj7uh8CSURkBAy+BP+sWEngEd/Yct3lik7k6EZSiNL61WGs5 NVOEbq7QK2E7FFCnyWbFHQ8hmBzaaGzoxa/Dj2kOsf33vDUqW5K1AXBs+KfEfvoCJELH JLYxer+jWt+Pe3r9jCvGUGHIvx/VYaY8IpRVY7sRvlE1bXp2KCXXTuZ4lSTAWmVKxi6W 7rsGd7B7QG5iVLCa+uhlwkzGQ9XhCVAlIvM92NCwhjc3r1CrPrzp8VCH66EXXr2vK8em DBXg== X-Received: by 10.50.42.168 with SMTP id p8mr5446698igl.106.1361885308791; Tue, 26 Feb 2013 05:28:28 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id ur12sm334146igb.8.2013.02.26.05.28.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 26 Feb 2013 05:28:27 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Feb 2013 08:28:22 -0500 From: Victor Kuarsingh To: "Liubing (Leo)" , "ipv6@ietf.org" , "v6ops@ietf.org" Message-ID: Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "renum@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 13:28:30 -0000 Bing, I as able to review the draft and agree this needs to be documented and discussed. I have had many frustrating nights dealing with my multiple OSs at home and figuring out what behaviour I was trying to expect when changing the upstream router's settings (M/O/A). I think the problem space discussion within the draft should be enough to have a preliminary discussion in the WG. I know there have been issues in the past with various opinions on what the M/O bits (for example) should or should not be used for - or how authoritative they should be. If the groups can agree that there is in fact a problem, then I would agree with Arturo that we can have a constructive follow-up draft/discussion on the corrective action. Lets get past step 1 and agree there is an issue (or not); then go down the more sensitive path of agreeing to the corrective action. Thanks for putting this together. Regards, Victor Kuarsingh On 2013-02-26 2:14 AM, "Liubing (Leo)" wrote: >Hi, 6man & v6ops > >We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. > >As we know there are several flags in RA messages regarding with the host >configuration behavior, which are A (Autonomous) flag, M (Managed) flag, >and O (Otherconfig) flag. >For some reason, the host behavior of interpreting the flags is ambiguous >in the standard (mainly RFC4862). I presented a draft discussing M flag >behavior in 6man @ietf84, and there were some feedbacks arguing the same >issue. This draft analyzed all the three flags, and provided test result >of current implementations, it showed the behavior of different >mainstream desktop OSes have varied. The ambiguous and variation might >cause operational problems, such as renumbering (used to discuss in >6renum WG and been documented in the WG drafts), cold start problem, and >management gaps .etc. > >Your review and comments would be appreciated very much. > >All the best, >Bing > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, February 25, 2013 5:52 PM >> To: Liubing (Leo) >> Cc: rbonica@juniper.net >> Subject: New Version Notification for >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt >> >> >> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt >> has been successfully submitted by Bing Liu and posted to the >> IETF repository. >> >> Filename: draft-liu-bonica-dhcpv6-slaac-problem >> Revision: 01 >> Title: DHCPv6/SLAAC Address Configuration Interaction Problem >> Statement >> Creation date: 2013-02-25 >> Group: Individual Submission >> Number of pages: 12 >> URL: >> >>http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem >>- >> 01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem >> Htmlized: >> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 >> Diff: >> >>http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem-01 >> >> Abstract: >> This document analyzes the host behavior of DHCPv6/SLAAC interaction >> issue. It reviews the standard definition of the host behaviors and >> provides the test results of current mainstream implementations. Some >> potential operational gaps of the interaction are also described. >> >> >> >> >> The IETF Secretariat > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From john_brzozowski@cable.comcast.com Tue Feb 26 05:53: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 633AF21F867A for ; Tue, 26 Feb 2013 05:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=-1.354, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lioZiXD3eVD2 for ; Tue, 26 Feb 2013 05:53:07 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7EB21F8673 for ; Tue, 26 Feb 2013 05:53:07 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44613044; Tue, 26 Feb 2013 08:40:28 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Tue, 26 Feb 2013 08:52:56 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , Owen DeLong Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOE+t3/dzS9cbAc0ie1KTMDHbgxZiMKU8A Date: Tue, 26 Feb 2013 13:52:54 +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.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <43DB6068C85AA945B951A89ED63772B9@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 13:53:08 -0000 Comcast has been setup from the beginning to allow up to a /60 for retail residential broadband and /48 for our commercial services FWIW. We will revise these over time so please do not assume this is where things will remain. RFC3177 did not influence this decision and frankly was written too early to be relevant IMO. RFC6177 seems to be better however this has not factored heavily into our decisions either. One example worth noting is the recommendation to not issue /128s, many of my customers have a single device connected to their broadband connection. Should I stop serving them IPv6? If yes why? This seems to contradict our goal to increase IPv6 use across the ecosystem. I am glad to see most of the questionable text from 3177 was updated. Most adopters of IPv6 recognize the need for shorter address blocks to support multiple connected interfaces, however, there are some implementations that either a) react poorly to a shorter prefix when the device cannot support the same or b) simply do not support shorter prefixes. 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) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =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 -----Original Message----- From: Lorenzo Colitti Date: Monday, February 25, 2013 10:34 PM To: Owen DeLong Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >On Fri, Feb 22, 2013 at 6:27 PM, Owen DeLong wrote: > >> RFC6177 was published as BCP. > >> http://tools.ietf.org/html/rfc6177 >> > > >True. I wasn't participating actively in IETF at the time 6177 was >written. IMHO, it is a travesty of v4 thinking being brought forward into >IPv6 and should be considered harmful rather than BCP. It is neither >common, nor best practice in my experience so far > in the IPv6 world. > > > > >You may disagree that it is best, but unfortunately, it IS common. The >largest IPv6 deployments in the world assign smaller than /48 blocks by >default. > > >Examples: AT&T /60, free.fr /60, Verizon Wireless /64 >(though to be fair, it's not their fault - 3GPP doesn't support DHCPv6 >PD), Comcast /64 (unless they've changed their default recently), NTT >Japan /56 or /64, and > so on. > > >In fact, I'm not aware of any major residential ISP (not a tunnel broker) >that actually assigns /48s. Are you? > > > From john_brzozowski@cable.comcast.com Tue Feb 26 05:58: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 EEC3121F86AF for ; Tue, 26 Feb 2013 05:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.381 X-Spam-Level: X-Spam-Status: No, score=-104.381 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPASv1nqPKYa for ; Tue, 26 Feb 2013 05:58:09 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6D021F86A8 for ; Tue, 26 Feb 2013 05:58:09 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.58057905; Tue, 26 Feb 2013 06:27:31 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Tue, 26 Feb 2013 08:58:03 -0500 From: "Brzozowski, John" To: "Brzozowski, John" , Lorenzo Colitti , Owen DeLong Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOE+t3/dzS9cbAc0ie1KTMDHbgxZiMKU8AgAABbQA= Date: Tue, 26 Feb 2013 13:58:02 +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.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B790618320E254F936BF45E17F58C0B@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 13:58:10 -0000 Forgot to mention, Comcast hat on. =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) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =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 -----Original Message----- From: , John Jason Brzozowski Date: Tuesday, February 26, 2013 5:52 AM To: Lorenzo Colitti , Owen DeLong Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >Comcast has been setup from the beginning to allow up to a /60 for retail >residential broadband and /48 for our commercial services FWIW. We will >revise these over time so please do not assume this is where things will >remain. RFC3177 did not influence this decision and frankly was written >too early to be relevant IMO. > >RFC6177 seems to be better however this has not factored heavily into our >decisions either. > >One example worth noting is the recommendation to not issue /128s, many of >my customers have a single device connected to their broadband connection. > Should I stop serving them IPv6? If yes why? This seems to contradict >our goal to increase IPv6 use across the ecosystem. I am glad to see most >of the questionable text from 3177 was updated. Most adopters of IPv6 >recognize the need for shorter address blocks to support multiple >connected interfaces, however, there are some implementations that either >a) react poorly to a shorter prefix when the device cannot support the >same or b) simply do not support shorter prefixes. > >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) 484-962-0060 >e) john_brzozowski@cable.comcast.com >o) 609-377-6594 >w) www.comcast6.net >=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 > > > > > > > >-----Original Message----- >From: Lorenzo Colitti >Date: Monday, February 25, 2013 10:34 PM >To: Owen DeLong >Cc: "v6ops@ietf.org" , >"draft-shishio-v6ops-dpvt@tools.ietf.org" > >Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt > >>On Fri, Feb 22, 2013 at 6:27 PM, Owen DeLong wrote: >> >>> RFC6177 was published as BCP. >> >>> http://tools.ietf.org/html/rfc6177 >>> >> >> >>True. I wasn't participating actively in IETF at the time 6177 was >>written. IMHO, it is a travesty of v4 thinking being brought forward into >>IPv6 and should be considered harmful rather than BCP. It is neither >>common, nor best practice in my experience so far >> in the IPv6 world. >> >> >> >> >>You may disagree that it is best, but unfortunately, it IS common. The >>largest IPv6 deployments in the world assign smaller than /48 blocks by >>default. >> >> >>Examples: AT&T /60, free.fr /60, Verizon Wireless /64 >>(though to be fair, it's not their fault - 3GPP doesn't support DHCPv6 >>PD), Comcast /64 (unless they've changed their default recently), NTT >>Japan /56 or /64, and >> so on. >> >> >>In fact, I'm not aware of any major residential ISP (not a tunnel broker) >>that actually assigns /48s. Are you? >> >> >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Tue Feb 26 06:00:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF61621F86CE for ; Tue, 26 Feb 2013 06:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JulYgPzR7ILp for ; Tue, 26 Feb 2013 06:00:50 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 201CA21F86B3 for ; Tue, 26 Feb 2013 06:00:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 16E5E9C; Tue, 26 Feb 2013 15:00:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 239A69A; Tue, 26 Feb 2013 15:00:45 +0100 (CET) Date: Tue, 26 Feb 2013 15:00:45 +0100 (CET) From: Mikael Abrahamsson To: "Brzozowski, John" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 14:00:50 -0000 On Tue, 26 Feb 2013, Brzozowski, John wrote: > One example worth noting is the recommendation to not issue /128s, many > of my customers have a single device connected to their broadband > connection. Should I stop serving them IPv6? If yes why? This seems to > contradict our goal to increase IPv6 use across the ecosystem. I am > glad to see most of the questionable text from 3177 was updated. Most > adopters of IPv6 recognize the need for shorter address blocks to > support multiple connected interfaces, however, there are some > implementations that either a) react poorly to a shorter prefix when the > device cannot support the same or b) simply do not support shorter > prefixes. I take it you do not have a CPE device that is actually an L3 router at the customer premise, but the "cable modem" is only an L2 bridge? As long as DHCPv6-PD space is available, then I would be fine by allowing for the customer option of a single PC connected would get its single IPv6 address by means of DHCPv6 /128. Personally I however opt for a solution where by default what comes out the CPE device is a SLAAC /64 where the customer can have a limited amount of ND entries (for instance 50), and if they want more then they have to get themselves a router which will get a /56 by means of -PD and put their additional devices behind that one. This ND 50 limitation is only needed if the device upstream that handles ND entries has some kind of limitation to ND entries, otherwise that can be skipped. -- Mikael Abrahamsson email: swmike@swm.pp.se From john_brzozowski@cable.comcast.com Tue Feb 26 06:09: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 002D621F8999 for ; Tue, 26 Feb 2013 06:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.086 X-Spam-Level: X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=-1.489, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka9bAV-7WG+I for ; Tue, 26 Feb 2013 06:09:01 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id F3C8D21F8992 for ; Tue, 26 Feb 2013 06:09:00 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44615599; Tue, 26 Feb 2013 08:56:24 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Tue, 26 Feb 2013 09:07:54 -0500 From: "Brzozowski, John" To: Mikael Abrahamsson Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOE+t3/dzS9cbAc0ie1KTMDHbgxZiMKU8AgABWA4D//64rAA== Date: Tue, 26 Feb 2013 14:07:53 +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.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BAC3F5251658841A9C530EF9ED2DD14@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 14:09:02 -0000 -----Original Message----- From: Mikael Abrahamsson Organization: People's Front Against WWW Date: Tuesday, February 26, 2013 6:00 AM To: John Jason Brzozowski Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >On Tue, 26 Feb 2013, Brzozowski, John wrote: > >> One example worth noting is the recommendation to not issue /128s, many >> of my customers have a single device connected to their broadband >> connection. Should I stop serving them IPv6? If yes why? This seems >>to=20 >> contradict our goal to increase IPv6 use across the ecosystem. I am >> glad to see most of the questionable text from 3177 was updated. Most >> adopters of IPv6 recognize the need for shorter address blocks to >> support multiple connected interfaces, however, there are some >> implementations that either a) react poorly to a shorter prefix when >>the=20 >> device cannot support the same or b) simply do not support shorter >> prefixes. > >I take it you do not have a CPE device that is actually an L3 router at >the customer premise, but the "cable modem" is only an L2 bridge? [jjmb] incorrect I have both, just stating that I have both. Apologies if I was not clear. I also have a good # of home routers actively using IPv6 enabled broadband today, ~3%. > >As long as DHCPv6-PD space is available, then I would be fine by allowing >for the customer option of a single PC connected would get its single >IPv6=20 >address by means of DHCPv6 /128. [jjmb] of course, we offer both. > >Personally I however opt for a solution where by default what comes out >the CPE device is a SLAAC /64 where the customer can have a limited >amount=20 >of ND entries (for instance 50), and if they want more then they have to >get themselves a router which will get a /56 by means of -PD and put >their=20 >additional devices behind that one. This ND 50 limitation is only needed >if the device upstream that handles ND entries has some kind of >limitation=20 >to ND entries, otherwise that can be skipped. [jjmb] it is practical to limit the # of directly connected CPEs, however for devices connected to the LAN of a CPE router this is really up to the customer. Sounds like you concur. =20 > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Tue Feb 26 09:53: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 8AE4E21F8462 for ; Tue, 26 Feb 2013 09:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.15 X-Spam-Level: X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUCsfl8pHeNB for ; Tue, 26 Feb 2013 09:53:30 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id AEBC321F8457 for ; Tue, 26 Feb 2013 09:53:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1QHrAGM012753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Feb 2013 18:53:11 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1QHrArF001349 for ; Tue, 26 Feb 2013 18:53:10 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1QHr6xb009936 for ; Tue, 26 Feb 2013 18:53:10 +0100 Message-ID: <512CF682.8030307@gmail.com> Date: Tue, 26 Feb 2013 18:53:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 17:53:38 -0000 Le 21/02/2013 21:40, Cameron Byrne a écrit : > Behcet, > > On Wed, Feb 20, 2013 at 2:45 PM, Behcet Sarikaya > wrote: >> Hi Cameron, >> >> sorry for my belated reply. >> >> On Sun, Feb 3, 2013 at 7:37 PM, Cameron Byrne >> wrote: >>> >>> >>> >>> Since a lot of folks talk about IPv6 in mobile, i figured i >>> would pen my own view and experience here. It hopefully will set >>> some context for the WG work products draft-ietf-v6ops-464xlat, >>> draft-ietf-v6ops-64share, >>> draft-binet-v6ops-cellular-host-requirements. Please do note >>> 464XLAT is not 3GPP/mobile specific. >>> >>> AFAIK, there is exactly 1 provider in the world of 3GPP that >>> offers dual-stack service by default, Verizon Wireless (hat >>> tip). I did not count, but there is probably more that 50 LTE >>> networks out there today >>> http://en.wikipedia.org/wiki/List_of_LTE_networks .. There may be >>> some others that support default-on dual-stack, i but i don't >>> know of them. >>> >>> So, conclusion #1 is that that LTE does not require or even help >>> IPv6 deployment. Look at the facts. There is a long list of LTE >>> networks that definitely do not have IPv6 or dual-stack by >>> default: AT&T, Sprint, EE, T-Mobile DE, Rogers, Vodafone, .. >>> >> >> Maybe they realized that NAT44 is good enough for them to handle >> not so many LTE customers they have? They already know NAT44 >> technology. >> > > Correct. NAT44 is good enough if you can number users from RFC1918. > If users (including M2M ...) and infrastructure exceed RFC1918 > space If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) then there is this 100.64.0.0/10 new space from RFC6598. > the problem becomes substantially more complicated and NAT44 is not > nearly as fit for the problem. For many mobile networks, they have > always been on NAT44 so inertia supports staying on NAT44. My > specific problem is that i have more users / gear / cell sites than > RFC1918, that is my driver for ipv6. I think it is a good driver. An additional driver I could think of is applications which don't work when NAT is present. I think webrtc - I think it works ok if there is a rdv point, but may not work otherwise. >>> I believe a lot of folks, myself included, thought network >>> upgrades would bring about more IPv6 features and deployment. >>> In my own experience, this is the exact opposite in reality. Let >>> me explain. >>> >>> There are 4 major providers of 3GPP equipment. I will exonerate >>> Huawei since i don't know anything about them and Cisco because >>> i know there stuff works (AFAIK). The other 2 providers are >>> specifically defunct on the IPv4v6 front. One -- has a brand >>> new high capacity P-GW/GGSN which does not support IPv4v6 (it >>> supports v4 or v6). >> >> >>> >>> And the other, which is painfully wrecking my IPv4v6 deployment >>> plans, has a newish (few years old now) high capacity SGSN which >>> does not support IPv4v6 (also supports v4 or v6). >> >> >> This should be OK for SGSN because you don't even need SGSN to >> support IPv6 in order to support IPv6 in your network, right? >> because of the inherent tunneling. >> > > As Ales noted, the issue is with control plane signalling and > handover between 2G/3G/4G. If the features are not synchronized, it > does not work well... especially if features such as "CS Fall Back" > are used to push between 3G and 4G for voice calls. > >>> Witness, new gear does not result in v4v6 (dual-stack). >> >> >> I remember you voiced strongly against the dual stack approach. >> You seemed to have advocated IPv6 only network with 4via6 >> approaches, v4 users can be supported. This was what you were >> advocating, and for a good reason. >> > > This was my "crazy" single-stack perspective, but i think it has > become more popular and therefore slightly less crazy :) > > I am still making progress on rolling out 464XLAT. The missing piece > right now is the handset, but it is making progress. As noted in my > rant, unforunately many vendors ship new gear without IPv6. It seems > counter-intuitive. Many folks thought they might new gear to do > IPv6, but in these specific cases new gear removed IPv6 functions. > >>> >>> In fact, the legacy SGSN that i had from the same vendor does >>> support v4v6, but it is now end of life (at least as far as my >>> network)! It is just the new one that does not have dual-stack >>> support. >>> >>> Thought i would just share, and dispel any misconceptions folks >>> had about 3GPP / LTE networks and IPv6, especially about >>> dual-stack. There is nothing wrong with the 3GPP specs, and i >>> know the network operators are asking but not getting the >>> features ... That said, draft-ietf-v6ops-464xlat and >>> draft-ietf-v6ops-64share are both hacks that try to route around >>> the brokeness of economics, NAT444s, vendors that don't ship 4+ >>> year old 3GPP defined mandatory features (IPv4v6 LTE bearers), >>> and >> >> >>> >>> IPV4-only apps like Skype. >>> >> >> This seems to be the main issue. What a pity :-). >> > > A pity indeed. The lesson I learned over the last few years is that > it is easier to change the host than the apps. It seems > counter-intuitive, but alas we must understand the things we can > control and the things we cannot control. If LTE doesn't do IPv6, some needs to improve its IPv4 may exist. For example, I would appreciate if an IPv4 64share method were possible ('24share'?)... Alex > > CB > >> Regards, >> >> Behcet > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From bs7652@att.com Tue Feb 26 10:06: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 A947B21F8A54; Tue, 26 Feb 2013 10:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxrMPFkOp46H; Tue, 26 Feb 2013 10:06:42 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1747821F886B; Tue, 26 Feb 2013 10:06:42 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 2b9fc215.53c06940.4288268.00-533.11847790.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 26 Feb 2013 18:06:42 +0000 (UTC) X-MXL-Hash: 512cf9b24a1a8ee4-7de3abe4ef9469d00e2360082cd6e3c605c42217 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ea9fc215.0.4288249.00-496.11847726.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 26 Feb 2013 18:06:40 +0000 (UTC) X-MXL-Hash: 512cf9b022ec96b0-34130cba56638fea4099aab599ab43fa530cfdd5 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1QI6c7i028467; Tue, 26 Feb 2013 13:06:38 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1QI6Tnk028206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 13:06:33 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Tue, 26 Feb 2013 13:02:16 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 13:02:05 -0500 From: "STARK, BARBARA H" To: "Liubing (Leo)" , "ipv6@ietf.org" , "v6ops@ietf.org" Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiMZZ8g Date: Tue, 26 Feb 2013 18:02:04 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130255AE0@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.174.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Ob0v+GvY c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=SawaiHsxiTQA:10 a=mjfWdd7OfzUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=qIRfQioSgDsA:10 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8] X-AnalysisOut: [ a=IrhkzyA9JQ-jOgXrGygA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=peF9eE_zjQwA:10 a=_nbaV8ywFon7Z7Y3:21 a=l_Yy1O5uc6Fl] X-AnalysisOut: [zOYM:21] Cc: "renum@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 18:06:43 -0000 This is interesting. Thanks for doing these tests and submitting the result= s. When testing the switching behavior, I'm curious for the " SLAAC-only host = receiving A=3D0&M=3D1 " case as to what you set the Preferred Lifetime to, = when you set A=3D0. I'm guessing Preferred Lifetime > 0? Since RFC 4862 states "A preferred address becomes deprecated when its pref= erred lifetime expires", I would only have expected a host to deprecate a S= LAAC-obtained address if the RA message set Preferred Lifetime to zero. It = sounds like the case where the RA is changed from A=3D1 and Preferred Lifet= ime > 0 to A=3D0 and Preferred Lifetime > 0 is ambiguous. I'm not quite sur= e what the use case is for separating the A flag and Preferred Lifetime set= tings. Did you also run the test by changing to A=3D0 and Preferred Lifetim= e =3D 0? I would hope that there would be consistent behavior in that case. For the "DHCPv6-only host receiving A=3D1&M=3D0" case, I'm curious as to wh= ether you also tried sending a DHCPv6 Reconfigure message and forcing the h= ost to release the DHCPv6-assigned address; and send A=3D1&M=3D0 in an RA d= irectly after sending the Reconfigure. I'm not sure what the use case is fo= r trying to force the release or deprecation of a DHCPv6 address via flags = in an RA message. Once a host has a DHCPv6 address, I would have expected i= ts subsequent behavior relating to that address and that DHCPv6 server to b= e governed by RFC 3315. The Linux/MAC behavior appears consistent with what= I would have expected. The Windows 7 does not. I'm unaware of even a "hint= " that suggests RA flags have a role in governing DHCPv6 behavior once RFC = 3315 is in play. Barbara > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Liubing (Leo) > Sent: Tuesday, February 26, 2013 2:14 AM > To: ipv6@ietf.org; v6ops@ietf.org > Cc: renum@ietf.org > Subject: SLAAC/DHCPv6 addr-conf operational gaps >=20 > Hi, 6man & v6ops >=20 > We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. >=20 > As we know there are several flags in RA messages regarding with the host > configuration behavior, which are A (Autonomous) flag, M (Managed) flag, > and O (Otherconfig) flag. > For some reason, the host behavior of interpreting the flags is ambiguous= in > the standard (mainly RFC4862). I presented a draft discussing M flag beha= vior > in 6man @ietf84, and there were some feedbacks arguing the same issue. > This draft analyzed all the three flags, and provided test result of curr= ent > implementations, it showed the behavior of different mainstream desktop > OSes have varied. The ambiguous and variation might cause operational > problems, such as renumbering (used to discuss in 6renum WG and been > documented in the WG drafts), cold start problem, and management gaps > .etc. >=20 > Your review and comments would be appreciated very much. >=20 > All the best, > Bing >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, February 25, 2013 5:52 PM > > To: Liubing (Leo) > > Cc: rbonica@juniper.net > > Subject: New Version Notification for > > draft-liu-bonica-dhcpv6-slaac-problem-01.txt > > > > > > A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt > > has been successfully submitted by Bing Liu and posted to the IETF > > repository. > > > > Filename: draft-liu-bonica-dhcpv6-slaac-problem > > Revision: 01 > > Title: DHCPv6/SLAAC Address Configuration Interaction Problem > > Statement > > Creation date: 2013-02-25 > > Group: Individual Submission > > Number of pages: 12 > > URL: > > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-prob > > lem- > > 01.txt > > Status: > > http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem > > Htmlized: > > http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-proble= m > > -01 > > > > Abstract: > > This document analyzes the host behavior of DHCPv6/SLAAC interaction > > issue. It reviews the standard definition of the host behaviors and > > provides the test results of current mainstream implementations. Som= e > > potential operational gaps of the interaction are also described. > > > > > > > > > > The IETF Secretariat >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From wesley.george@twcable.com Tue Feb 26 10:13:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ECC21F8633 for ; Tue, 26 Feb 2013 10:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deCYx6cY3ykz for ; Tue, 26 Feb 2013 10:13:33 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E49721F861A for ; Tue, 26 Feb 2013 10:13:33 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,742,1355115600"; d="scan'208";a="32847697" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Feb 2013 13:11:59 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 26 Feb 2013 13:12:52 -0500 From: "George, Wes" To: Philip Matthews , "v6ops@ietf.org list" Date: Tue, 26 Feb 2013 13:12:52 -0500 Thread-Topic: [v6ops] draft-ietf-v6ops-design-choices-00 Thread-Index: Ac4K5hD4xvJsDV37TqCufRmeEp70hQJZVGuQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923041EF8C7FD@PRVPEXVS15.corp.twcable.com> References: 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 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices-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, 26 Feb 2013 18:13:34 -0000 One thing I might recommend highlighting as you discuss pros and cons in th= e different sections and especially as an expansion of section 3.2 is the i= dea that eventually the network will transition from dual-stack back to sin= gle-stack (v6-only), and your design choices now will impact how easy or ha= rd it is to make that transition later. The actual timeframe for when that = happens is not important in the design phase, but the fact that it will eve= ntually happen, probably in phases across the network, is something that pe= ople need to be considering. It certainly informs decisions like 2.4, and m= ay well impact the way that you build your routing policies and QoS. If I were to summarize what I interpret from the current section 3.2, it's = that short-term, you want IPv4 and IPv6 to mirror each other as closely as = possible in order to reduce the amount of double or parallel work that must= be done to manage the two independent protocol stacks. I agree with this, = but I think we should take it further to talk about the long-term considera= tions. While fate sharing between control and data plane is valuable, the o= ther rule of thumb is probably that you want to design things modularly eno= ugh that you can eventually shut off IPv4 without having to redesign large = parts of the network config. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Philip Matthews > Sent: Thursday, February 14, 2013 2:04 PM > To: v6ops@ietf.org list > Subject: [v6ops] draft-ietf-v6ops-design-choices-00 > > Folks: > > I have just submitted draft-ietf-v6ops-design-choices-00, which is a > renamed version of the Design Guidelines draft (draft-matthews-v6ops- > design-guidelines). It should be appearing in the online drafts > repository shortly. > > Though I had hoped to get a more substantial revision out, work > intervened and I was only able to make a few smaller changes. > I have been working on adding more design choices, but ran out of time. > Sorry. > > Comments on the new version are most welcome. > > - Philip > _______________________________________________ > 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 owen@delong.com Tue Feb 26 10:41: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 5F69B21F8976 for ; Tue, 26 Feb 2013 10:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPHS9SsCZcVx for ; Tue, 26 Feb 2013 10:41:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23C21F8984 for ; Tue, 26 Feb 2013 10:41:05 -0800 (PST) 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 r1QIdPoW009862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 10:39:25 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1QIdPoW009862 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361903967; bh=kviZd1vj+e4GaFZm9k4AsZF93qk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=qYrSNHN856sLtErP5s273GLPkTJJ2/I0AjN+ugziymbIw8g2OHr/iJX/W6y6muUVI hsJFr6BwcYF+SM05rF1bbMzglmeJUWuWz8siHCF5CiSPoO2wmcX8FDPxp0SubR9Uum mlfqiadL0JKmYx8bE8I14UlHyB/pR6FFjzIK9qnc= Content-Type: multipart/alternative; boundary="Apple-Mail=_4EF144D0-7594-4D5F-80F4-E50F7E1B182F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Tue, 26 Feb 2013 10:39:23 -0800 Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 26 Feb 2013 10:39:27 -0800 (PST) Cc: "v6ops@ietf.org" , "draft-shishio-v6ops-dpvt@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 18:41:07 -0000 --Apple-Mail=_4EF144D0-7594-4D5F-80F4-E50F7E1B182F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 25, 2013, at 22:34 , Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 6:27 PM, Owen DeLong wrote: > > RFC6177 was published as BCP. > > http://tools.ietf.org/html/rfc6177 > > >=20 > True. I wasn't participating actively in IETF at the time 6177 was = written. IMHO, it is a travesty of v4 thinking being brought forward = into IPv6 and should be considered harmful rather than BCP. It is = neither common, nor best practice in my experience so far in the IPv6 = world. >=20 > You may disagree that it is best, but unfortunately, it IS common. The = largest IPv6 deployments in the world assign smaller than /48 blocks by = default. >=20 If it's becoming common, that's unfortunate. Hopefully it won't remain = common for very long. I don't disagree with John about issuing /128s = where necessary or about issuing /64s to devices that can't handle = shorter prefixes. I accept the need to make things work in spite of = buggy hardware and/or software. > Examples: AT&T /60, free.fr /60, Verizon Wireless /64 (though to be = fair, it's not their fault - 3GPP doesn't support DHCPv6 PD), Comcast = /64 (unless they've changed their default recently), NTT Japan /56 or = /64, and so on. >=20 > In fact, I'm not aware of any major residential ISP (not a tunnel = broker) that actually assigns /48s. Are you? However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing = /48s. I don't know if any of the non-tunnel providers are issuing /48s = by default, but, I do know that /48s from our tunnel broker are fairly = popular. (Including some from people that could go native if they were = willing to accept the smaller prefixes from their providers). It would be one thing if issuing such longer prefixes actually provided = some benefit, but the reality is that it does not. All it does is make = future innovation more difficult and reduce the utility of the network. Owen --Apple-Mail=_4EF144D0-7594-4D5F-80F4-E50F7E1B182F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Feb 25, 2013, at 22:34 , Lorenzo Colitti <lorenzo@google.com> wrote:

On Fri, Feb 22, 2013 at 6:27 PM, Owen DeLong <owen@delong.com> wrote:
> RFC6177 was published as BCP.
> http://tools.ietf.org/html/rfc6177
>

True. I wasn't participating actively in IETF at the time 6177 was written. IMHO, it is a travesty of v4 thinking being brought forward into IPv6 and should be considered harmful rather than BCP. It is neither common, nor best practice in my experience so far in the IPv6 world.

You may disagree that it is best, but unfortunately, it IS common. The largest IPv6 deployments in the world assign smaller than /48 blocks by default.


If it's becoming common, that's unfortunate. Hopefully it won't remain common for very long. I don't disagree with John about issuing /128s where necessary or about issuing /64s to devices that can't handle shorter prefixes. I accept the need to make things work in spite of buggy hardware and/or software.


Examples: AT&T /60, free.fr /60, Verizon Wireless /64 (though to be fair, it's not their fault - 3GPP doesn't support DHCPv6 PD), Comcast /64 (unless they've changed their default recently), NTT Japan /56 or /64, and so on.

In fact, I'm not aware of any major residential ISP (not a tunnel broker) that actually assigns /48s. Are you?

However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing /48s. I don't know if any of the non-tunnel providers are issuing /48s by default, but, I do know that /48s from our tunnel broker are fairly popular. (Including some from people that could go native if they were willing to accept the smaller prefixes from their providers).

It would be one thing if issuing such longer prefixes actually provided some benefit, but the reality is that it does not. All it does is make future innovation more difficult and reduce the utility of the network.

Owen

--Apple-Mail=_4EF144D0-7594-4D5F-80F4-E50F7E1B182F-- From ipepelnjak@gmail.com Tue Feb 26 10:49: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 1DD0B21F8970 for ; Tue, 26 Feb 2013 10:49:22 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noS-MOAqnMDk for ; Tue, 26 Feb 2013 10:49:21 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 644C021F88E3 for ; Tue, 26 Feb 2013 10:49:21 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so2717649eek.29 for ; Tue, 26 Feb 2013 10:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=J9oi9wL6nQ2Bjtq6D7F0H5sOZEUTzn0u+mq8YcDwXqM=; b=rJzwkYydAB0HDzDsRjHaw9PeY8ztn1BqR3S1c4Yit4f/sPKYiOg0Rj4BZx8rcFMzB3 vR55JH2kM2Bgg0+7f2Spnj8WwkYwjf7ThGCDf/MGJ5tTSKcQH2qJj6VyPmy4gshg7hpk N1Bi/T4zc6o6qrjc16yxf/PfrewDxU0srecjsjrWsj1qcVS3Ox64KP+YpBD5Mp2u05ct pDUoA0DBfMl+InoRz59IZhGCglGGFUx5rJAnl69p1LF9THEB/6CPlmwvTHTtLppjVUGV WIz311W7osYdT1vTPhKrQL32Cl5hV0duxZxv08rcumL1uJ1MIyBDlBdx5ATpRj00BrHE Fl5g== X-Received: by 10.14.207.73 with SMTP id m49mr52690034eeo.24.1361904560591; Tue, 26 Feb 2013 10:49:20 -0800 (PST) Received: from Ivans-MacBook-Air.local (83-215-81-109.stjo.dyn.salzburg-online.at. [83.215.81.109]) by mx.google.com with ESMTPS id r4sm2833770eeo.12.2013.02.26.10.49.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 10:49:19 -0800 (PST) Message-ID: <512D03AC.5050005@gmail.com> Date: Tue, 26 Feb 2013 19:49:16 +0100 From: Ivan Pepelnjak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 18:49:22 -0000 On 26.02.2013 19:39 , Owen DeLong wrote: [...] > It would be one thing if issuing such longer prefixes actually provided > some benefit, but the reality is that it does not. All it does is make > future innovation more difficult and reduce the utility of the network. Years after a similar comment on my blog I'm still waiting for a sample of innovation being stifled by residential end-user prefixes longer than /48. Ivan From dougb@dougbarton.us Tue Feb 26 11:04: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 1A2AC21F8842 for ; Tue, 26 Feb 2013 11:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fP73JXvEvyO for ; Tue, 26 Feb 2013 11:04:36 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBDD21F8821 for ; Tue, 26 Feb 2013 11:04:36 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:4cf6:ff8f:32c1:5210] (unknown [IPv6:2001:470:d:5e7:4cf6:ff8f:32c1:5210]) by dougbarton.us (Postfix) with ESMTPSA id 1481B22B22 for ; Tue, 26 Feb 2013 19:04:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1361905473; bh=bDc05VPeL13Km+O3YTUA6mjAspgUBShwQ/uVxE0qtQQ=; h=Date:From:To:Subject:References:In-Reply-To; b=psyUMVQhQHvd+WgCT5I4etZbCIWwP6VEinhDFK9nju2I1uNlwF+rSndxbMm+1MQkz i7XFX1QSZ5Bgnwksqu1eGCkYFGAt9RQ4PseFd0kvytDtrRbBaBGgWpmrp11dxc+U26 VNnVkdahhfRqmLNdmFkzDfioh436kG6hzTQXi/ik= Message-ID: <512D0740.1040801@dougbarton.us> Date: Tue, 26 Feb 2013 11:04:32 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> In-Reply-To: <512D03AC.5050005@gmail.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 19:04:37 -0000 On 02/26/2013 10:49 AM, Ivan Pepelnjak wrote: > On 26.02.2013 19:39 , Owen DeLong wrote: > [...] >> It would be one thing if issuing such longer prefixes actually provided >> some benefit, but the reality is that it does not. All it does is make >> future innovation more difficult and reduce the utility of the network. > > Years after a similar comment on my blog I'm still waiting for a sample > of innovation being stifled by residential end-user prefixes longer than > /48. Rather than repeat this entire discussion again, the answer I've proposed for years now, without anyone showing why it might be a bad idea ... :) 1. Reserve a /48 for each assignment 2. Actually assign whatever longer prefix you think is reasonable (/56, /60, etc.) 3. When you get past 50% of your space being reserved, review this policy That way, if the people who say that it should be "/48s all the way down" are right, you're covered. If it turns out that you're running out of space and you can't get more (unlikely of course), then you can go back and chop each reservation in 1/2, and start again. Doug From owen@delong.com Tue Feb 26 11:11: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 6A66C21F87FD for ; Tue, 26 Feb 2013 11:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2TjLSOjBvwJ for ; Tue, 26 Feb 2013 11:11:20 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BDDEB21F8790 for ; Tue, 26 Feb 2013 11:11:19 -0800 (PST) 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 r1QJ6ukl010602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 11:06:56 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1QJ6ukl010602 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361905616; bh=0I/8QM9Sr2WDonPXKZq/epO+9t4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K+6KVUVdJuW8lZSsioHSmAA+5Tos0KptlyN0PyrUtM/s7jcgHMi8z/GlL+0YG2/Eh 824nsvb0oBgukFNlrGU0H0k2Jwb4GlFijZDxWz+pBQZjpGaJXssNfEaymcAxhNTZ/C vVWHyOyTOmi6UYlTQ9eQgWf5ftaLnBJSLbMDVPiw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <512D03AC.5050005@gmail.com> Date: Tue, 26 Feb 2013 11:06:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> To: Ivan Pepelnjak X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 26 Feb 2013 11:06:56 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 19:11:21 -0000 On Feb 26, 2013, at 10:49 , Ivan Pepelnjak wrote: > On 26.02.2013 19:39 , Owen DeLong wrote: > [...] >> It would be one thing if issuing such longer prefixes actually = provided >> some benefit, but the reality is that it does not. All it does is = make >> future innovation more difficult and reduce the utility of the = network. >=20 > Years after a similar comment on my blog I'm still waiting for a = sample of innovation being stifled by residential end-user prefixes = longer than /48. >=20 It's too early to know. There isn't enough IPv6 deployment yet for the = majority of innovators to have even started looking at what would be = possible. Unfortunately, we're on a path where we will have to set the = constraints first and then see what innovations occur. So far, we're on = a good track to repeat the mistakes of IPv4, hamper said innovation = (which many of the large residential ISPs may consider a vested = interest), and deploy IPv6 in a manner that helps preserve a more = consumer/provider model of the internet rather than a more peer-centric = model. Owen From owen@delong.com Tue Feb 26 11:11: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 73B9B21F87FD for ; Tue, 26 Feb 2013 11:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytMh6+hsfZVZ for ; Tue, 26 Feb 2013 11:11:22 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id CA8C121F8790 for ; Tue, 26 Feb 2013 11:11:21 -0800 (PST) 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 r1QJ99BN010633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 11:09:09 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1QJ99BN010633 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361905750; bh=ihFLduOiWGSc2o9ciP6Akh7p/YU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hLgE+t3uzwHqLbc+loCmam1ZvgEZrhL4lL10Z3qrhhq4Ay3aXl/wSxPSjN064Oc5P EviboT25v5o3AJySvpvujULNkYPk8dhyHk+ewxh1iWFBdXPd24JwE0HPk9iYCvGpWH 7pCg9GxJTWL47h5XbZNsVl1nE/Ai6wr67aovewfI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <512D0740.1040801@dougbarton.us> Date: Tue, 26 Feb 2013 11:09:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 26 Feb 2013 11:09:10 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 19:11:22 -0000 On Feb 26, 2013, at 11:04 , Doug Barton wrote: > On 02/26/2013 10:49 AM, Ivan Pepelnjak wrote: >> On 26.02.2013 19:39 , Owen DeLong wrote: >> [...] >>> It would be one thing if issuing such longer prefixes actually = provided >>> some benefit, but the reality is that it does not. All it does is = make >>> future innovation more difficult and reduce the utility of the = network. >>=20 >> Years after a similar comment on my blog I'm still waiting for a = sample >> of innovation being stifled by residential end-user prefixes longer = than >> /48. >=20 > Rather than repeat this entire discussion again, the answer I've = proposed for years now, without anyone showing why it might be a bad = idea ... :) >=20 > 1. Reserve a /48 for each assignment > 2. Actually assign whatever longer prefix you think is reasonable = (/56, /60, etc.) > 3. When you get past 50% of your space being reserved, review this = policy >=20 > That way, if the people who say that it should be "/48s all the way = down" are right, you're covered. If it turns out that you're running out = of space and you can't get more (unlikely of course), then you can go = back and chop each reservation in 1/2, and start again. >=20 At least in North America, it's pretty easy to get a very large amount = of IPv6 space. Being unable to obtain space is clearly not a valid reason to use longer = prefixes and I certainly think that your proposed compromise is an = improvement over dense-packing long prefixes. However, I have yet to = hear from anyone any legitimate reason for using longer prefixes to = begin with. Nobody has yet stated any benefit to doing so. Owen From dougb@dougbarton.us Tue Feb 26 11:16: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 EB28B21F8790 for ; Tue, 26 Feb 2013 11:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVm9x1g8+JMO for ; Tue, 26 Feb 2013 11:16:48 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E821F872E for ; Tue, 26 Feb 2013 11:16:48 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:4cf6:ff8f:32c1:5210] (unknown [IPv6:2001:470:d:5e7:4cf6:ff8f:32c1:5210]) by dougbarton.us (Postfix) with ESMTPSA id 3E8BF22B22; Tue, 26 Feb 2013 19:16:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1361906208; bh=duq875mbKXnJPjaeD/Fk4u9QZis8dJta3NR4aLqW6c8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=suOlGKVsXUhr3pF5IZ9KZfSTBlqFYn/h3yB1HyRP1xpM/7yDZLb0uhGVXV8cUpjG4 aLJPjV1AahQoLKHElzTS3dWaBjIPEqLiMrDDHnf4frBcDtxFpWvI4zb6GitgLBicu2 cmu/IdoG3VBW4TVqsTOXlVKMg0aNy4N9emBAhfHo= Message-ID: <512D0A20.3060505@dougbarton.us> Date: Tue, 26 Feb 2013 11:16:48 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Owen DeLong References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 19:16:50 -0000 On 02/26/2013 11:09 AM, Owen DeLong wrote: > At least in North America, it's pretty easy to get a very large amount of IPv6 space. I think that's true pretty universally, and is likely to remain so for well past our lifetimes. :) > Being unable to obtain space is clearly not a valid reason to use longer prefixes and I certainly think that your proposed compromise is an improvement over dense-packing long prefixes. However, I have yet to hear from anyone any legitimate reason for using longer prefixes to begin with. Nobody has yet stated any benefit to doing so. People have given reasons, you just don't agree with them. :) Personally I am ambivalent, I have sympathy for the argument that we don't want to "waste" space since we thought IPv4 was "effectively infinite" at the time too. OTOH, the math on available IPv6 space is so astonishingly huge that humans literally have a difficult time understanding the amount of space we have available. Given that there are hard and fast opinions on both sides of this debate, and neither group is likely to change their mind, the compromise I propose covers all the bases. Then 10 or 20 years from now we'll have a much better idea about who was right. Doug (for those keeping score at home ...) From owen@delong.com Tue Feb 26 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 4A6C221F8900 for ; Tue, 26 Feb 2013 11:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epdPMP2W77eF for ; Tue, 26 Feb 2013 11:46:10 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1887521F88C1 for ; Tue, 26 Feb 2013 11:46:09 -0800 (PST) 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 r1QJg80Z011515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 11:42:08 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1QJg80Z011515 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361907728; bh=MmEFX/nj0L3tDm/OoJd3cIdcraA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jJLG8NIkmTusuXa2I59qnK2V5ujT4nG/0eB4Akay/1caK9QNMJA5LyfREBA+/xgXw dSIo824vqFx6wB4dnUqvyS8G3j4brnthzatybdz62nQBI7pBAEPxGNWMF/E8d7bwAW ml4BBNbe+4H7cXPGO2AQFygY5mWkEAW484NUGLdM= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <512D0A20.3060505@dougbarton.us> Date: Tue, 26 Feb 2013 11:42:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 26 Feb 2013 11:42:08 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 19:46:11 -0000 On Feb 26, 2013, at 11:16 , Doug Barton wrote: > On 02/26/2013 11:09 AM, Owen DeLong wrote: >> At least in North America, it's pretty easy to get a very large = amount of IPv6 space. >=20 > I think that's true pretty universally, and is likely to remain so for = well past our lifetimes. :) >=20 >> Being unable to obtain space is clearly not a valid reason to use = longer prefixes and I certainly think that your proposed compromise is = an improvement over dense-packing long prefixes. However, I have yet to = hear from anyone any legitimate reason for using longer prefixes to = begin with. Nobody has yet stated any benefit to doing so. >=20 > People have given reasons, you just don't agree with them. :) >=20 I literally haven't seen anything that is even alleged to be a benefit = of longer prefixes. Here's what I've seen: Comcast: "Covers buggy hardware/software" I've already agreed that I accept this. However, that's = /128s and /64s. Not /60s and /56s vs. /48s. A few others: "We shouldn't give it out liberally because we'll run = out. Have we learned nothing from IPv4?" This isn't a benefit. This is fear mongering. The = solution to this is, IMHO, Let's try it liberal until we're 50 years down the road or until 2000::/3 is fully = allocated to RIRs, whichever comes first. If we fully allocate 2000::/3 to RIRs in less than 50 = years, then we have plenty of time to talk about more conservative ways to allocate the next /3 and = we still have 4 other /3s (1/2 of the total IPv6 address space) that remains untouched. If you've seen someone stating an actual benefit (outside of "it covers = for the bugs"), then please share... I really have literally missed it. = If someone can show a truly valid reason for longer prefixes that = involves either a benefit or a real downside to shorter ones, I really = am open to being convinced. > Personally I am ambivalent, I have sympathy for the argument that we = don't want to "waste" space since we thought IPv4 was "effectively = infinite" at the time too. OTOH, the math on available IPv6 space is so = astonishingly huge that humans literally have a difficult time = understanding the amount of space we have available. I have a certain amount of sympathy for "don't waste space". However, = providing bits to allow radical new autoconfiguration mechanisms for = autonomous topological hierarchies in the residential environment is not = a waste IMHO. Providing enough bits that residential end users are not = treated as second class citizens for addressing purposes compared to = businesses is not a waste IMHO. If we define "wasted addresses" as "addresses not utilized to number = hosts", then, no matter what we do, IPv6 is designed for and depends on = huge amounts of waste. However, if we seriously consider the numbers, we = see that the waste of giving out /48s to everyone still doesn't really = have much of an impact. UN's highest estimate of world population for 2100 is just under = 16,000,000,000 (16 Billion). Let's assume that every single person = represents a household that needs a /48 and that each person also has = their own business that also needs a /48 (obviously a ridiculous = over-estimation). That's a total need for 32 Billion (32,000,000,000) = /48s. 2000::/3 provides 2^45 or 35,184,372,088,832, so we would still = have more than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can = number ISPs, infrastructure, servers, etc. That's still within 1/8th of the total IPv6 address space. > Given that there are hard and fast opinions on both sides of this = debate, and neither group is likely to change their mind, the compromise = I propose covers all the bases. Then 10 or 20 years from now we'll have = a much better idea about who was right. As I said, your compromise is better than what is being done today. = However, both have distinct drawbacks and there are at least potential = benefits to providing /48s (or at least /48s on request). Since there = are no drawbacks (potential or actual) to issuing shorter prefixes, I = really am at a loss as to how the other side justifies its position. Owen From markzzzsmith@yahoo.com.au Tue Feb 26 12:34: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 60BED21F88E6 for ; Tue, 26 Feb 2013 12:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxDKamge9B2O for ; Tue, 26 Feb 2013 12:34:34 -0800 (PST) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with SMTP id 3D88721F8890 for ; Tue, 26 Feb 2013 12:34:34 -0800 (PST) Received: from [98.139.212.147] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 26 Feb 2013 20:34:33 -0000 Received: from [98.139.212.232] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 26 Feb 2013 20:34:33 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 26 Feb 2013 20:34:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 637016.33085.bm@omp1041.mail.bf1.yahoo.com Received: (qmail 79426 invoked by uid 60001); 26 Feb 2013 20:34:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1361910873; bh=y6gH6gNPjZdYi+d8xQFSX48JcT3R04YZd4dbpDBnytA=; 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=19sfM13tdRNw/DhE3RJeK02PIKUvHNIHfTZF/yUCX3hpbNle19/n440hJk8C6u7oiJZgbLFAPZBZ/wrKSD1C0uoCFdudnPkuEtLilxgxz/wDTfLUoGB3ChJHWHcR1ObPZ7DrUsJMsuDoBViWmUaTQCN63P1N7s4tPMyr4I+zDDI= 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=LDmFVUuiRsA0/a3S4HrrQryt/SPb9Ac/3cmtGq1WXO3kj+9o2lR9NeMsY9Bs90UY+IjcdcZNc5FXNqC/7ws6vCN0HX6yAM1TUpxaaliXHntTnJnVaRXOFrBWuaQHzXDyIlyNDVfJ4hol9EtCiz3p/KHwU9XW1qE7v1EQ+sGZZBw=; X-YMail-OSG: BO43t_QVM1mM5KX2avIH5Y.WJ3tCS9ay0Zms5nY0c7aAncp xoe12iQHGKXLAJx4WEzAFX6N4P2pbAN7scj2lCGh1faPZN8Bn1PUSG8.AD78 CzZuKpkthHoXuPKyu3bL8J2kgQEoqkjgtVgCAwveeSi60u7sVk5IieO0nFce Nb2ND3oMDaweJnH.iPCbse8xRn_V.Yn9ZI9MJTSGBNXX3_PpJIAlvAQzssM5 q0vEHxwsMsh.lLoJypL4IL.4Wg9gBgckZXjKtadO9mr58pIiJMSKL89JNokT cySQmyjgDwFeHXSeFudiCm3YcB6Exl1TXbENfncoKBk52VpzPib1taSuAu7t DW3l91VDkX946fOl5fNzzPHzvHFXkM0AEurIAccKbyN.TU8..3wYuf9fOhMi oR6pRnZsfHgFqTyYWcfI4WPkdPbv4Vfm1T_X7lZFmhkJbgCTTGL14I0uBSLW Vb6np.IpknccnLfnv.ywM6C3W2JH0IvebrUn8VdU9oo8XKgeaCcxbmRbZoSo GQd6o7etlWfme8DmQkhp7A23HCooC Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Tue, 26 Feb 2013 12:34:33 PST X-Rocket-MIMEInfo: 001.001, SGksCgpJJ3ZlIGhhZCBhIHF1aWNrIHJlYWQgdGhvdWdoLCBJJ2xsIHRyeSB0byBkbyBhIHRob3JvdWdoIG9uZSBpbiB0aGUgbmV4dCB3ZWVrIG9yIHNvLgoKVGhhbmtzIGZvciB3cml0aW5nIHRoaXMsIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCBkb2luZyBzb21ldGhpbmcgc2ltaWxhciBvdmVyIHRoZSBsYXN0IGZldyBtb250aHMgc2luY2UsIElJUkMsIEkgaGVhcmQgYWJvdXQgV2luZG93cyA3IGludmFsaWRhdGluZyBJUHY2IGFkZHJlc3NlcyBsZWFybmVkIHZpYSBESENQdjYgd2hlbiBTTEFBQyB3YXMgZW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.135.514 References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> Message-ID: <1361910873.78397.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Tue, 26 Feb 2013 12:34:33 -0800 (PST) From: Mark Smith To: "Liubing \(Leo\)" , "ipv6@ietf.org" , "v6ops@ietf.org" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "renum@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:34:37 -0000 Hi,=0A=0AI've had a quick read though, I'll try to do a thorough one in the= next week or so.=0A=0AThanks for writing this, I've been thinking about do= ing something similar over the last few months since, IIRC, I heard about W= indows 7 invalidating IPv6 addresses learned via DHCPv6 when SLAAC was enab= led and DHCPv6 was disabled on a link.=0A=0AA few thoughts I've had which m= ay be useful -=0A=0AFirstly, I came to realise that the mistake being made = by Windows 7 was the assumption that the aging of the assigned IPv6 address= es was tightly coupled to the DHCPv6 session state, meaning that if DHCPv6 = went away, so would the assigned addresses. This is generally the way DHCPv= 4 has worked. However, in IPv6/DHCPv6, it seems the address lifetime values= in the IA_NA are not coupled to the T1 and T2 times, so if DHCPv6 goes awa= y (perhaps because the M bit was switched off in a latter RA), the configur= ed IPv6 addresses should be left to age out as per their preferred and vali= d lifetimes.=0A=0AThe other thing I noticed was that the M RA flag and the = PIO A flags aren't mutually exclusive - I couldn't find any text in RFC4861= that says if the M bit is switched on, the PIO A flags must be switched of= f and vice-versa. So that suggests that the DHCPv6 and SLAAC can co-exist, = and I think that is quite reasonable if you're transitioning a link from DH= CPv6 to SLAAC address configuration or vice-versa.=0A=0AThinking about it m= ore, I came realise that DHCPv6 and SLAAC are _address configuration_ metho= ds, but are not address aging methods - IPv6 takes care of address aging vi= a it's preferred and valid aging mechanisms, regardless of the address conf= iguration method. Static assignment is also just an address configuration m= ethod, although typically the addresses don't age out, but only because the= y're normally set to infinity. Perhaps in the future there might be other a= ddress configuration methods.=0A=0AI didn't seem to be able to find an RFC = that made it clear that address configuration and address aging are quite s= eparate, so perhaps this ID could be the one.=0A=0ARegarding this text:=0A= =0A'For the host behavior, there is an explicit rule in the SLAAC specifica= tion [RFC4862]: "If the Autonomous flag is not set, silently ignore the Pre= fix Information option."'=0A=0AI think RFC5942, "IPv6 Subnet Model: The Rel= ationship between Links and Subnet Prefixes." updates that advice, as the P= IO option is used to indicates which prefix/range of addresses are on-link,= via the PIO O bit, even if the PIO A bit is switched off.=0A=0ABest regard= s,=0AMark.=0A=0A>________________________________=0A> From: Liubing (Leo) <= leo.liubing@huawei.com>=0A>To: "ipv6@ietf.org" ; "v6ops@ietf= .org" =0A>Cc: "renum@ietf.org" =0A>Sent: = Tuesday, 26 February 2013 6:14 PM=0A>Subject: SLAAC/DHCPv6 addr-conf operat= ional gaps=0A> =0A>Hi, 6man & v6ops=0A>=0A>We submitted a new draft to disc= uss the SLAAC/DHCPv6 interaction gaps.=0A>=0A>As we know there are several = flags in RA messages regarding with the host configuration behavior, which = are A (Autonomous) flag, M (Managed) flag, and O (Otherconfig) flag.=0A>For= some reason, the host behavior of interpreting the flags is ambiguous in t= he standard (mainly RFC4862). I presented a draft discussing M flag behavio= r in 6man @ietf84, and there were some feedbacks arguing the same issue. Th= is draft analyzed all the three flags, and provided test result of current = implementations, it showed the behavior of different mainstream desktop OSe= s have varied. The ambiguous and variation might cause operational problems= , such as renumbering (used to discuss in 6renum WG and been documented in = the WG drafts), cold start problem, and management gaps .etc.=0A>=0A>Your r= eview and comments would be appreciated very much. =0A>=0A>All the best,=0A= >Bing=0A>=0A>> -----Original Message-----=0A>> From: internet-drafts@ietf.o= rg [mailto:internet-drafts@ietf.org]=0A>> Sent: Monday, February 25, 2013 5= :52 PM=0A>> To: Liubing (Leo)=0A>> Cc: rbonica@juniper.net=0A>> Subject: Ne= w Version Notification for=0A>> draft-liu-bonica-dhcpv6-slaac-problem-01.tx= t=0A>> =0A>> =0A>> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-prob= lem-01.txt=0A>> has been successfully submitted by Bing Liu and posted to t= he=0A>> IETF repository.=0A>> =0A>> Filename:=A0=A0=A0=A0=A0draft-liu-bonic= a-dhcpv6-slaac-problem=0A>> Revision:=A0=A0=A0=A0=A001=0A>> Title:=A0=A0=A0= =A0=A0=A0=A0=A0DHCPv6/SLAAC Address Configuration Interaction Problem=0A>>= Statement=0A>> Creation date:=A0=A0=A0=A0=A02013-02-25=0A>> Group:=A0=A0= =A0 =A0=A0=A0=A0=A0Individual Submission=0A>> Number of pages: 12=0A>> URL:= =0A>> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-pro= blem-=0A>> 01.txt=0A>> Status:=0A>> http://datatracker.ietf.org/doc/draft-l= iu-bonica-dhcpv6-slaac-problem=0A>> Htmlized:=0A>> http://tools.ietf.org/ht= ml/draft-liu-bonica-dhcpv6-slaac-problem-01=0A>> Diff:=0A>> http://www.ietf= .org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-problem-01=0A>> =0A>> Abs= tract:=0A>>=A0 =A0 This document analyzes the host behavior of DHCPv6/SLAAC= interaction=0A>>=A0 =A0 issue. It reviews the standard definition of the h= ost behaviors and=0A>>=A0 =A0 provides the test results of current mainstre= am implementations. Some=0A>>=A0 =A0 potential operational gaps of the inte= raction are also described.=0A>> =0A>> =0A>> =0A>> =0A>> The IETF Secretari= at=0A>=0A>-----------------------------------------------------------------= ---=0A>IETF IPv6 working group mailing list=0A>ipv6@ietf.org=0A>Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A>---------------= -----------------------------------------------------=0A>=0A>=0A> From john.mann@monash.edu Tue Feb 26 15:42: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 AC3D221F8621 for ; Tue, 26 Feb 2013 15:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKuzU6OumMLd for ; Tue, 26 Feb 2013 15:42:25 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 582F021F8618 for ; Tue, 26 Feb 2013 15:42:25 -0800 (PST) Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKUS1IX8qjDs8zRFQ6Wa3Wp1IFM83Q+SHI@postini.com; Tue, 26 Feb 2013 15:42:25 PST Received: by mail-oa0-f71.google.com with SMTP id o6so27001653oag.6 for ; Tue, 26 Feb 2013 15:42:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=JclFr3biFffruSKJQ1f4qFT7tpvGQ0lKp3iIbmynbBM=; b=HE0JNuKL4Le89xhp0WvlKnaoWNBgq4SG5Q5Z9BN7jT2oPQ4T5VlzjQAWmQ1NuMDamM X7vXKonnBauUDrH8jSvpZzNWdfm5YBMeGyGrdcI58U1ZTU4x+BCfm9v8qhvzGNAFBWhF yfKN2+9Vqm6HC9OgNNol0nMCxcvV+jUyPimv155nZ7o8GnDtNNAn4Fy/bINVqUgyAkg0 2eBX0wpB9cB+zg7eX+A7RdVrQelaX08yf9Rn4w7/aABpxHbrvmV4yggU+3KfRZcQTAMt 8q/c6XJ/8TJFou6dR8mjcRXBlCbFuYCCorVul062P6uCrUmHRBUa6TYSW3ZrK5ab1/XI gEeg== X-Received: by 10.60.30.33 with SMTP id p1mr147611oeh.66.1361922143516; Tue, 26 Feb 2013 15:42:23 -0800 (PST) X-Received: by 10.60.30.33 with SMTP id p1mr147602oeh.66.1361922143362; Tue, 26 Feb 2013 15:42:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.24.226 with HTTP; Tue, 26 Feb 2013 15:42:03 -0800 (PST) In-Reply-To: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> From: John Mann Date: Wed, 27 Feb 2013 10:42:03 +1100 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=e89a8ff25172913b9b04d6a935b5 X-Gm-Message-State: ALoCoQmncmJzcBpDNmZuiUgWObnqncXORxv6NmJVvCA22DU/eDIni1K0Rkk6Rpo8ljf4PPEHuDodPtbdmOu52bFwVfwguPAnqP8oxAx+lfBmPAgiYw2xi5bffscvvB1+hxOUwRH8UY8u Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Feb 2013 23:42:26 -0000 --e89a8ff25172913b9b04d6a935b5 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 27 February 2013 06:42, Owen DeLong wrote: > > On Feb 26, 2013, at 11:16 , Doug Barton wrote: > > > On 02/26/2013 11:09 AM, Owen DeLong wrote: > >> At least in North America, it's pretty easy to get a very large amount > of IPv6 space. > > > > I think that's true pretty universally, and is likely to remain so for > well past our lifetimes. :) > > > >> Being unable to obtain space is clearly not a valid reason to use > longer prefixes and I certainly think that your proposed compromise is an > improvement over dense-packing long prefixes. However, I have yet to hear > from anyone any legitimate reason for using longer prefixes to begin with. > Nobody has yet stated any benefit to doing so. > > > > People have given reasons, you just don't agree with them. :) > > > > I literally haven't seen anything that is even alleged to be a benefit of > longer prefixes. > > Here's what I've seen: > > Comcast: "Covers buggy hardware/software" > I've already agreed that I accept this. However, that's > /128s and /64s. Not /60s and /56s vs. /48s. > > A few others: > "We shouldn't give it out liberally because we'll run out. > Have we learned nothing from IPv4?" > > This isn't a benefit. This is fear mongering. The solution > to this is, IMHO, Let's try it liberal until > we're 50 years down the road or until 2000::/3 is fully > allocated to RIRs, whichever comes first. > If we fully allocate 2000::/3 to RIRs in less than 50 > years, then we have plenty of time to talk > about more conservative ways to allocate the next /3 and > we still have 4 other /3s (1/2 of the > total IPv6 address space) that remains untouched. > > If you've seen someone stating an actual benefit (outside of "it covers > for the bugs"), then please share... I really have literally missed it. If > someone can show a truly valid reason for longer prefixes that involves > either a benefit or a real downside to shorter ones, I really am open to > being convinced. > There is a small but non-negligible matter of cost. For example, at APNIC, based around 2^24 customers a /32 costs AUD 1,994 == http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calculate and a /24 costs AUD 16,267 == http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculate So, the difference between offering /56's to home users and /48's to home users could be $14k per year. Looking at it a different way, for AUD 1,994, they could provide 2^24 /56's _or_ 2^16 /48's. Somebody would have to sign off on the extra cost, or reduced customer goal. > Personally I am ambivalent, I have sympathy for the argument that we > don't want to "waste" space since we thought IPv4 was "effectively > infinite" at the time too. OTOH, the math on available IPv6 space is so > astonishingly huge that humans literally have a difficult time > understanding the amount of space we have available. > > I have a certain amount of sympathy for "don't waste space". However, > providing bits to allow radical new autoconfiguration mechanisms for > autonomous topological hierarchies in the residential environment is not a > waste IMHO. Providing enough bits that residential end users are not > treated as second class citizens for addressing purposes compared to > businesses is not a waste IMHO. > > If we define "wasted addresses" as "addresses not utilized to number > hosts", then, no matter what we do, IPv6 is designed for and depends on > huge amounts of waste. However, if we seriously consider the numbers, we > see that the waste of giving out /48s to everyone still doesn't really have > much of an impact. > > UN's highest estimate of world population for 2100 is just under > 16,000,000,000 (16 Billion). Let's assume that every single person > represents a household that needs a /48 and that each person also has their > own business that also needs a /48 (obviously a ridiculous > over-estimation). That's a total need for 32 Billion (32,000,000,000) /48s. > 2000::/3 provides 2^45 or 35,184,372,088,832, so we would still have more > than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can > number ISPs, infrastructure, servers, etc. > > That's still within 1/8th of the total IPv6 address space. I don't think it is a simple matter of raw numbers. Any address plan will have unallocated space, internal fragmentation etc. >From your numbers -- 2^35 /48's out of 2^45 possible /48's allows for 10 bits of slack. If we assume the address plan is hierarchical on nibble boundaries, then that may allow for 3 levels of hierarchy with 2/16ths or 3/16ths utilisation at each level. RIR -> ISP; ISP -> region; region -> customer With care, seems doable. > Given that there are hard and fast opinions on both sides of this debate, > and neither group is likely to change their mind, the compromise I propose > covers all the bases. Then 10 or 20 years from now we'll have a much better > idea about who was right. > > As I said, your compromise is better than what is being done today. > However, both have distinct drawbacks and there are at least potential > benefits to providing /48s (or at least /48s on request). Since there are > no drawbacks (potential or actual) to issuing shorter prefixes, I really am > at a loss as to how the other side justifies its position. > > Owen Thanks, John --e89a8ff25172913b9b04d6a935b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 27 February 2013 06:42, Owen DeLon= g <owen@delong.com> wrote:

On Feb 26, 2013, at 11:16 , Doug Barton <dougb@dougbarton.us> wrote:

> On 02/26/2013 11:09 AM, Owen DeLong wrote:
>> At least in North America, it's pretty easy to get a very larg= e amount of IPv6 space.
>
> I think that's true pretty universally, and is likely to remain so= for well past our lifetimes. :)
>
>> Being unable to obtain space is clearly not a valid reason to use = longer prefixes and I certainly think that your proposed compromise is an i= mprovement over dense-packing long prefixes. However, I have yet to hear fr= om anyone any legitimate reason for using longer prefixes to begin with. No= body has yet stated any benefit to doing so.
>
> People have given reasons, you just don't agree with them. :)
>

I literally haven't seen anything that is even alleged to be a be= nefit of longer prefixes.

Here's what I've seen:

=A0 =A0 =A0 =A0 Comcast: =A0 =A0 =A0 =A0"Covers buggy hardware/softwar= e"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I've already agreed that I accept this.= However, that's /128s and /64s. Not /60s and /56s vs. /48s.

=A0 =A0 =A0 =A0 A few others:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "We shouldn't give it out liberall= y because we'll run out. Have we learned nothing from IPv4?"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This isn't a benefit. This is fear mong= ering. The solution to this is, IMHO, Let's try it liberal until
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 we're 50 years down the road or until 2= 000::/3 is fully allocated to RIRs, whichever comes first.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If we fully allocate 2000::/3 to RIRs in le= ss than 50 years, then we have plenty of time to talk
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 about more conservative ways to allocate th= e next /3 and we still have 4 other /3s (1/2 of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 total IPv6 address space) that remains unto= uched.

If you've seen someone stating an actual benefit (outside of "it c= overs for the bugs"), then please share... I really have literally mis= sed it. If someone can show a truly valid reason for longer prefixes that i= nvolves either a benefit or a real downside to shorter ones, I really am op= en to being convinced.

There is a small but non-negligible matter= of cost.

For example, at APNIC, based around 2^24= customers
a /32 costs AUD 1,994 =3D=3D ht= tp://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&actio= n=3DCalculate
and a /24 costs AUD 16,267 =3D=3D http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6= =3D%2F24&action=3DCalculate

So, the dif= ference between offering /56's to home users and /48's to home user= s could be $14k per year.
Looking at it a d= ifferent way, for AUD 1,994, they could provide 2^24 /56's _or_ 2^16 /4= 8's.

Somebody wo= uld have to sign off on the extra cost, or reduced customer goal.

> Personally I am ambivalent, I have sympathy for the argument that we d= on't want to "waste" space since we thought IPv4 was "ef= fectively infinite" at the time too. OTOH, the math on available IPv6 = space is so astonishingly huge that humans literally have a difficult time = understanding the amount of space we have available.

I have a certain amount of sympathy for "don't waste space&q= uot;. However, providing bits to allow radical new autoconfiguration mechan= isms for autonomous topological hierarchies in the residential environment = is not a waste IMHO. Providing enough bits that residential end users are n= ot treated as second class citizens for addressing purposes compared to bus= inesses is not a waste IMHO.

If we define "wasted addresses" as "addresses not utilized t= o number hosts", then, no matter what we do, IPv6 is designed for and = depends on huge amounts of waste. However, if we seriously consider the num= bers, we see that the waste of giving out /48s to everyone still doesn'= t really have much of an impact.

UN's highest estimate of world population for 2100 is just under 16,000= ,000,000 (16 Billion). Let's assume that every single person represents= a household that needs a /48 and that each person also has their own busin= ess that also needs a /48 (obviously a ridiculous over-estimation). That= 9;s a total need for 32 Billion (32,000,000,000) /48s. 2000::/3 provides 2^= 45 or 35,184,372,088,832, so we would still have more
than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can number= ISPs, infrastructure, servers, etc.

That's still within 1/8th of the total IPv6 address space.
=

I don't think it is a simple matter of raw numbers.=
Any address plan will have unallocated space, internal fragmenta= tion etc.

From your numbers -- 2^35 /48's out of 2^45 possibl= e /48's allows for 10 bits of slack.

If we ass= ume the address plan is=A0hierarchical=A0on nibble boundaries, then that ma= y allow for 3 levels of=A0hierarchy with 2/16ths or 3/16ths utilisation=A0a= t each level.
=A0 RIR -> ISP; ISP -> region; region -> customer
W= ith care, seems doable.

=
> Given that there are hard and fast opinions on both sides of this deba= te, and neither group is likely to change their mind, the compromise I prop= ose covers all the bases. Then 10 or 20 years from now we'll have a muc= h better idea about who was right.

As I said, your compromise is better than what is being done today. H= owever, both have distinct drawbacks and there are at least potential benef= its to providing /48s (or at least /48s on request). Since there are no dra= wbacks (potential or actual) to issuing shorter prefixes, I really am at a = loss as to how the other side justifies its position.

Owen

Thanks,
=A0 = =A0 John=A0
--e89a8ff25172913b9b04d6a935b5-- From ales.vizdal@t-mobile.cz Tue Feb 26 16:01: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 7798321F86B2 for ; Tue, 26 Feb 2013 16:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cvjRkyKok56 for ; Tue, 26 Feb 2013 16:01:12 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id C4F7C21F86AD for ; Tue, 26 Feb 2013 16:01:11 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 7D1E228581D; Wed, 27 Feb 2013 01:01:09 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 27 Feb 2013 01:01:09 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Wed, 27 Feb 2013 00:59:29 +0100 Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks Thread-Index: Ac4USkmaw2t7wvFQRJOgXxgmNFpnHgAMuuuA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> References: <512CF682.8030307@gmail.com> In-Reply-To: <512CF682.8030307@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 00:01:13 -0000 > > Correct. NAT44 is good enough if you can number users from RFC1918. > > If users (including M2M ...) and infrastructure exceed RFC1918 > > space >=20 > If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and > 192.168.0.0/16) then there is this 100.64.0.0/10 new space from RFC6598. Unfortunately, 40-60 million customer base cannot be addressed by RFC1918/1= 0.64/10 address space. Ales From lorenzo@google.com Tue Feb 26 16: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 10B2B21F8675 for ; Tue, 26 Feb 2013 16:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrqEHfFIWN0H for ; Tue, 26 Feb 2013 16:30:46 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 843DF21F8600 for ; Tue, 26 Feb 2013 16:30:46 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so6735759oag.34 for ; Tue, 26 Feb 2013 16:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aX5DtUrAaXqQilcArvJF/e0OnXXD3iQLDtbYmIrKaok=; b=M9uOrj3H7i9xTIl4B/jCESLm/CYLbYKPAl6+kI0o9FB3HBNzxrSHaoauMGhPl/zFch R8ER5TJxqHBY9OE5btSGO5tnof01MDLdhpDyOX0FMG7C9zsocgPbRDdg4B696uwHCUnF cRcMk85pthLtpLTrodmwgNSukUo6FY9T4XMjqFa+2NrskoO+7Sn3yClHTxrkXl/DWiYc ba7/8CAin+swMikWIcyNS/TMhxMzYal6/k4D/52glrC4IQleFeLlliL/adQUbbVxPdik BnKFWM57mooG8aSv1kwUlDUE5B6tv9gxYSU9UCKHBKAZlcuHgtxEp7LrGqINYzdXRLQA EiQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=aX5DtUrAaXqQilcArvJF/e0OnXXD3iQLDtbYmIrKaok=; b=OGTW+53tpsVPyu2Rx+Pw7VIVp9PWZS36fN027++rNrwYqIEDFbuFj/UC1X0QCmmlse FA8x9lnDVrj7egvoXhT8AcU1I83XvwFp6zS/TjZses7yuqYUJ8Saa5A37ZfmCBejBCpy zvuSzezJGpnG4PwHr9LIL2DrIA1JOA0Z/yzDTJJj6JRQLKX4RRviHQKWhFadc084NDc9 el3n60gHnny3NoE0TR2RMeGSioFeQrzC9cQqS6/cNeKLbJ2p/MmF40MB9GkqFQFPT6jh 6q6jMzkEYIpbqMBcPwPNCHukY5DaBGuBanmpbGlwTNYF21PW4mLxiLUxos6Ex79l4kAJ BnGA== X-Received: by 10.60.6.199 with SMTP id d7mr165260oea.137.1361925046107; Tue, 26 Feb 2013 16:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Tue, 26 Feb 2013 16:30:26 -0800 (PST) In-Reply-To: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> From: Lorenzo Colitti Date: Wed, 27 Feb 2013 09:30:26 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=e89a8fb1fd7495a6f304d6a9e23b X-Gm-Message-State: ALoCoQk8ndV4Iabl4dWoKV8iNFJJfJ0UZDzPOMOe82jc0NS6h4w0p41rroP1ZjG4S4x2icyEkgv2dT3wLZiuALDmFsdyHhFG/niowgWlbHpAmxyzfoNFR1A7Il5uLMUyTZEWZUvu8VeUNqT+SkRoildnXS4xhwT81snIbOcuZiuwKsqny6s4GH9v7ONE24LG1dMknFnknojx Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 00:30:47 -0000 --e89a8fb1fd7495a6f304d6a9e23b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 27, 2013 at 4:42 AM, Owen DeLong wrote: > If you've seen someone stating an actual benefit (outside of "it covers > for the bugs"), then please share... I really have literally missed it. If > someone can show a truly valid reason for longer prefixes that involves > either a benefit or a real downside to shorter ones, I really am open to > being convinced. > Note that a least as far as my message went, I wasn't trying to convince you that assigning longer prefixes is right. I was trying to convince you that that it is what happening in the real world. --e89a8fb1fd7495a6f304d6a9e23b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 27, 2013 at 4:42 AM, Owen DeLong <owen@delong.c= om> wrote:
If you've seen so= meone stating an actual benefit (outside of "it covers for the bugs&qu= ot;), then please share... I really have literally missed it. If someone ca= n show a truly valid reason for longer prefixes that involves either a bene= fit or a real downside to shorter ones, I really am open to being convinced= .

Note that a least as far as my messa= ge went, I wasn't trying to convince you that assigning longer prefixes= is right. I was trying to convince you that that it is what happening in t= he real world.
--e89a8fb1fd7495a6f304d6a9e23b-- From owen@delong.com Tue Feb 26 16:32: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 8527821F8675 for ; Tue, 26 Feb 2013 16:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ftzogo6pV+r for ; Tue, 26 Feb 2013 16:32:27 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7A921F85C6 for ; Tue, 26 Feb 2013 16:32:26 -0800 (PST) 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 r1R0PxbS021882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 16:26:00 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1R0PxbS021882 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361924761; bh=aDqu0GDsxQNGocmQhsh45drSFVo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=YZFC7GUxFUVDQLPSDF21T1Ks9gZUiprb1lJgRwIkVQnLn+IPem05e+6wLHmlmuNiS T32Q1ZE9R2BSroRzwVm6xdToTqzJDt4+GjAluKc4Jn5Fk2lkeQZlfH6Gyhfbtvam76 I86nvvtiydThqo2u8qTVWTLR4Kw3QTeP7pzIiGss= Content-Type: multipart/alternative; boundary="Apple-Mail=_9F3F1426-7671-4542-BA01-266B4B83DB05" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Tue, 26 Feb 2013 16:25:59 -0800 Message-Id: <9BE44330-52E6-47D8-B6AD-0561391C25AC@delong.com> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> To: John Mann X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 26 Feb 2013 16:26:01 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 00:32:31 -0000 --Apple-Mail=_9F3F1426-7671-4542-BA01-266B4B83DB05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 26, 2013, at 3:42 PM, John Mann wrote: > Hi, >=20 > On 27 February 2013 06:42, Owen DeLong wrote: >=20 > On Feb 26, 2013, at 11:16 , Doug Barton wrote: >=20 > > On 02/26/2013 11:09 AM, Owen DeLong wrote: > >> At least in North America, it's pretty easy to get a very large = amount of IPv6 space. > > > > I think that's true pretty universally, and is likely to remain so = for well past our lifetimes. :) > > > >> Being unable to obtain space is clearly not a valid reason to use = longer prefixes and I certainly think that your proposed compromise is = an improvement over dense-packing long prefixes. However, I have yet to = hear from anyone any legitimate reason for using longer prefixes to = begin with. Nobody has yet stated any benefit to doing so. > > > > People have given reasons, you just don't agree with them. :) > > >=20 > I literally haven't seen anything that is even alleged to be a benefit = of longer prefixes. >=20 > Here's what I've seen: >=20 > Comcast: "Covers buggy hardware/software" > I've already agreed that I accept this. However, = that's /128s and /64s. Not /60s and /56s vs. /48s. >=20 > A few others: > "We shouldn't give it out liberally because we'll run = out. Have we learned nothing from IPv4?" >=20 > This isn't a benefit. This is fear mongering. The = solution to this is, IMHO, Let's try it liberal until > we're 50 years down the road or until 2000::/3 is = fully allocated to RIRs, whichever comes first. > If we fully allocate 2000::/3 to RIRs in less than 50 = years, then we have plenty of time to talk > about more conservative ways to allocate the next /3 = and we still have 4 other /3s (1/2 of the > total IPv6 address space) that remains untouched. >=20 > If you've seen someone stating an actual benefit (outside of "it = covers for the bugs"), then please share... I really have literally = missed it. If someone can show a truly valid reason for longer prefixes = that involves either a benefit or a real downside to shorter ones, I = really am open to being convinced. >=20 > There is a small but non-negligible matter of cost. >=20 > For example, at APNIC, based around 2^24 customers > a /32 costs AUD 1,994 =3D=3D = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&action=3DC= alculate > and a /24 costs AUD 16,267 =3D=3D = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F24&action=3DC= alculate >=20 Admittedly, some RIRs have (unfortunate) linear pricing models, but, = let's look at the difference in cost per subscriber. A /24 is 16.7 = Million subscribers at /48 (and a /32 is 16.7 million at /56), so we're = dallying about a difference per subscriber of $0.00085073711 per subscriber per year. If you ask me, I'll happily pay an extra $0.01 per year to cover = appropriate addressing for me and my closest 99+ neighbors. If you want to argue that at the low end of customers, you can handle = ~65,000 customers from your /32 getting /48s before you have to incur any cost above your base /32, so = that's still only $0.22 per customer per year. Do you really think that most customers would be sensitive to = a $0.25/year increase (<$0.03/month) increase to their internet bill? I bet most of them wouldn't notice the = difference between $19.95 and $19.98. > So, the difference between offering /56's to home users and /48's to = home users could be $14k per year. > Looking at it a different way, for AUD 1,994, they could provide 2^24 = /56's _or_ 2^16 /48's. >=20 > Somebody would have to sign off on the extra cost, or reduced customer = goal. >=20 Yes, look at the above math on the actual difference that would need = sign-off. I bet the customers would accept the difference. Heck, even if you want to mark it up 10x, the worst case price increase = is $2.50/year. As such, I think that the cost argument doesn't really hold water. > > Personally I am ambivalent, I have sympathy for the argument that we = don't want to "waste" space since we thought IPv4 was "effectively = infinite" at the time too. OTOH, the math on available IPv6 space is so = astonishingly huge that humans literally have a difficult time = understanding the amount of space we have available. >=20 > I have a certain amount of sympathy for "don't waste space". However, = providing bits to allow radical new autoconfiguration mechanisms for = autonomous topological hierarchies in the residential environment is not = a waste IMHO. Providing enough bits that residential end users are not = treated as second class citizens for addressing purposes compared to = businesses is not a waste IMHO. >=20 > If we define "wasted addresses" as "addresses not utilized to number = hosts", then, no matter what we do, IPv6 is designed for and depends on = huge amounts of waste. However, if we seriously consider the numbers, we = see that the waste of giving out /48s to everyone still doesn't really = have much of an impact. >=20 > UN's highest estimate of world population for 2100 is just under = 16,000,000,000 (16 Billion). Let's assume that every single person = represents a household that needs a /48 and that each person also has = their own business that also needs a /48 (obviously a ridiculous = over-estimation). That's a total need for 32 Billion (32,000,000,000) = /48s. 2000::/3 provides 2^45 or 35,184,372,088,832, so we would still = have more > than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can = number ISPs, infrastructure, servers, etc. >=20 > That's still within 1/8th of the total IPv6 address space. >=20 > I don't think it is a simple matter of raw numbers. > Any address plan will have unallocated space, internal fragmentation = etc. >=20 > =46rom your numbers -- 2^35 /48's out of 2^45 possible /48's allows = for 10 bits of slack. >=20 > If we assume the address plan is hierarchical on nibble boundaries, = then that may allow for 3 levels of hierarchy with 2/16ths or 3/16ths = utilisation at each level. > RIR -> ISP; ISP -> region; region -> customer > With care, seems doable. >=20 Right=85 Also note that I think I allowed for a lot of unallocated space = and slack by assuming a world population almost 3x the current = population and then assuming that every individual represented a = complete household and a complete business. In reality, the average is = something like 4.5 people per household IIRC and a much larger = multiplier for business end-sites. We probably recover another whole = nibble there. > > Given that there are hard and fast opinions on both sides of this = debate, and neither group is likely to change their mind, the compromise = I propose covers all the bases. Then 10 or 20 years from now we'll have = a much better idea about who was right. >=20 > As I said, your compromise is better than what is being done today. = However, both have distinct drawbacks and there are at least potential = benefits to providing /48s (or at least /48s on request). Since there = are no drawbacks (potential or actual) to issuing shorter prefixes, I = really am at a loss as to how the other side justifies its position. >=20 > Owen >=20 > Thanks, > John=20 --Apple-Mail=_9F3F1426-7671-4542-BA01-266B4B83DB05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 john.mann@monash.edu> = wrote:

Hi,

On 27 February 2013 = 06:42, Owen DeLong <owen@delong.com> wrote:

On Feb 26, 2013, at 11:16 , Doug Barton <dougb@dougbarton.us> = wrote:

> On 02/26/2013 11:09 AM, Owen DeLong wrote:
>> At least in North America, it's pretty easy to get a very large = amount of IPv6 space.
>
> I think that's true pretty universally, and is likely to remain so = for well past our lifetimes. :)
>
>> Being unable to obtain space is clearly not a valid reason to = use longer prefixes and I certainly think that your proposed compromise = is an improvement over dense-packing long prefixes. However, I have yet = to hear from anyone any legitimate reason for using longer prefixes to = begin with. Nobody has yet stated any benefit to doing so.
>
> People have given reasons, you just don't agree with them. :)
>

I literally haven't seen anything that is even alleged to be a = benefit of longer prefixes.

Here's what I've seen:

        Comcast:        "Covers = buggy hardware/software"
                I've already = agreed that I accept this. However, that's /128s and /64s. Not /60s and = /56s vs. /48s.

        A few others:
                "We shouldn't = give it out liberally because we'll run out. Have we learned nothing = from IPv4?"

                This isn't a = benefit. This is fear mongering. The solution to this is, IMHO, Let's = try it liberal until
                we're 50 years = down the road or until 2000::/3 is fully allocated to RIRs, whichever = comes first.
                If we fully = allocate 2000::/3 to RIRs in less than 50 years, then we have plenty of = time to talk
                about more = conservative ways to allocate the next /3 and we still have 4 other /3s = (1/2 of the
                total IPv6 = address space) that remains untouched.

If you've seen someone stating an actual benefit (outside of "it covers = for the bugs"), then please share... I really have literally missed it. = If someone can show a truly valid reason for longer prefixes that = involves either a benefit or a real downside to shorter ones, I really = am open to being convinced.

There is a small but non-negligible = matter of cost.

For example, at APNIC, based = around 2^24 customers
a /32 costs AUD 1,994 =3D=3D http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D= &ipv6=3D%2F32&action=3DCalculate
and a /24 costs AUD 16,267 =3D=3D http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D= &ipv6=3D%2F24&action=3DCalculate


Admittedly, = some RIRs have (unfortunate) linear pricing models, but, let's look at = the difference in cost per subscriber. A /24 is 16.7 Million subscribers = at /48 (and a /32 is 16.7 million at /56), so we're dallying = about
a difference per subscriber of $0.00085073711 per = subscriber per year.

If you ask me, I'll = happily pay an extra $0.01 per year to cover appropriate addressing for = me and my
closest 99+ neighbors.

If = you want to argue that at the low end of customers, you can handle = ~65,000 customers from your /32
getting /48s before you have = to incur any cost above your base /32, so that's still only $0.22 per = customer
per year. Do you really think that most customers = would be sensitive to a $0.25/year increase = (<$0.03/month)
increase to their internet bill? I bet most = of them wouldn't notice the difference between $19.95 and = $19.98.

So, the difference between offering /56's to home = users and /48's to home users could be $14k per year.
Looking at it a different way, for AUD 1,994, they = could provide 2^24 /56's _or_ 2^16 /48's.

Somebody = would have to sign off on the extra cost, or reduced customer = goal.


Yes, look at = the above math on the actual difference that would need sign-off. I bet = the customers would
accept the = difference.

Heck, even if you want to mark it = up 10x, the worst case price increase is = $2.50/year.

As such, I think that the cost = argument doesn't really hold water.

> Personally I am ambivalent, I have sympathy for the argument that = we don't want to "waste" space since we thought IPv4 was "effectively = infinite" at the time too. OTOH, the math on available IPv6 space is so = astonishingly huge that humans literally have a difficult time = understanding the amount of space we have available.

I have a certain amount of sympathy for "don't waste space". = However, providing bits to allow radical new autoconfiguration = mechanisms for autonomous topological hierarchies in the residential = environment is not a waste IMHO. Providing enough bits that residential = end users are not treated as second class citizens for addressing = purposes compared to businesses is not a waste IMHO.

If we define "wasted addresses" as "addresses not utilized to number = hosts", then, no matter what we do, IPv6 is designed for and depends on = huge amounts of waste. However, if we seriously consider the numbers, we = see that the waste of giving out /48s to everyone still doesn't really = have much of an impact.

UN's highest estimate of world population for 2100 is just under = 16,000,000,000 (16 Billion). Let's assume that every single person = represents a household that needs a /48 and that each person also has = their own business that also needs a /48 (obviously a ridiculous = over-estimation). That's a total need for 32 Billion (32,000,000,000) = /48s. 2000::/3 provides 2^45 or 35,184,372,088,832, so we would still = have more
than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can = number ISPs, infrastructure, servers, etc.

That's still within 1/8th of the total IPv6 address = space.

I don't think it is a simple = matter of raw numbers.
Any address plan will have unallocated = space, internal fragmentation etc.

=46rom your numbers -- 2^35 /48's out of 2^45 = possible /48's allows for 10 bits of slack.

If = we assume the address plan is hierarchical on nibble = boundaries, then that may allow for 3 levels of hierarchy with = 2/16ths or 3/16ths utilisation at each level.
  RIR -> ISP; ISP -> region; region -> = customer
With care, seems = doable.


Right=85 = Also note that I think I allowed for a lot of unallocated space and = slack by assuming a world population almost 3x the current population = and then assuming that every individual represented a complete household = and a complete business. In reality, the average is something like 4.5 = people per household IIRC and a much larger multiplier for business = end-sites.  We probably recover another whole nibble = there.

> Given that there are hard and fast opinions on both sides of this = debate, and neither group is likely to change their mind, the compromise = I propose covers all the bases. Then 10 or 20 years from now we'll have = a much better idea about who was right.

As I said, your compromise is better than what is being done = today. However, both have distinct drawbacks and there are at least = potential benefits to providing /48s (or at least /48s on request). = Since there are no drawbacks (potential or actual) to issuing shorter = prefixes, I really am at a loss as to how the other side justifies its = position.

= Owen

Thanks,
 = ;   John 

= --Apple-Mail=_9F3F1426-7671-4542-BA01-266B4B83DB05-- From leo.liubing@huawei.com Tue Feb 26 19:07: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 ED03E21F8673; Tue, 26 Feb 2013 19:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQuSdv6j77QQ; Tue, 26 Feb 2013 19:07:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1A31121F8602; Tue, 26 Feb 2013 19:07:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV20200; Wed, 27 Feb 2013 03:07:08 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:06:13 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:07:07 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 11:07:02 +0800 From: "Liubing (Leo)" To: Victor Kuarsingh , "arturo.servin@gmail.com" , "ipv6@ietf.org" , "v6ops@ietf.org" Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiLnE0AgAFog0A= Date: Wed, 27 Feb 2013 03:07:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC74E@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "renum@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 03:07:12 -0000 Hi, Victor & Arturo Thanks for the comments. We do plan to write a draft of subsequence solution. But as Victor said, st= ep 1 is to see if the groups agree there are problems. So hope more people = could feed back on this. Many thanks. B.R. Bing > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] > Sent: Tuesday, February 26, 2013 9:28 PM > To: Liubing (Leo); ipv6@ietf.org; v6ops@ietf.org > Cc: renum@ietf.org > Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps >=20 > Bing, >=20 > I as able to review the draft and agree this needs to be documented and > discussed. I have had many frustrating nights dealing with my multiple > OSs at home and figuring out what behaviour I was trying to expect when > changing the upstream router's settings (M/O/A). >=20 > I think the problem space discussion within the draft should be enough to > have a preliminary discussion in the WG. I know there have been issues i= n > the past with various opinions on what the M/O bits (for example) should > or should not be used for - or how authoritative they should be. >=20 > If the groups can agree that there is in fact a problem, then I would > agree with Arturo that we can have a constructive follow-up > draft/discussion on the corrective action. >=20 > Lets get past step 1 and agree there is an issue (or not); then go down > the more sensitive path of agreeing to the corrective action. >=20 > Thanks for putting this together. >=20 > Regards, >=20 > Victor Kuarsingh >=20 >=20 >=20 > On 2013-02-26 2:14 AM, "Liubing (Leo)" wrote: >=20 > >Hi, 6man & v6ops > > > >We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. > > > >As we know there are several flags in RA messages regarding with the hos= t > >configuration behavior, which are A (Autonomous) flag, M (Managed) flag, > >and O (Otherconfig) flag. > >For some reason, the host behavior of interpreting the flags is ambiguou= s > >in the standard (mainly RFC4862). I presented a draft discussing M flag > >behavior in 6man @ietf84, and there were some feedbacks arguing the > same > >issue. This draft analyzed all the three flags, and provided test result > >of current implementations, it showed the behavior of different > >mainstream desktop OSes have varied. The ambiguous and variation might > >cause operational problems, such as renumbering (used to discuss in > >6renum WG and been documented in the WG drafts), cold start problem, > and > >management gaps .etc. > > > >Your review and comments would be appreciated very much. > > > >All the best, > >Bing > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, February 25, 2013 5:52 PM > >> To: Liubing (Leo) > >> Cc: rbonica@juniper.net > >> Subject: New Version Notification for > >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt > >> > >> > >> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt > >> has been successfully submitted by Bing Liu and posted to the > >> IETF repository. > >> > >> Filename: draft-liu-bonica-dhcpv6-slaac-problem > >> Revision: 01 > >> Title: DHCPv6/SLAAC Address Configuration Interaction Problem > >> Statement > >> Creation date: 2013-02-25 > >> Group: Individual Submission > >> Number of pages: 12 > >> URL: > >> > >>http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-probl= e > m > >>- > >> 01.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem > >> Htmlized: > >> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 > >> Diff: > >> > >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-proble= m-0 > 1 > >> > >> Abstract: > >> This document analyzes the host behavior of DHCPv6/SLAAC > interaction > >> issue. It reviews the standard definition of the host behaviors and > >> provides the test results of current mainstream implementations. > Some > >> potential operational gaps of the interaction are also described. > >> > >> > >> > >> > >> The IETF Secretariat > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- >=20 From jiangsheng@huawei.com Tue Feb 26 19: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 6365921F8726 for ; Tue, 26 Feb 2013 19:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7pdXpt0p2yc for ; Tue, 26 Feb 2013 19:22:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8D421F872E for ; Tue, 26 Feb 2013 19:22:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV21025; Wed, 27 Feb 2013 03:22:08 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:22:02 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 03:22:07 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.45]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 11:22:04 +0800 From: Sheng Jiang To: "v6ops@ietf.org" Thread-Topic: Review solicitation - draft-jiang-v6ops-semantic-prefix Thread-Index: Ac4UmZxJgYKThVy5TOeV8GZlgLA+sg== Date: Wed, 27 Feb 2013 03:22:03 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A00DFFB@szxeml545-mbx.china.huawei.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: "ian.farrer@telekom.de" , sunqiong Subject: [v6ops] Review solicitation - draft-jiang-v6ops-semantic-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 03:22:15 -0000 SGksIGFsbCB2Nm9wcywNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBkcmFmdC1q aWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgsICJBIEZyYW1ld29yayBmb3IgU2VtYW50aWMgSVB2 NiBQcmVmaXggYW5kIEdhcCBBbmFseXNpcyIgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeCkuIEl0IGlzIGRlc2NyaWJlcyBhIGZyYW1l d29yayB0aGF0IGVtYmVkcyBzZW1hbnRpY3MgaW50byBJUHY2IHByZWZpeGVzLCBzbyB0aGF0IG5l dHdvcmsgb3BlcmF0b3JzIGNhbiBlZmZpY2llbnRseSBtYW5hZ2UgdGhlaXIgbmV0d29yayB0cmFm ZmljIGJhc2VkIG9uIHRoZXNlIGV4cGxpY2l0IHNlbWFudGljcy4NCg0KVGhpcyBkb2N1bWVudCB3 YXMgb25jZSBwcmVzZW50ZWQgaW4gdjZvcHMgQCBpZXRmODQsIFZhbmNvdXZlci4gVGhlcmUgd2Fz IG1hbnkgZGlzY3Vzc2lvbnMgYW5kIGludGVyZXN0cyB3YXMgZXhwcmVzc2VkLiBBZnRlciB0aGF0 LCB3ZSBoYXZlIHJld3JpdHRlbiB0aGUgZG9jdW1lbnQgbGFyZ2VseSBhbG9uZyB3aXRoIHR3byBu ZXcgY28tYXV0aG9ycyBmcm9tIENoaW5hIFRlbGVjb20gYW5kIERldXRzY2hlIFRlbGVjb20uDQoN ClRoZSBhdXRob3JzIGJlbGlldmUgaXQgaXMgdXNlZnVsIHdvcmsgYW5kIG9wZXJhdG9ycyBjYW4g YmVuZWZpdCBmcm9tIHN1Y2ggbmV0d29yayBwbGFubmluZy9tYW5hZ2VtZW50Lg0KDQpQbGVhc2Ug cmVhZCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQuIFlvdXIgcmV2aWV3aW5nIGlzIGltcG9ydGFudCBm b3IgdXMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQuDQoNCkEgY29tcGFuaW9uIGRyYWZ0ICJVc2Ug Y2FzZSBvZiBJUHY2IHByZWZpeCBzZW1hbnRpY3MgZm9yIG9wZXJhdG9ycyIgKGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXN1bi12Nm9wcy1zZW1hbnRpYy11c2VjYXNlKSBoYXMgYWxz byBiZWVuIHN1Ym1pdHRlZCB0byB2Nm9wcyBXRy4gSXQgZGVzY3JpYmVzIG1vcmUgc3BlY2lmaWMg dXNlIGNhc2UgZm9yIHRlbGVjb21tdW5pY2F0aW9uIG9wZXJhdG9ycy4NCg0KQmVzdCByZWdhcmRz LA0KDQpTaGVuZw0K From marka@isc.org Tue Feb 26 19:23: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 5FEE421F874E for ; Tue, 26 Feb 2013 19:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkQ0Q9Q0hiDZ for ; Tue, 26 Feb 2013 19:23:02 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9CA21F871D for ; Tue, 26 Feb 2013 19:22:54 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4CE3F5F9842; Wed, 27 Feb 2013 03:22:45 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361935373; bh=2+XmykpHjO/7W/5YY4BjMV4gMe7iVO+LZ9GZ7lnZtG0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=rEFW+plBULNVH4J1k2ofeJZVShtjyn2/ZFcObO2sCgugUpzbkn5MoGNKewnsTyykf h6WW+OuIEemrvOMk8FOmRW16Ds2yWxuJAuoVcI3/t3MNv/35UZYvhIe/5ebQcampVM ksWiJOHKeHsjC1Nn5eJ5po7GLPaJn3GmFyzhf+lM= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5AF7D216C43; Wed, 27 Feb 2013 03:22:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1363930236F9; Wed, 27 Feb 2013 14:22:41 +1100 (EST) To: John Mann From: Mark Andrews References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> In-reply-to: Your message of "Wed, 27 Feb 2013 10:42:03 +1100." Date: Wed, 27 Feb 2013 14:22:41 +1100 Message-Id: <20130227032241.1363930236F9@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 03:23:04 -0000 In message , John Mann writes: > I don't think it is a simple matter of raw numbers. > Any address plan will have unallocated space, internal fragmentation etc. > > >From your numbers -- 2^35 /48's out of 2^45 possible /48's allows for 10 > bits of slack. > > If we assume the address plan is hierarchical on nibble boundaries, Which is a bad assumption. Nibble boundaries are there for rDNS. The only place, generally, without enough clue to do non-nibble boundaries in the DNS is the end customer delegation. ISP's have worked with non byte aligned delegations from RIRs for years. These is no reason to expect that this needs to change. > then that may allow for 3 levels of hierarchy with 2/16ths or 3/16ths > utilisation at each level. > RIR -> ISP; ISP -> region; region -> customer > With care, seems doable. 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 Tue Feb 26 20:01: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 9E9E421F8659 for ; Tue, 26 Feb 2013 20:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBC7XCVJ0SVT for ; Tue, 26 Feb 2013 20:01:26 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E081821F863C for ; Tue, 26 Feb 2013 20:01:25 -0800 (PST) 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 r1R40dpc025648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 20:00:39 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1R40dpc025648 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361937640; bh=ticQChhcztNfCg17qz5un/f198I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PCn0jOHfvuytzde0EFsDDl1S1AXupA8og92f+knm+CQccvTp6FpxZIegvUTgZYU9d 24WlIBUCgA9KAbtm32t2Gdp6dDDlc2PTIMnsc+7miuyNmBiM7aBEEC8PvrkASIgvC1 Qlm7cQcYSqFMrQHMEbXa2cLX75aIEDjxX6XB8K/4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130227032241.1363930236F9@drugs.dv.isc.org> Date: Tue, 26 Feb 2013 20:00:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> <20130227032241.1363930236F9@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 26 Feb 2013 20:00:40 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 04:01:27 -0000 That depends. There is value to nibble-alignment of aggregation points where it makes = sense and they are (somewhat) supported in ARIN policy at this point. Doing so does improve the human-factors aspects of network management = and the space to do so is, generally, readily available at least at one = or two levels of hierarchy. Owen On Feb 26, 2013, at 7:22 PM, Mark Andrews wrote: >=20 > In message = > , John Mann writes: >> I don't think it is a simple matter of raw numbers. >> Any address plan will have unallocated space, internal fragmentation = etc. >>=20 >>> =46rom your numbers -- 2^35 /48's out of 2^45 possible /48's allows = for 10 >> bits of slack. >>=20 >> If we assume the address plan is hierarchical on nibble boundaries, >=20 > Which is a bad assumption. Nibble boundaries are there for rDNS. > The only place, generally, without enough clue to do non-nibble > boundaries in the DNS is the end customer delegation. ISP's have > worked with non byte aligned delegations from RIRs for years. These > is no reason to expect that this needs to change. >=20 >> then that may allow for 3 levels of hierarchy with 2/16ths or 3/16ths >> utilisation at each level. >> RIR -> ISP; ISP -> region; region -> customer >> With care, seems doable. >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From leo.liubing@huawei.com Tue Feb 26 20:01:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831B21F86D5; Tue, 26 Feb 2013 20:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b8bfnf6D-ST; Tue, 26 Feb 2013 20:01:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 89ECD21F86A8; Tue, 26 Feb 2013 20:01:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV23270; Wed, 27 Feb 2013 04:01:28 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 04:00:33 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 04:01:27 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 12:01:20 +0800 From: "Liubing (Leo)" To: "STARK, BARBARA H" , "ipv6@ietf.org" , "v6ops@ietf.org" Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiMZZ8ggACi1xA= Date: Wed, 27 Feb 2013 04:01:19 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC7D7@nkgeml506-mbx.china.huawei.com> References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <2D09D61DDFA73D4C884805CC7865E61130255AE0@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130255AE0@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "renum@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 04:01:32 -0000 Hi, Barbara Thanks for your comments. Please see replies inline. > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Wednesday, February 27, 2013 2:02 AM > To: Liubing (Leo); ipv6@ietf.org; v6ops@ietf.org > Cc: renum@ietf.org > Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps >=20 > This is interesting. Thanks for doing these tests and submitting the resu= lts. >=20 > When testing the switching behavior, I'm curious for the " SLAAC-only hos= t > receiving A=3D0&M=3D1 " case as to what you set the Preferred Lifetime to= , > when you set A=3D0. I'm guessing Preferred Lifetime > 0? [Bing] Yes, we just leave the Preferred Lifetime as default, it should be >= 0 > Since RFC 4862 states "A preferred address becomes deprecated when its > preferred lifetime expires", I would only have expected a host to depreca= te a > SLAAC-obtained address if the RA message set Preferred Lifetime to zero. = It > sounds like the case where the RA is changed from A=3D1 and Preferred > Lifetime > 0 to A=3D0 and Preferred Lifetime > 0 is ambiguous.=20 [Bing] As I learned from RFC4862, it is ambiguous. >I'm not quite > sure what the use case is for separating the A flag and Preferred Lifetim= e > settings. Did you also run the test by changing to A=3D0 and Preferred Li= fetime > =3D 0? I would hope that there would be consistent behavior in that case. [Bing] We haven't run that, but could do it later. Thanks for the remind. For separating A flag and Preferred Lifetime, it is just the concept of sep= arating "_address configuration_ methods" and "address aging" raised by Mar= k Smith in another mail on this thread. I think it is a good point of view,= and if we can initiate subsequence revision of host behavior, we should co= nsider it. > For the "DHCPv6-only host receiving A=3D1&M=3D0" case, I'm curious as to > whether you also tried sending a DHCPv6 Reconfigure message and forcing > the host to release the DHCPv6-assigned address; and send A=3D1&M=3D0 in = an > RA directly after sending the Reconfigure. I'm not sure what the use case= is > for trying to force the release or deprecation of a DHCPv6 address via fl= ags > in an RA message. Once a host has a DHCPv6 address, I would have expected > its subsequent behavior relating to that address and that DHCPv6 server t= o > be governed by RFC 3315.=20 [Bing] We haven't tried this, could do later. But we used to talk about it = in 6renum WG. DHCPv6-Reconfiguration is considered not suitable for bulk us= age, since it is stateful and unicast, might cause heavy load for the DHCPv= 6 server, this has been documented in [draft-ietf-6renum-gap-analysis]. Mor= eover, it is more difficult for administration to simultaneously operate DH= CPv6 and ND together. =20 The Linux/MAC behavior appears consistent with > what I would have expected. The Windows 7 does not. I'm unaware of even > a "hint" that suggests RA flags have a role in governing DHCPv6 behavior > once RFC 3315 is in play. [Bing] That is just the ambiguous of the RA flags behavior. IMHO, we need t= o specify it clear in the standard. Whether the RA flags should govern DHCP= v6 behavior or not, we can discuss it in the next step if the groups agree = we should deal with the ambiguous problem firstly. B.R. Bing > Barbara >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > Liubing (Leo) > > Sent: Tuesday, February 26, 2013 2:14 AM > > To: ipv6@ietf.org; v6ops@ietf.org > > Cc: renum@ietf.org > > Subject: SLAAC/DHCPv6 addr-conf operational gaps > > > > Hi, 6man & v6ops > > > > We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. > > > > As we know there are several flags in RA messages regarding with the ho= st > > configuration behavior, which are A (Autonomous) flag, M (Managed) flag= , > > and O (Otherconfig) flag. > > For some reason, the host behavior of interpreting the flags is ambiguo= us > in > > the standard (mainly RFC4862). I presented a draft discussing M flag > behavior > > in 6man @ietf84, and there were some feedbacks arguing the same issue. > > This draft analyzed all the three flags, and provided test result of cu= rrent > > implementations, it showed the behavior of different mainstream desktop > > OSes have varied. The ambiguous and variation might cause operational > > problems, such as renumbering (used to discuss in 6renum WG and been > > documented in the WG drafts), cold start problem, and management gaps > > .etc. > > > > Your review and comments would be appreciated very much. > > > > All the best, > > Bing > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Monday, February 25, 2013 5:52 PM > > > To: Liubing (Leo) > > > Cc: rbonica@juniper.net > > > Subject: New Version Notification for > > > draft-liu-bonica-dhcpv6-slaac-problem-01.txt > > > > > > > > > A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt > > > has been successfully submitted by Bing Liu and posted to the IETF > > > repository. > > > > > > Filename: draft-liu-bonica-dhcpv6-slaac-problem > > > Revision: 01 > > > Title: DHCPv6/SLAAC Address Configuration Interaction Problem > > > Statement > > > Creation date: 2013-02-25 > > > Group: Individual Submission > > > Number of pages: 12 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-pro= b > > > lem- > > > 01.txt > > > Status: > > > http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem > > > Htmlized: > > > http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 > > > Diff: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-prob= lem > > > -01 > > > > > > Abstract: > > > This document analyzes the host behavior of DHCPv6/SLAAC > interaction > > > issue. It reviews the standard definition of the host behaviors an= d > > > provides the test results of current mainstream implementations. > Some > > > potential operational gaps of the interaction are also described. > > > > > > > > > > > > > > > The IETF Secretariat > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- From jcurran@istaff.org Tue Feb 26 20:17: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 E1C1721F85ED for ; Tue, 26 Feb 2013 20:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EPJgn1Ux6+m for ; Tue, 26 Feb 2013 20:17:16 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 91F7621F8548 for ; Tue, 26 Feb 2013 20:17:16 -0800 (PST) Received: from [182.16.234.15] (helo=[10.30.2.216]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1UAYSB-000CBg-Re; Wed, 27 Feb 2013 04:17:16 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 182.16.234.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/jigWuLngPjk3oMyOsQvU+ Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Curran In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923A00DFFB@szxeml545-mbx.china.huawei.com> Date: Wed, 27 Feb 2013 12:17:20 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <193BD919-64AA-412C-B26D-1274ED4B3410@istaff.org> References: <5D36713D8A4E7348A7E10DF7437A4B923A00DFFB@szxeml545-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1499) Cc: sunqiong , "v6ops@ietf.org" , "ian.farrer@telekom.de" Subject: Re: [v6ops] Review solicitation - draft-jiang-v6ops-semantic-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 04:17:18 -0000 On Feb 27, 2013, at 11:22 AM, Sheng Jiang wrote: > We have submitted a new version draft-jiang-v6ops-semantic-prefix, "A = Framework for Semantic IPv6 Prefix and Gap Analysis" = (http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix). It is = describes a framework that embeds semantics into IPv6 prefixes, so that = network operators can efficiently manage their network traffic based on = these explicit semantics. > ... > Please read the draft and comment. Your reviewing is important for us = to improve the document. Sheng -=20 The draft contains the following text - > Using semantic prefix information for this function also makes it > possible for the service provider to increase the level of trust in > a customer-generated packet. If the packet has an incorrectly set > source or destination address, then a session will simply fail to > establish. > ... > The prefix can offer a higher level of trust for the network = operator > because it is delegated by the network and therefore the network is > better able to detect any undesired modifications and filter the > packet accordingly. If a user manipulated the destination address, > the packet will never arrive at the desired service; if the source > address is altered, then the return packet will not be received. The premise that "prefix can offer a higher level of trust for the = network=20 operator because it is delegated by the network" does not apply to a = source=20 address, and we have ample proof on the Internet today that source = addresses=20 are routinely forged (the fact that the return packet is not received = does not make an effective deterrent.)=20 One may perform entry control from subscribers to make sure that the = source=20 address complies with a certain requirements (such as your semantic = prefix information) This _would_ allow an actual increase in the level of = trust=20 in customer-generated packets. Note however that use of filters for customer-packet entry control may = just=20 as readily be deployed for header extension or option compliance, hence = it is=20 incorrect to state that "Using semantic prefix information for this = function=20 also makes it possible for the service provider to increase the level of = trust=20 in a customer-generated packet", as the increased trust in the user = packets=20 would come from the compliance filters in either case. Can you update the document accordingly? Thanks! /John From swmike@swm.pp.se Tue Feb 26 20:51: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 5895E21F86F0 for ; Tue, 26 Feb 2013 20:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JrRUVopC7fs for ; Tue, 26 Feb 2013 20:51:16 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA9221F86EB for ; Tue, 26 Feb 2013 20:51:12 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1A9CE9C; Wed, 27 Feb 2013 05:51:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 11FDE9A; Wed, 27 Feb 2013 05:51:09 +0100 (CET) Date: Wed, 27 Feb 2013 05:51:09 +0100 (CET) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: Message-ID: References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 04:51:17 -0000 On Tue, 26 Feb 2013, Owen DeLong wrote: > However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing > /48s. When I say this to some people, they quote financial benefit because supposedly ARIN charges more money if they want more addresses. -- Mikael Abrahamsson email: swmike@swm.pp.se From jcurran@istaff.org Tue Feb 26 21: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 A521921F86EB for ; Tue, 26 Feb 2013 21:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYTFchsmG3PP for ; Tue, 26 Feb 2013 21:32:29 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1327521F86C2 for ; Tue, 26 Feb 2013 21:32:28 -0800 (PST) Received: from [182.16.234.15] (helo=[10.30.2.216]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1UAZcw-000JiB-LX; Wed, 27 Feb 2013 05:32:26 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 182.16.234.15 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/LXycxhU3+uh9Bnb+bO8Lc Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Curran In-Reply-To: Date: Wed, 27 Feb 2013 13:32:32 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F4AE9FE-D750-45E6-833E-A55C54F8E5A4@istaff.org> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 05:32:29 -0000 On Feb 27, 2013, at 12:51 PM, Mikael Abrahamsson = wrote: > On Tue, 26 Feb 2013, Owen DeLong wrote: >=20 >> However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing = /48s. >=20 > When I say this to some people, they quote financial benefit because = supposedly ARIN charges more money if they want more addresses. ARIN current fees are available here: I will note that they go up at sub-linear rate, and while that does mean = that=20 an service provider that issues /48's (rather than /60s, /56's) to = customers=20 is more likely to bump a category, the cost per customer prefix drops = very quickly in higher fee categories. We have a new fee schedule which has=20= similar properties, and I'll use that one as the example as it is a = uniform step function: ... Small $2,000 Larger than /36, up to and including /32=20 (means $.0305175/year per /48) Medium $4,000 Larger than /32, up to and including /28=20 (means $.0038146/year per /48) Large $8,000 Larger than /28, up to and including /24 (means $.000476/year per /48) Now obviously the utilization is going to be far less efficient, due to sparse allocation, per-pop pools, etc, but the the claim that issuing /48's to customers will increase your fees applies at most _once_ (due to boundary condition) and then the next category change is only going to occur due to some widely successful IPv6 customer growth by that ISP. FYI, /John John Curran President and CEO ARIN From joelja@bogus.com Tue Feb 26 21:48: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 DB26421F86C4 for ; Tue, 26 Feb 2013 21:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRHVc5NSehxT for ; Tue, 26 Feb 2013 21:47:59 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8D321F86E3 for ; Tue, 26 Feb 2013 21:47:58 -0800 (PST) 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 r1R5lqdl030453 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 27 Feb 2013 05:47:52 GMT (envelope-from joelja@bogus.com) Message-ID: <512D9E04.7030503@bogus.com> Date: Tue, 26 Feb 2013 21:47:48 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Owen DeLong References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 27 Feb 2013 05:47:53 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 05:48:07 -0000 On 2/26/13 8:51 PM, Mikael Abrahamsson wrote: > On Tue, 26 Feb 2013, Owen DeLong wrote: > >> However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing >> /48s. > > When I say this to some people, they quote financial benefit because > supposedly ARIN charges more money if they want more addresses. the fee schedule is generally congruent with the ipv4 fee schedule until you need a prefix shorter than /22 A /22 is enough for 67 million /48s 17 billion /56s or 274 trillion /60s From leo.liubing@huawei.com Tue Feb 26 21:56: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 E2B0721F86E3; Tue, 26 Feb 2013 21:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj8B2Y-xL30p; Tue, 26 Feb 2013 21:56:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7821F85D7; Tue, 26 Feb 2013 21:56:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV29444; Wed, 27 Feb 2013 05:56:13 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 05:55:17 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 05:56:12 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 13:56:04 +0800 From: "Liubing (Leo)" To: Mark Smith , "ipv6@ietf.org" , "v6ops@ietf.org" Thread-Topic: SLAAC/DHCPv6 addr-conf operational gaps Thread-Index: AQHOE/Dp7oY45oFpuUWdZ8xgw4l8cJiME2CAgAEfplA= Date: Wed, 27 Feb 2013 05:56:03 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC83E@nkgeml506-mbx.china.huawei.com> References: <20130225095210.8863.75094.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DC03C@nkgeml506-mbx.china.huawei.com> <1361910873.78397.YahooMailNeo@web142503.mail.bf1.yahoo.com> In-Reply-To: <1361910873.78397.YahooMailNeo@web142503.mail.bf1.yahoo.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "renum@ietf.org" Subject: Re: [v6ops] SLAAC/DHCPv6 addr-conf operational gaps X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 05:56:23 -0000 Hi, Mark Thanks for your comment.=20 I like the concept of separating "_address configuration_ methods" and "add= ress aging methods", if we could initiate the subsequence work, it should b= e considered. All the best Bing > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@yahoo.com.au] > Sent: Wednesday, February 27, 2013 4:35 AM > To: Liubing (Leo); ipv6@ietf.org; v6ops@ietf.org > Cc: renum@ietf.org > Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps >=20 > Hi, >=20 > I've had a quick read though, I'll try to do a thorough one in the next w= eek or > so. >=20 > Thanks for writing this, I've been thinking about doing something similar= over > the last few months since, IIRC, I heard about Windows 7 invalidating IPv= 6 > addresses learned via DHCPv6 when SLAAC was enabled and DHCPv6 was > disabled on a link. >=20 > A few thoughts I've had which may be useful - >=20 > Firstly, I came to realise that the mistake being made by Windows 7 was t= he > assumption that the aging of the assigned IPv6 addresses was tightly coup= led > to the DHCPv6 session state, meaning that if DHCPv6 went away, so would > the assigned addresses. This is generally the way DHCPv4 has worked. > However, in IPv6/DHCPv6, it seems the address lifetime values in the IA_N= A > are not coupled to the T1 and T2 times, so if DHCPv6 goes away (perhaps > because the M bit was switched off in a latter RA), the configured IPv6 > addresses should be left to age out as per their preferred and valid life= times. >=20 > The other thing I noticed was that the M RA flag and the PIO A flags aren= 't > mutually exclusive - I couldn't find any text in RFC4861 that says if the= M bit > is switched on, the PIO A flags must be switched off and vice-versa. So t= hat > suggests that the DHCPv6 and SLAAC can co-exist, and I think that is quit= e > reasonable if you're transitioning a link from DHCPv6 to SLAAC address > configuration or vice-versa. >=20 > Thinking about it more, I came realise that DHCPv6 and SLAAC are _address > configuration_ methods, but are not address aging methods - IPv6 takes ca= re > of address aging via it's preferred and valid aging mechanisms, regardles= s of > the address configuration method. Static assignment is also just an addre= ss > configuration method, although typically the addresses don't age out, but > only because they're normally set to infinity. Perhaps in the future ther= e > might be other address configuration methods. >=20 > I didn't seem to be able to find an RFC that made it clear that address > configuration and address aging are quite separate, so perhaps this ID co= uld > be the one. >=20 > Regarding this text: >=20 > 'For the host behavior, there is an explicit rule in the SLAAC specificat= ion > [RFC4862]: "If the Autonomous flag is not set, silently ignore the Prefix > Information option."' >=20 > I think RFC5942, "IPv6 Subnet Model: The Relationship between Links and > Subnet Prefixes." updates that advice, as the PIO option is used to indic= ates > which prefix/range of addresses are on-link, via the PIO O bit, even if t= he PIO > A bit is switched off. >=20 > Best regards, > Mark. >=20 > >________________________________ > > From: Liubing (Leo) > >To: "ipv6@ietf.org" ; "v6ops@ietf.org" > >Cc: "renum@ietf.org" > >Sent: Tuesday, 26 February 2013 6:14 PM > >Subject: SLAAC/DHCPv6 addr-conf operational gaps > > > >Hi, 6man & v6ops > > > >We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. > > > >As we know there are several flags in RA messages regarding with the hos= t > configuration behavior, which are A (Autonomous) flag, M (Managed) flag, > and O (Otherconfig) flag. > >For some reason, the host behavior of interpreting the flags is ambiguou= s in > the standard (mainly RFC4862). I presented a draft discussing M flag > behavior in 6man @ietf84, and there were some feedbacks arguing the same > issue. This draft analyzed all the three flags, and provided test result = of > current implementations, it showed the behavior of different mainstream > desktop OSes have varied. The ambiguous and variation might cause > operational problems, such as renumbering (used to discuss in 6renum WG > and been documented in the WG drafts), cold start problem, and > management gaps .etc. > > > >Your review and comments would be appreciated very much. > > > >All the best, > >Bing > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Monday, February 25, 2013 5:52 PM > >> To: Liubing (Leo) > >> Cc: rbonica@juniper.net > >> Subject: New Version Notification for > >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt > >> > >> > >> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt > >> has been successfully submitted by Bing Liu and posted to the > >> IETF repository. > >> > >> Filename:=A0=A0=A0=A0=A0draft-liu-bonica-dhcpv6-slaac-problem > >> Revision:=A0=A0=A0=A0=A001 > >> Title:=A0=A0=A0 =A0=A0=A0=A0=A0DHCPv6/SLAAC Address Configuration Inte= raction > Problem > >> Statement > >> Creation date:=A0=A0=A0=A0=A02013-02-25 > >> Group:=A0=A0=A0 =A0=A0=A0=A0=A0Individual Submission > >> Number of pages: 12 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem= - > >> 01.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem > >> Htmlized: > >> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 > >> Diff: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-bonica-dhcpv6-slaac-problem-= 01 > >> > >> Abstract: > >>=A0 =A0 This document analyzes the host behavior of DHCPv6/SLAAC > interaction > >>=A0 =A0 issue. It reviews the standard definition of the host behaviors= and > >>=A0 =A0 provides the test results of current mainstream implementations= . > Some > >>=A0 =A0 potential operational gaps of the interaction are also describe= d. > >> > >> > >> > >> > >> The IETF Secretariat > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > > > > From drc@virtualized.org Tue Feb 26 22:10: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 8D0EF21F86C4 for ; Tue, 26 Feb 2013 22:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLJPV71ESh2f for ; Tue, 26 Feb 2013 22:10:06 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0196C21F8613 for ; Tue, 26 Feb 2013 22:10:06 -0800 (PST) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id A192E1717A; Wed, 27 Feb 2013 06:10:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: David Conrad In-Reply-To: <1F4AE9FE-D750-45E6-833E-A55C54F8E5A4@istaff.org> Date: Tue, 26 Feb 2013 22:10:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <169940C0-EF47-45FC-99EA-368F373BFF68@virtualized.org> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <1F4AE9FE-D750-45E6-833E-A55C54F8E5A4@istaff.org> To: John Curran X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 06:10:09 -0000 John, On Feb 26, 2013, at 9:32 PM, John Curran wrote: >>> However, there's zero benefit to issuing /60s, /56s, etc. vs. = issuing /48s. >>=20 >> When I say this to some people, they quote financial benefit because = supposedly ARIN charges more money if they want more addresses. >=20 > ARIN current fees are available here: > So, is this a commitment on the part of all RIRs to permanently fix the = fees? :) More seriously, I think it would be a mistake to tailor protocol specs = to take advantage of a particular RIR's fee schedule. Regards, -drc From owen@delong.com Tue Feb 26 22:16: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 6068821F8722 for ; Tue, 26 Feb 2013 22:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LInDPKqrdMi7 for ; Tue, 26 Feb 2013 22:16:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7783121F86E3 for ; Tue, 26 Feb 2013 22:16:08 -0800 (PST) Received: from [10.0.1.23] ([216.218.209.150]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1R6ERXi001911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 22:14:28 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1R6ERXi001911 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361945668; bh=SwtwIdeeBU75HzkN7LW9AcEPPsw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=P4gQHHqvwWg4pE5luWCvHw5H4nnZzs3XBS3nbV25PFFzKsW18/0x56SP4Q0rNZbfr Yp3Isvlv9wYpzCZsB5ozcjmvQel3gt8CFYFaydNdIGlLc+U6+yFdM49Qj98cYp9wOp t3HV+mqrwOQN5XFrAbSN9oz0hePz+O+rTIwvZRXY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <169940C0-EF47-45FC-99EA-368F373BFF68@virtualized.org> Date: Tue, 26 Feb 2013 22:14:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCF45F1-66DD-420F-905F-BC031717D893@delong.com> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <1F4AE9FE-D750-45E6-833E-A55C54F8E5A4@istaff.org> <169940C0-EF47-45FC-99EA-368F373BFF68@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 26 Feb 2013 22:14:28 -0800 (PST) Cc: John Curran , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 06:16:09 -0000 On Feb 26, 2013, at 10:10 PM, David Conrad wrote: > John, >=20 > On Feb 26, 2013, at 9:32 PM, John Curran wrote: >>>> However, there's zero benefit to issuing /60s, /56s, etc. vs. = issuing /48s. >>>=20 >>> When I say this to some people, they quote financial benefit because = supposedly ARIN charges more money if they want more addresses. >>=20 >> ARIN current fees are available here: >> >=20 > So, is this a commitment on the part of all RIRs to permanently fix = the fees? :) >=20 Rather it is an expression that the fees do not actually change = meaningfully per subscriber as you move from /60 to /56 to /48. > More seriously, I think it would be a mistake to tailor protocol specs = to take advantage of a particular RIR's fee schedule. True. However, it's also a mistake to do stupid things to protocol = specs just to save a few $$ in RIR fees. Owen From marka@isc.org Tue Feb 26 22:26: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 6E25821F87B9 for ; Tue, 26 Feb 2013 22:26:04 -0800 (PST) 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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke-Yo8ZYkT+B for ; Tue, 26 Feb 2013 22:26:03 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B5D8C21F8790 for ; Tue, 26 Feb 2013 22:26:03 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5E60E5F98BF; Wed, 27 Feb 2013 06:25:50 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361946363; bh=LKHgdeO5UuMmjCfZOwWIVomzV39lPWQGIhIWZIooj24=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=BOKWNUfFDvC7tAKaOAXdrOY9w4YGomBFNb+X2SGs0bl+FipTyJ5HxJu0uBQ+Qf2Dv xarvgbh9it30G6/zx6kE9jVUvYJnSIDJo1N4gVqnrBD/KiZUajyPLGZhGEYHOMqZ9h I0UCji5C65h09qdL/8gVLjKu+sbqyrPM3VtMevM0= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:90:dc36:4d1e:8327]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 99FC9216C4B; Wed, 27 Feb 2013 06:25:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8CB1C302780D; Wed, 27 Feb 2013 17:25:48 +1100 (EST) To: David Conrad From: Mark Andrews References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <1F4AE9FE-D750-45E6-833E-A55C54F8E5A4@istaff.org> <169940C0-EF47-45FC-99EA-368F373BFF68@virtualized.org> In-reply-to: Your message of "Tue, 26 Feb 2013 22:10:03 -0800." <169940C0-EF47-45FC-99EA-368F373BFF68@virtualized.org> Date: Wed, 27 Feb 2013 17:25:48 +1100 Message-Id: <20130227062548.8CB1C302780D@drugs.dv.isc.org> Cc: John Curran , v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 06:26:04 -0000 In message <169940C0-EF47-45FC-99EA-368F373BFF68@virtualized.org>, David Conrad writes: > John, > > On Feb 26, 2013, at 9:32 PM, John Curran wrote: > >>> However, there's zero benefit to issuing /60s, /56s, etc. vs. issuing /48s. > >> > >> When I say this to some people, they quote financial benefit because supposedly ARIN charges more money if they want more addresses. > > > > ARIN current fees are available here: > > > > So, is this a commitment on the part of all RIRs to permanently fix the fees? :) > > More seriously, I think it would be a mistake to tailor protocol specs to take advantage of a particular RIR's fee schedule. > > Regards, > -drc Whatever the rate is it is "chump change" per /48. 3c/annum out of $720.00 assuming $60/m. .0041% of the cost is address rental from ARIN. The ISP will be paying 1000x more to MC and Visa than this just processing the payments. > _______________________________________________ > 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 jiangsheng@huawei.com Tue Feb 26 22:26: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 BA6DB21F87E0 for ; Tue, 26 Feb 2013 22:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYeJKhAUODvw for ; Tue, 26 Feb 2013 22:26:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 984DC21F87C3 for ; Tue, 26 Feb 2013 22:26:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOV31498; Wed, 27 Feb 2013 06:26:05 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 06:25:58 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Feb 2013 06:26:04 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.45]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Wed, 27 Feb 2013 14:24:51 +0800 From: Sheng Jiang To: John Curran Thread-Topic: [v6ops] Review solicitation - draft-jiang-v6ops-semantic-prefix Thread-Index: Ac4UmZxJgYKThVy5TOeV8GZlgLA+sv//iVYA//9aqJA= Date: Wed, 27 Feb 2013 06:24:51 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A00E19B@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923A00DFFB@szxeml545-mbx.china.huawei.com> <193BD919-64AA-412C-B26D-1274ED4B3410@istaff.org> In-Reply-To: <193BD919-64AA-412C-B26D-1274ED4B3410@istaff.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: sunqiong , "v6ops@ietf.org" , "ian.farrer@telekom.de" Subject: Re: [v6ops] Review solicitation - draft-jiang-v6ops-semantic-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 06:26:08 -0000 SGksIEpvaG4sDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4gWW91ciBvYnNlcnZhdGlvbiBpcyBh Y2N1cmF0ZS4gVGhlIGluY3JlYXNpbmcgb2YgdHJ1c3QgaXMgYnJvdWdodCBieSB0aGUgY29tcGxp YW5jZSBmaWx0ZXJzIHJhdGhlciB0aGFuIHNlbWFudGljIHByZWZpeC4gV2Ugd2lsbCBtb2RpZnkg dGhlIGNvbnRlbnQgYWNjb3JkaW5nbHkgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KTWFueSB0aGFu a3MgYW5kIGJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+RnJvbTogSm9obiBDdXJyYW4gW21haWx0bzpqY3VycmFuQGlzdGFmZi5vcmddDQo+U2Vu dDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNywgMjAxMyAxMjoxNyBQTQ0KPlRvOiBTaGVuZyBKaWFu Zw0KPkNjOiB2Nm9wc0BpZXRmLm9yZzsgaWFuLmZhcnJlckB0ZWxla29tLmRlOyBzdW5xaW9uZw0K PlN1YmplY3Q6IFJlOiBbdjZvcHNdIFJldmlldyBzb2xpY2l0YXRpb24gLSBkcmFmdC1qaWFuZy12 Nm9wcy1zZW1hbnRpYy1wcmVmaXgNCj4NCj5PbiBGZWIgMjcsIDIwMTMsIGF0IDExOjIyIEFNLCBT aGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4NCj4+IFdlIGhhdmUg c3VibWl0dGVkIGEgbmV3IHZlcnNpb24gZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4 LCAiQQ0KPkZyYW1ld29yayBmb3IgU2VtYW50aWMgSVB2NiBQcmVmaXggYW5kIEdhcCBBbmFseXNp cyINCj4oaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50 aWMtcHJlZml4KS4gSXQgaXMgZGVzY3JpYmVzIGENCj5mcmFtZXdvcmsgdGhhdCBlbWJlZHMgc2Vt YW50aWNzIGludG8gSVB2NiBwcmVmaXhlcywgc28gdGhhdCBuZXR3b3JrDQo+b3BlcmF0b3JzIGNh biBlZmZpY2llbnRseSBtYW5hZ2UgdGhlaXIgbmV0d29yayB0cmFmZmljIGJhc2VkIG9uIHRoZXNl IGV4cGxpY2l0DQo+c2VtYW50aWNzLg0KPj4gLi4uDQo+PiBQbGVhc2UgcmVhZCB0aGUgZHJhZnQg YW5kIGNvbW1lbnQuIFlvdXIgcmV2aWV3aW5nIGlzIGltcG9ydGFudCBmb3IgdXMgdG8NCj5pbXBy b3ZlIHRoZSBkb2N1bWVudC4NCj4NCj4NCj5TaGVuZyAtDQo+DQo+VGhlIGRyYWZ0IGNvbnRhaW5z IHRoZSBmb2xsb3dpbmcgdGV4dCAtDQo+DQo+PiAgICBVc2luZyBzZW1hbnRpYyBwcmVmaXggaW5m b3JtYXRpb24gZm9yIHRoaXMgZnVuY3Rpb24gYWxzbyBtYWtlcyBpdA0KPj4gICAgcG9zc2libGUg Zm9yIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHRvIGluY3JlYXNlIHRoZSBsZXZlbCBvZiB0cnVzdCBp bg0KPj4gICAgYSBjdXN0b21lci1nZW5lcmF0ZWQgcGFja2V0LiAgSWYgdGhlIHBhY2tldCBoYXMg YW4gaW5jb3JyZWN0bHkgc2V0DQo+PiAgICBzb3VyY2Ugb3IgZGVzdGluYXRpb24gYWRkcmVzcywg dGhlbiBhIHNlc3Npb24gd2lsbCBzaW1wbHkgZmFpbCB0bw0KPj4gICAgZXN0YWJsaXNoLg0KPj4g Li4uDQo+PiAgICBUaGUgcHJlZml4IGNhbiBvZmZlciBhIGhpZ2hlciBsZXZlbCBvZiB0cnVzdCBm b3IgdGhlIG5ldHdvcmsgb3BlcmF0b3INCj4+ICAgIGJlY2F1c2UgaXQgaXMgZGVsZWdhdGVkIGJ5 IHRoZSBuZXR3b3JrIGFuZCB0aGVyZWZvcmUgdGhlIG5ldHdvcmsgaXMNCj4+ICAgIGJldHRlciBh YmxlIHRvIGRldGVjdCBhbnkgdW5kZXNpcmVkIG1vZGlmaWNhdGlvbnMgYW5kIGZpbHRlciB0aGUN Cj4+ICAgIHBhY2tldCBhY2NvcmRpbmdseS4gIElmIGEgdXNlciBtYW5pcHVsYXRlZCB0aGUgZGVz dGluYXRpb24gYWRkcmVzcywNCj4+ICAgIHRoZSBwYWNrZXQgd2lsbCBuZXZlciBhcnJpdmUgYXQg dGhlIGRlc2lyZWQgc2VydmljZTsgaWYgdGhlIHNvdXJjZQ0KPj4gICAgYWRkcmVzcyBpcyBhbHRl cmVkLCB0aGVuIHRoZSByZXR1cm4gcGFja2V0IHdpbGwgbm90IGJlIHJlY2VpdmVkLg0KPg0KPlRo ZSBwcmVtaXNlIHRoYXQgInByZWZpeCBjYW4gb2ZmZXIgYSBoaWdoZXIgbGV2ZWwgb2YgdHJ1c3Qg Zm9yIHRoZSBuZXR3b3JrDQo+b3BlcmF0b3IgYmVjYXVzZSBpdCBpcyBkZWxlZ2F0ZWQgYnkgdGhl IG5ldHdvcmsiIGRvZXMgbm90IGFwcGx5IHRvIGEgc291cmNlDQo+YWRkcmVzcywgYW5kIHdlIGhh dmUgYW1wbGUgcHJvb2Ygb24gdGhlIEludGVybmV0IHRvZGF5IHRoYXQgc291cmNlDQo+YWRkcmVz c2VzDQo+YXJlIHJvdXRpbmVseSBmb3JnZWQgKHRoZSBmYWN0IHRoYXQgdGhlIHJldHVybiBwYWNr ZXQgaXMgbm90IHJlY2VpdmVkIGRvZXMNCj5ub3QgbWFrZSBhbiBlZmZlY3RpdmUgZGV0ZXJyZW50 LikNCj4NCj5PbmUgbWF5IHBlcmZvcm0gZW50cnkgY29udHJvbCBmcm9tIHN1YnNjcmliZXJzIHRv IG1ha2Ugc3VyZSB0aGF0IHRoZSBzb3VyY2UNCj5hZGRyZXNzIGNvbXBsaWVzIHdpdGggYSBjZXJ0 YWluIHJlcXVpcmVtZW50cyAoc3VjaCBhcyB5b3VyIHNlbWFudGljIHByZWZpeA0KPmluZm9ybWF0 aW9uKSAgVGhpcyBfd291bGRfIGFsbG93IGFuIGFjdHVhbCBpbmNyZWFzZSBpbiB0aGUgbGV2ZWwg b2YgdHJ1c3QNCj5pbiBjdXN0b21lci1nZW5lcmF0ZWQgcGFja2V0cy4NCj4NCj5Ob3RlIGhvd2V2 ZXIgdGhhdCB1c2Ugb2YgZmlsdGVycyBmb3IgY3VzdG9tZXItcGFja2V0IGVudHJ5IGNvbnRyb2wg bWF5IGp1c3QNCj5hcyByZWFkaWx5IGJlIGRlcGxveWVkIGZvciBoZWFkZXIgZXh0ZW5zaW9uIG9y IG9wdGlvbiBjb21wbGlhbmNlLCBoZW5jZSBpdCBpcw0KPmluY29ycmVjdCB0byBzdGF0ZSB0aGF0 ICJVc2luZyBzZW1hbnRpYyBwcmVmaXggaW5mb3JtYXRpb24gZm9yIHRoaXMgZnVuY3Rpb24NCj5h bHNvIG1ha2VzIGl0IHBvc3NpYmxlIGZvciB0aGUgc2VydmljZSBwcm92aWRlciB0byBpbmNyZWFz ZSB0aGUgbGV2ZWwgb2YgdHJ1c3QNCj5pbiBhIGN1c3RvbWVyLWdlbmVyYXRlZCBwYWNrZXQiLCBh cyB0aGUgaW5jcmVhc2VkIHRydXN0IGluIHRoZSB1c2VyIHBhY2tldHMNCj53b3VsZCBjb21lIGZy b20gdGhlIGNvbXBsaWFuY2UgZmlsdGVycyBpbiBlaXRoZXIgY2FzZS4NCj4NCj5DYW4geW91IHVw ZGF0ZSB0aGUgZG9jdW1lbnQgYWNjb3JkaW5nbHk/DQo+DQo+VGhhbmtzIQ0KPi9Kb2huDQoNCg== From nathalie@ripe.net Wed Feb 27 04:12: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 2AEE321F8551 for ; Wed, 27 Feb 2013 04:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NzTeOtBI6IO for ; Wed, 27 Feb 2013 04:12:12 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id D890021F8549 for ; Wed, 27 Feb 2013 04:12:11 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UAfrj-0007DX-CC; Wed, 27 Feb 2013 13:12:08 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-152.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1UAfrj-0000H8-4D; Wed, 27 Feb 2013 13:12:07 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Nathalie Trenaman In-Reply-To: Date: Wed, 27 Feb 2013 13:12:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4633D559-CA4C-40E0-9E56-96BB1755F13B@ripe.net> References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> To: Owen DeLong X-Mailer: Apple Mail (2.1085) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130227 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a8d3944c2bbc2b4517e23405275834220 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 12:12:13 -0000 >=20 >> On 02/26/2013 11:09 AM, Owen DeLong wrote: >>> At least in North America, it's pretty easy to get a very large = amount of IPv6 space. >>=20 >> I think that's true pretty universally, and is likely to remain so = for well past our lifetimes. :) >>=20 >>> Being unable to obtain space is clearly not a valid reason to use = longer prefixes and I certainly think that your proposed compromise is = an improvement over dense-packing long prefixes. However, I have yet to = hear from anyone any legitimate reason for using longer prefixes to = begin with. Nobody has yet stated any benefit to doing so. >>=20 >> People have given reasons, you just don't agree with them. :) >>=20 >=20 > I literally haven't seen anything that is even alleged to be a benefit = of longer prefixes. >=20 > Here's what I've seen: >=20 > Comcast: "Covers buggy hardware/software" > I've already agreed that I accept this. However, that's = /128s and /64s. Not /60s and /56s vs. /48s. >=20 > A few others: > "We shouldn't give it out liberally because we'll run = out. Have we learned nothing from IPv4?" >=20 > This isn't a benefit. This is fear mongering. The = solution to this is, IMHO, Let's try it liberal until > we're 50 years down the road or until 2000::/3 is fully = allocated to RIRs, whichever comes first. > If we fully allocate 2000::/3 to RIRs in less than 50 = years, then we have plenty of time to talk > about more conservative ways to allocate the next /3 and = we still have 4 other /3s (1/2 of the > total IPv6 address space) that remains untouched. >=20 > If you've seen someone stating an actual benefit (outside of "it = covers for the bugs"), then please share... I really have literally = missed it. If someone can show a truly valid reason for longer prefixes = that involves either a benefit or a real downside to shorter ones, I = really am open to being convinced. This is why, in our IPv6 for LIRs courses, we spend an incredible amount = of time getting people to understand the concepts of larger blocks and = why they should assign them to customers. It is a hard struggle for = people who are just starting with IPv6 to get their heads around this. = Sometimes I have to explain the attendees that it is half a psychology = course rather than a technical course ;). In the feedback we get after = the courses, we can tell this is one of the hardest subjects for them to = understand..... Nathalie Trenaman RIPE NCC Trainer= From pkern@spike.0x539.de Wed Feb 27 05: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 E75CF21F856D for ; Wed, 27 Feb 2013 05:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdhXVICX0j8L for ; Wed, 27 Feb 2013 05:15:00 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id C434B21F852C for ; Wed, 27 Feb 2013 05:14:32 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UAgq4-0001wJ-MT; Wed, 27 Feb 2013 14:14:28 +0100 Received: from [2a00:1398:4:0:c62:8ebc:7a9:440b] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UAgq5-0003uN-W5; Wed, 27 Feb 2013 14:14:30 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UAgq5-00009k-Ln; Wed, 27 Feb 2013 14:14:29 +0100 Date: Wed, 27 Feb 2013 14:14:29 +0100 From: Philipp Kern To: Nathalie Trenaman Message-ID: <20130227131429.GB31502@spike.0x539.de> References: <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> <4633D559-CA4C-40E0-9E56-96BB1755F13B@ripe.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <4633D559-CA4C-40E0-9E56-96BB1755F13B@ripe.net> Organization: The Debian Project (http://www.debian.org) X-Debbugs-No-Ack: yes User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 13:15:06 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Nathalie, am Wed, Feb 27, 2013 at 01:12:12PM +0100 hast du folgendes geschrieben: > This is why, in our IPv6 for LIRs courses, we spend an incredible amount of > time getting people to understand the concepts of larger blocks and why they > should assign them to customers. It is a hard struggle for people who are > just starting with IPv6 to get their heads around this. Sometimes I have to > explain the attendees that it is half a psychology course rather than a > technical course ;). In the feedback we get after the courses, we can tell > this is one of the hardest subjects for them to understand..... are we talking about /48 here? Kind regards Philipp Kern --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlEuBrUACgkQ7Ro5M7LPzdicHQCghUsmuBi/BjToQkzlqEliM7Qi 0DYAoLVgfyB7R6Cba8TF93kynYBs8YOo =RowX -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From nathalie@ripe.net Wed Feb 27 05:24: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 8508D21F8611 for ; Wed, 27 Feb 2013 05:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYkCNmBVv77H for ; Wed, 27 Feb 2013 05:24:45 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id BEBBB21F8602 for ; Wed, 27 Feb 2013 05:24:44 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UAgzy-0002jU-10; Wed, 27 Feb 2013 14:24:43 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-152.ripe.net) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1UAgzx-0003dB-T6; Wed, 27 Feb 2013 14:24:41 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Nathalie Trenaman In-Reply-To: <20130227131429.GB31502@spike.0x539.de> Date: Wed, 27 Feb 2013 14:24:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AD5FF8E-973D-4D44-BD71-1DFA2EE16729@ripe.net> References: <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> <4633D559-CA4C-40E0-9E56-96BB1755F13B@ripe.net> <20130227131429.GB31502@spike.0x539.de> To: Philipp Kern X-Mailer: Apple Mail (2.1085) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130227 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ab0828c500a09c03b257964143a0621d7 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 13:24:45 -0000 Philipp, On Feb 27, 2013, at 2:14 PM, Philipp Kern wrote: > Nathalie, >=20 > am Wed, Feb 27, 2013 at 01:12:12PM +0100 hast du folgendes = geschrieben: >> This is why, in our IPv6 for LIRs courses, we spend an incredible = amount of >> time getting people to understand the concepts of larger blocks and = why they >> should assign them to customers. It is a hard struggle for people who = are >> just starting with IPv6 to get their heads around this. Sometimes I = have to >> explain the attendees that it is half a psychology course rather than = a >> technical course ;). In the feedback we get after the courses, we can = tell >> this is one of the hardest subjects for them to understand..... >=20 > are we talking about /48 here? >=20 >=20 /48 for businesses, /48 or /52 or /56 for residentials. Kind regards, Nathalie Trenaman RIPE NCC Trainer From tjc@ecs.soton.ac.uk Wed Feb 27 05:56: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 C981721F852C for ; Wed, 27 Feb 2013 05:56:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QdoHait62qa for ; Wed, 27 Feb 2013 05:56:13 -0800 (PST) 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 D6DA021F85BB for ; Wed, 27 Feb 2013 05:56:12 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1RDuBs6021454 for ; Wed, 27 Feb 2013 13:56:11 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r1RDuBs6021454 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1361973371; bh=c/peBaPPQ0gdtpdJyOS65ElyVBU=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=EP7d/mAzCI+inu736iwQ3n5deha9d4jPu80mWpF182KfsS2uv2CTpQBNX0olrGMEf mVWQR8sdTLx9noSdR0MqZtONEq6xg4QWRJIWBZ0TGU/iMA5dihgwSdJwOI6vIqv3AU 7/4p30H/0EQYUYWoiEDpOcpOP6QMwkz8uDECPDnI= 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 p1QDuB0430612981aj ret-id none; Wed, 27 Feb 2013 13:56:11 +0000 Received: from ip-161-146.eduroam.soton.ac.uk (ip-161-146.eduroam.soton.ac.uk [152.78.161.146]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1RDu9IZ018204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Feb 2013 13:56:10 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_5F95A5EB-1317-423E-8940-52FDB3677746" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Wed, 27 Feb 2013 13:56:15 +0000 References: <8D032AC7-F73D-4FFE-9605-CE135EE6A3AE@ecs.soton.ac.uk> To: v6ops@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p1QDuB043061298100; tid=p1QDuB0430612981aj; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r1RDuBs6021454 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 13:56:13 -0000 --Apple-Mail=_5F95A5EB-1317-423E-8940-52FDB3677746 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Feb 2013, at 14:07, "Brzozowski, John" = wrote: > [jjmb] incorrect I have both, just stating that I have both. = Apologies if > I was not clear. I also have a good # of home routers actively using = IPv6 > enabled broadband today, ~3%. Congratulations, btw. That must be a large number when converted to real = customers :) The homenet architecture assumes a CPE rather than a single host. It = discusses ISP allocations in section 3.4.1 of = http://tools.ietf.org/html/draft-ietf-homenet-arch-07. As that text is = in WGLC, any comments on that section would be welcome (preferably on = the homenet list). Tim= --Apple-Mail=_5F95A5EB-1317-423E-8940-52FDB3677746 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii John_Brzozowski@Cable.Co= mcast.com> wrote:

[jjmb] = incorrect I have both, just stating that I have both.  Apologies = if
I was not clear.  I also have a good # of home routers = actively using IPv6
enabled broadband today, = ~3%.

Congratulations, btw. That must be a = large number when converted to real customers = :)

The homenet architecture assumes a CPE = rather than a single host. It discusses ISP allocations in section 3.4.1 = of http://tool= s.ietf.org/html/draft-ietf-homenet-arch-07.  As that text is in = WGLC, any comments on that section would be welcome (preferably on the = homenet list).

Tim
= --Apple-Mail=_5F95A5EB-1317-423E-8940-52FDB3677746-- From gert@space.net Wed Feb 27 10:19: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 0157421F85F3 for ; Wed, 27 Feb 2013 10:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km6XUCR1O0J0 for ; Wed, 27 Feb 2013 10:19:11 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 1308E21F8667 for ; Wed, 27 Feb 2013 10:19:10 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id D3AEB60465 for ; Wed, 27 Feb 2013 19:19:08 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A5B7A60363 for ; Wed, 27 Feb 2013 19:19:08 +0100 (CET) Received: (qmail 2184 invoked by uid 1007); 27 Feb 2013 19:19:08 +0100 Date: Wed, 27 Feb 2013 19:19:08 +0100 From: Gert Doering To: John Mann Message-ID: <20130227181908.GE51699@Space.Net> References: <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 18:19:12 -0000 Hi, On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: > For example, at APNIC, based around 2^24 customers > a /32 costs AUD 1,994 == > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calculate > and a /24 costs AUD 16,267 == > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculate Ouch... This is exactly the sort of incentive the RIRs should *not* give (and we don't do that in RIPE land). OTOH, I don't have an issue with "/56s to residential customers", as I'm still waiting for someone to explain to me why 256 subnets in the home is "too small". /60 feels a bit too small, though. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From marka@isc.org Wed Feb 27 14:39:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254B121F875C for ; Wed, 27 Feb 2013 14:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex5m6aviodSt for ; Wed, 27 Feb 2013 14:39:43 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD5021F8853 for ; Wed, 27 Feb 2013 14:39:43 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id DF6DC5F9940; Wed, 27 Feb 2013 22:39:30 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362004782; bh=JmSm3cFiXPFMSL/k2zGMGrKYzJTMTrpeaHiFPOmGBq4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=nmvtWgApImCXGju33gdtO6NKFkYPjynvLRMkQ7P6TN0iFGGQAHhB7lzSp8aLJxN0P 2TVpSPfGQFfkQ34yjlbcLyeHIpljm1nm/KE2oG+QWyv1lTZBc0/WC2tHugJIp91DGx BHIvDyh9t1dV9fK3T1PmfeSI6nwQqM96RxZE0DWk= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:47:dd04:3a56:d7fe]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1E691216C3B; Wed, 27 Feb 2013 22:39:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 05832302B138; Thu, 28 Feb 2013 09:39:26 +1100 (EST) To: Gert Doering From: Mark Andrews References: <5126BA74.5080508@cisco.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <512D0A20.3060505@dougbarton.us> <20130227181908.GE51699@Space.Net> In-reply-to: Your message of "Wed, 27 Feb 2013 19:19:08 BST." <20130227181908.GE51699@Space.Net> Date: Thu, 28 Feb 2013 09:39:25 +1100 Message-Id: <20130227223926.05832302B138@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 22:39:44 -0000 In message <20130227181908.GE51699@Space.Net>, Gert Doering writes: > Hi, > > On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: > > For example, at APNIC, based around 2^24 customers > > a /32 costs AUD 1,994 == > > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calculat > e > > and a /24 costs AUD 16,267 == > > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculat > e > > Ouch... 3c/annum and 0.1c/annum per /48 respectively > This is exactly the sort of incentive the RIRs should *not* give (and > we don't do that in RIPE land). or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer allocations. Both of those are less than the cost of getting the ethernet address that the CPE vendor paid to the IEEE. > OTOH, I don't have an issue with "/56s to residential customers", as I'm > still waiting for someone to explain to me why 256 subnets in the home > is "too small". /60 feels a bit too small, though. Because it stiffles development. When you have a people wearing a couple of subnets each it doesn't take long to use up 256 subnets. Today I have family and friends come over and grab a address wirelessly. It is not a long stretch to also have a prefix delegation or two occur in the future at the same time. 256 is suddenly very small. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From wwwrun@rfc-editor.org Wed Feb 27 15:32: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 5287421F884F for ; Wed, 27 Feb 2013 15:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaoCA5AUI2ZP for ; Wed, 27 Feb 2013 15:32:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4B21F883B for ; Wed, 27 Feb 2013 15:32:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9408D72E114; Wed, 27 Feb 2013 15:30:46 -0800 (PST) To: dwing@cisco.com, ayourtch@cisco.com, rbonica@juniper.net, bclaise@cisco.com, fred.baker@cisco.com, john_brzozowski@cable.comcast.com From: RFC Errata System Message-Id: <20130227233046.9408D72E114@rfc-editor.org> Date: Wed, 27 Feb 2013 15:30:46 -0800 (PST) Cc: techgrrl@gmail.com, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] [Technical Errata Reported] RFC6555 (3502) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2013 23:32:04 -0000 The following errata report has been submitted for RFC6555, "Happy Eyeballs: Success with Dual-Stack Hosts". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6555&eid=3502 -------------------------------------- Type: Technical Reported by: Elle Plato Section: 6 Original Text ------------- 1. Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy. Corrected Text -------------- 1. Call getaddrinfo(), which returns a list of IP addresses sorted by the host's address preference policy. Notes ----- The r appears to be missing from the getaddrinfo() call. This may vary by language but C, POSIX and Perl seem to expect the r. I would think this is a trivial change, and would fall into the category of "Hold for Document Update". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6555 (draft-ietf-v6ops-happy-eyeballs-07) -------------------------------------- Title : Happy Eyeballs: Success with Dual-Stack Hosts Publication Date : April 2012 Author(s) : D. Wing, A. Yourtchenko Category : PROPOSED STANDARD Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From owen@delong.com Wed Feb 27 17:47:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28B721F8771 for ; Wed, 27 Feb 2013 17:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zCk+j4prrRQ for ; Wed, 27 Feb 2013 17:46:59 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D58D121F8767 for ; Wed, 27 Feb 2013 17:46:55 -0800 (PST) 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 r1S1guhF002686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Feb 2013 17:42:56 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1S1guhF002686 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362015777; bh=xTHrMFiyNQm7nVkgDR6VCTmvU9I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WkpNcVEZiPgJFbWOu72Fbgc/nXf8KRaXdNRBgkQUaHivZFsQkiPShV+sfVZyTrFgK n1XujVZdUSwLLlrqJ++J3brK8wC7J35DU8TDSLg9LcrlT4hJ/MEegFt5WPP7KjYLbF 2zJP/GyC2pjlikGlKqIXbfTYqAbXSJSccIJI9F6M= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Wed, 27 Feb 2013 17:42:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Feb 2013 17:42:57 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 01:47:00 -0000 Sorry for the delay=85 Just now getting to this. Section 1. Paragraph 1 "=85normally they are not used on the publicly routable=85" Suggest should be changed to "=85they should not be used on the publicly = routable=85" Paragraph 3 "=85networks has been confused for network operators." Suggest should be changed to "=85networks has been confusing to network = operators." Paragraph 3 "=85while network operators run their entire networks on ULA.." Can you cite some examples of this? I can't imagine a functional network = running entirely on ULA unless it is a completely disconnected network. Section 2.1.2 Paragraph 1 "ULA is intended to be globally unique to avoid collision" Suggest should be changed to "ULA is intended to have a low probability = of collision, but uniqueness is not guaranteed." Also paragraph 1 "=85Overlapping is cited as a deficiency with how [RFC1918] addresses = were deployed, and ULA was designed to overcome this deficiency." This is somewhat revisionist history IMHO. The whole point of RFC-1918 = was to provide overlapping addresses for non-connected and NAT-based = networks to allow IPv4 address conservation. Prior to the need for = address conservation and re-use in IPv4, no one saw any need for = anything like RFC-1918 or ULA. Indeed, I still, even after reading this = draft don't see a use case for ULA that would not be served equally well = (if not better) by GUA. Section 2.1.3 Paragraph 2 "On the other hand, many organizations have security policies and = architectures based around the local-only routing of [RFC1918] addresses = and those policies may directly map to ULA." Any security policy which depends on the semantics of [RFC1918] is = flawed. Routing leaks of [RFC1918] space are commonplace and there are = many "crafted packet" attacks perfectly capable of delivering datagrams = to [RFC1918] based networks. Any pretense that [RFC1918] is a security = mechanism is fictional and should not be codified in an RFC, IMHO. Section 2.2.2.1 IMHO, this section should be deleted in its entirety or at least come = with a strong cautionary note that such designs are ill-conceived and = detrimental in nature. Pretending that NAT or NPT improve security at = all is dubious at best. In fact, NPT and especially NAT provide more = tall weeds for attackers to hide in, if anything. AL Proxies can be implemented equally effectively using GUA and there is = no significant advantage to ULA in such a case. Section 3.1 The last sentence should be deleted. GUA is an equally viable option for = these networks. Section 3.3.2 I'm unable to decipher Paragraph 2, so I cannot make a suggestion on = rewording it. However, since I can't tell what you're trying to say, I'm = pretty sure it needs to be rewritten. Section 5 IANA considerations should be updated to point to RFC4193 in a similar = manner to section 4. [End of comments] Owen From brian.e.carpenter@gmail.com Thu Feb 28 00:50: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 6654221F86A8 for ; Thu, 28 Feb 2013 00:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.898 X-Spam-Level: X-Spam-Status: No, score=-100.898 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuGwEGNmlfwJ for ; Thu, 28 Feb 2013 00:50:18 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8683821F8514 for ; Thu, 28 Feb 2013 00:50:18 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so1208304wge.34 for ; Thu, 28 Feb 2013 00:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7UreTUWyx8uKAySzz2lHgMcZkrMCt7qWGeDno4xmZKg=; b=KHH0ybm0bLAj8k7bOxIDWrwxJIQBkSNmOzu7JNjgFA8IpuvaQ2wvTb3eaNyMvpOfNl Yqs4gELnppyZwnJku+YMFbWYvuoo7KbldtrTFh/3+U//b/XLiCtfqJDfyaf6KUSANhXe gPz4EUM9ELnvMe4pZGdW5Ew51unJSUt2vFqsRe9hObAzim7FYC+u/eGZc1ql0Grsn6nF 8FURoi9qsY6CxgDW1GTa096edREP0xyLP+t0w9N37Z6BQ9xjz8qHIaC4yeTzeaH853I7 xS4hcxZkGMyPG9W90pEu/EPArEM0bVFF78Zp2x+qagkvrTA/U5cX/D5OJiJ2Hk9XokAw a2Zw== X-Received: by 10.194.6.2 with SMTP id w2mr9289674wjw.10.1362041417719; Thu, 28 Feb 2013 00:50:17 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-166.as13285.net. [2.101.188.166]) by mx.google.com with ESMTPS id cf8sm13862854wib.1.2013.02.28.00.50.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 00:50:16 -0800 (PST) Message-ID: <512F1A52.60806@gmail.com> Date: Thu, 28 Feb 2013 08:50:26 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> In-Reply-To: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 08:50:20 -0000 Owen, On 28/02/2013 01:42, Owen DeLong wrote: =2E.. > "ULA is intended to be globally unique to avoid collision" >=20 > Suggest should be changed to "ULA is intended to have a low > probability of collision, but uniqueness is not guaranteed." The best thing for this point is to refer to the extensive discussion in RFC 4193, where it is shown that the probability of collision is extremely low. >=20 > Also paragraph 1 >=20 > "=E2=80=A6Overlapping is cited as a deficiency with how [RFC1918] > addresses were deployed, and ULA was designed to overcome > this deficiency." >=20 > This is somewhat revisionist history IMHO. The whole point of > RFC-1918 was to provide overlapping addresses for > non-connected and NAT-based networks to allow IPv4 address > conservation. Prior to the need for address conservation and > re-use in IPv4, no one saw any need for anything like > RFC-1918 or ULA. Indeed, I still, even after reading this > draft don't see a use case for ULA that would not be served > equally well (if not better) by GUA. Well, there are arguments for stable, non-ISP-dependent and non-registry-dependent prefixes, but we don't have to justify ULAs in this draft: that was done by RFC 4193. I think that the disconnected-network and homenet scenarios need to be further explored in this draft. >=20 > Section 2.1.3 >=20 > Paragraph 2 >=20 > "On the other hand, many organizations have security policies > and architectures based around the local-only routing of > [RFC1918] addresses and those policies may directly map to > ULA." >=20 > Any security policy which depends on the semantics of > [RFC1918] is flawed.=20 That whole question is explored in RFC 4864, as well as the extent to which ULAs fit in. But the objective fact is as stated here: many organizations base their security on RFC 1918. I don't like it, you don't like it, but it's the real world. >=20 > Section 2.2.2.1 >=20 > IMHO, this section should be deleted in its entirety or at > least come with a strong cautionary note that such designs > are ill-conceived and detrimental in nature. Pretending that > NAT or NPT improve security at all is dubious at best. In > fact, NPT and especially NAT provide more tall weeds for > attackers to hide in, if anything. Same comment. We could certainly give pros and cons, but it would be misleading to pretend that such deployments won't happen. > AL Proxies can be implemented equally effectively using GUA > and there is no significant advantage to ULA in such a case. Well, you can avoid renumbering, and multihome without PI, for a start. > Section 3.1 >=20 > The last sentence should be deleted. GUA is an equally viable > option for these networks. Only if you have an ISP, which by definition you don't. Brian From owen@delong.com Thu Feb 28 01:25: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 4CC9C21F8A45 for ; Thu, 28 Feb 2013 01:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDDg-dUtss2O for ; Thu, 28 Feb 2013 01:25:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC0121F8A25 for ; Thu, 28 Feb 2013 01:25:54 -0800 (PST) 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 r1S9NtBB012343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 01:23:55 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1S9NtBB012343 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362043435; bh=nIz5PBCCZGXhCfOVy2GMWiOIERE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F2DbnvuVAqiTQqBB22sRYCI5ZEd3cEy2GiPQDfhf8uKmReTqgKZVPBXvQW183BoPL +WwZJ9vDujcB4yGXHdASkuYXsrawpoCOu7ZDF/vTdy4U2xIYlMMmB+sYdJUjUZb0Uj dViXf/+/vFgkgvSncmmC+H7LnRI9T7UjvnSULVr4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <512F1A52.60806@gmail.com> Date: Thu, 28 Feb 2013 01:23:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 28 Feb 2013 01:23:55 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 09:25:59 -0000 On Feb 28, 2013, at 00:50 , Brian E Carpenter = wrote: > Owen, >=20 > On 28/02/2013 01:42, Owen DeLong wrote: > ... >> "ULA is intended to be globally unique to avoid collision" >>=20 >> Suggest should be changed to "ULA is intended to have a low >> probability of collision, but uniqueness is not guaranteed." >=20 > The best thing for this point is to refer to the extensive > discussion in RFC 4193, where it is shown that the probability > of collision is extremely low. >=20 I'd be fine with that as an alternative as well, but the current = language fails. >>=20 >> Also paragraph 1 >>=20 >> "=85Overlapping is cited as a deficiency with how [RFC1918] >> addresses were deployed, and ULA was designed to overcome >> this deficiency." >>=20 >> This is somewhat revisionist history IMHO. The whole point of >> RFC-1918 was to provide overlapping addresses for >> non-connected and NAT-based networks to allow IPv4 address >> conservation. Prior to the need for address conservation and >> re-use in IPv4, no one saw any need for anything like >> RFC-1918 or ULA. Indeed, I still, even after reading this >> draft don't see a use case for ULA that would not be served >> equally well (if not better) by GUA. >=20 > Well, there are arguments for stable, non-ISP-dependent and > non-registry-dependent prefixes, but we don't have to justify > ULAs in this draft: that was done by RFC 4193. >=20 I've heard the arguments and I remain somewhat unconvinced. However, as you say, 4193 is already on the books, so this draft doesn't need to be a commercial. > I think that the disconnected-network and homenet scenarios need > to be further explored in this draft. >=20 Agreed. FWIW, My homenet has a stable non-ISP-dependent prefix and it works just fine. (2620:0:930::/48) >>=20 >> Section 2.1.3 >>=20 >> Paragraph 2 >>=20 >> "On the other hand, many organizations have security policies >> and architectures based around the local-only routing of >> [RFC1918] addresses and those policies may directly map to >> ULA." >>=20 >> Any security policy which depends on the semantics of >> [RFC1918] is flawed.=20 >=20 > That whole question is explored in RFC 4864, as well as > the extent to which ULAs fit in. But the objective fact is > as stated here: many organizations base their security > on RFC 1918. I don't like it, you don't like it, but it's > the real world. >=20 No, they don't. They base their security on stateful inspection. They don't realize that the mutilation of the packet header doesn't actually help their security beyond its default stateful inspection behavior, but, the reality is that the stateful inspection behavior is what provides security. Without that behavior, (for example, an NPT that doesn't maintain a state table), there is no security. However, there are still additional tall weeds for the bad guys to hide in provided by the obfuscation layer. >>=20 >> Section 2.2.2.1 >>=20 >> IMHO, this section should be deleted in its entirety or at >> least come with a strong cautionary note that such designs >> are ill-conceived and detrimental in nature. Pretending that >> NAT or NPT improve security at all is dubious at best. In >> fact, NPT and especially NAT provide more tall weeds for >> attackers to hide in, if anything. >=20 > Same comment. We could certainly give pros and cons, but it > would be misleading to pretend that such deployments won't > happen. >=20 Then Let's put a strong cautionary not in and acknowledge that in spite of our best efforts at education, people will do profoundly dumb things. >> AL Proxies can be implemented equally effectively using GUA >> and there is no significant advantage to ULA in such a case. >=20 > Well, you can avoid renumbering, and multihome without PI, > for a start. >=20 What is the significant benefit to "without PI"? PI seems to be very nice as near as I can tell. It is working very well here. >> Section 3.1 >>=20 >> The last sentence should be deleted. GUA is an equally viable >> option for these networks. >=20 > Only if you have an ISP, which by definition you don't. ?? I know of a number of networks that are using GUA for those purposes without involving an ISP. Could you explain why you think that's not possible? Owen From owen@delong.com Thu Feb 28 01:42: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 0FBAA21F8ABC for ; Thu, 28 Feb 2013 01:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.567 X-Spam-Level: * X-Spam-Status: No, score=1.567 tagged_above=-999 required=5 tests=[AWL=-4.168, BAYES_00=-2.599, GB_SUMOF=5, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn-1oeagXm12 for ; Thu, 28 Feb 2013 01:42:12 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF2221F8AB4 for ; Thu, 28 Feb 2013 01:41:16 -0800 (PST) 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 r1S9cI9A013886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 01:38:18 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1S9cI9A013886 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362044299; bh=27AvX+D7M7SzKfCMREdHWB9rgPE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=FfvIRj9GBUCzIs9d/D9aHqSe4zaPRyKz/ZPYjrbubjkP0aubAhhaWUh4uhEKJNR0N Dmbww/FQy7dzU9SrUgHi7Q/9M+1WGJ731ZVmaYuqBYfE+LZ4S/Sc5/itqxOQjLCBfT ioS64HXoAxjdd+tOICDhYZCQ5q5l51yRfdalkTI4= Content-Type: multipart/alternative; boundary="Apple-Mail=_B2F6059F-5026-4CD0-B70C-437E968E0142" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <201302281653438909933@chinamobile.com> Date: Thu, 28 Feb 2013 01:38:10 -0800 Message-Id: References: <201302201509342346215@chinamobile.com>, <512485CC.5010102@bogus.com>, <7D525337-B6C9-40D5-BF24-CC1C1E56A2B7@delong.com> <201302281653438909933@chinamobile.com> To: "maqiongfang" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 28 Feb 2013 01:38:19 -0800 (PST) Cc: IPv6 Ops WG , v6ops-chairs , draft-ma-v6ops-ipv6-address-assignment Subject: Re: [v6ops] Some questions on 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: Thu, 28 Feb 2013 09:42:14 -0000 --Apple-Mail=_B2F6059F-5026-4CD0-B70C-437E968E0142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On Feb 28, 2013, at 00:53 , "maqiongfang" = wrote: > Owen, > =20 > Thank you very much for your serious and long comments. There are some = imprecise descriptions and wordings in the draft, and your comments help = me to=20 > make it clear.=20 > =20 > Section 2 the needs of management : address palnning should be easy to = manage. for example, the lacation informantion or network type (wireless = network,=20 > wlan,) can be embodied in the address. > The Qos of certain service have special requirements to the number of = bits of address aggregation, so the address assignment should take the = special=20 > requiremnts into account. (this requirement is derived from IPv4, if = IPv6 should also consider it? ) > =20 These sound like you're overlapping the draft regarding semantic = addressing. I think that topic is better addressed in that draft. > Section 3=A3=AC we think that the number of users under mobile hotspot = is fewer than in the home broadband=A3=AC so we assign a shorter prefix = without actual=20 > user surveys. Maybe you are right that a /60 is a little less. There is, IMHO, no reason to assign anything longer than a /48 to any = end-site ever. Whether it's a dorm room, a cell phone, an apartment, a single family = detached home, a warehouse or a small business, there's no need to = assign a long prefix. A /60 is certainly too restrictive. A /56 might be OK for a few years, = but probably won't last all that long. However, if we do standardize on = these longer prefixes, we are likely to stifle innovation and creativity = in the applications space for many years to come. > Section 4 ,thanks for your rewrite. I think the train of thoughts is = different. In the example, the 30 thousand users means home gateways , = I assume=20 > that each home gateway contains a single subscriber, each WAN segment = receive a /64 and each subscriber receive a /56( or longer /48 as your = advice).=20 > =20 /48 is shorter, not longer. Shorter prefix =3D larger network. > You said that =A1=B0put 200 subscribers on a given WAN segment=A1=B1. = Do you mean that subscribers of enterprise? My DSL at my residence, for example, has a WAN segment that includes me = and several other customers. It's addressed with an IPv4 /24. I presume = if it were to have IPv6 capability, it would get a /64 to work along = side the /24. My router has a single node address within that /24. Other customers also have single node addresses within that /24. That is = what I mean by 200 subscribers on a given WAN segment. Obviously other topologies are possible, including 1 subscriber per WAN = segment, in which case, a /64 for the WAN segment is still equally = viable. > =20 > section5, Maybe the figure caused some misunderstanding = in this example. I do not mean to use uniform sizes for all divisions. = The size of P0 is fixed and sizes of=20 > other divisions are depended on the requirements of specific network = and are not the same generally.=20 > =20 > I do not mean that The number of network address and the user's = address is equal. The network address is generally far less than the = user's address, > we may assign 4 bit for the type flag, wherein 1/16 for network = infrastructure and other for customers or reserved. > =20 Yes, this is very unclear as written. I'm still not sure I am in = complete agreement even with the concept presented, however. Owen > =20 > many thanks and best regards. > =20 > =20 > Qiongfang > =20 > =20 > 2013-02-28 > =20 > =B7=A2=BC=FE=C8=CB=A3=BA Owen DeLong > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2013-02-21 01:01:19 > =CA=D5=BC=FE=C8=CB=A3=BA joel jaeggli > =B3=AD=CB=CD=A3=BA maqiongfang; fred@cisco.com; = draft-ma-v6ops-ipv6-address-assignment; IPv6 Ops WG; v6ops-chairs > =D6=F7=CC=E2=A3=BA Re: [v6ops] Some questions on = draft-ma-v6ops-ipv6-address-assignment > Summary: >=20 > As written, I cannot support this draft. It is divergent from what I = have come > to believe are the best practices for numbering IPv6 networks. This = document > seems to incorporate a significant amount of IPv4-think and = over-conservative > granularity in the initial sections, while providing contradictory and = confusing > advice in section 5. >=20 > A more detailed description of my concerns: >=20 > Section 2 (3) I am unclear what you mean by the second bullet point. >=20 > Section 2(4) is similarly unclear to me. >=20 > Section 3 makes no allowance for the benefits of providing a uniform = assignment size to all > subscribers. There is nothing wrong with assigning a /48 to each = end-site and no reason > to discourage this practice. >=20 > Section 3(2) should be rewritten replacing MiFi with "Mobile Hotspot = or other portable > on-demand router technology". I do not agree that such a device should = receive only > a /60. I would support rewording to "at least a /60 and no more than a = /48." >=20 > Section 3(3) I do not agree with limiting broadband CPE to /56. There = is no reason > not to assign these devices a /48. I could accept tis draft if it were = reworded to > "at least a /56 and no more than a /48." >=20 > Section 3(4) should be reworded to "a /48 per end-site where an = end-site is > a single structure, building, or tenant in a multi-tenant structure or = building". > There is no reason to count hosts in IPv6 and these words should be = removed. > In IPv6, we should be counting subnets, not hosts. >=20 > Section 3(5) should be rewritten as "Loopback interfaces requiring = public addresses > should, generally be assigned a /128. In certain applications, a = shorter prefix may > be necessary or desirable." >=20 > Section 3(6) is very poorly constructed and implies that a datacenter = should assign > a /127 to each server and connect each server separately to its = upstream router. > While assigning /127s to point to point links can be an expediency to = work around > certain security issues today, I do not support codifying it as a = permanent=20 > recommendation. Rather I would prefer to see "Point to point links = should be > assigned /64s, though it may be desirable to configure them as /127s = to work > around certain security concerns." or words to that effect. >=20 > Section 4 paragraph 3 you have reversed LAN and WAN. The WAN requires > a /64 (or a /127) and the LAN requires a /48 (or less). Further, = computing > the address pool as a combined total may not always yield optimal = results. > There are good reasons to aggregate the LAN and WAN segments = separately > in many cases as the WAN segments may be better aggregated across > multiple BRAS in a serving center, while each BRAS should have its own > aggregate pool of LAN addresses to allocate to subscribers. Further, I > believe it is good practice to round such pool assignments up to the = next > nibble boundary which is neglected in this paragraph. A suggested = rewrite: >=20 > The calculation of address pool in a broadband access server such > as a BRAS or CMTS is slightly more complicated. In the broadband > network, assume that user capacity configured in a BRAS is > roughly 30 thousand end-sites. Each end site needs a prefix from > which LAN segments can be assigned and a WAN interface address. > The WAN interface numbering must be deployed on both the CPE and > the provider's access gear and a single WAN interface prefix may be > shared among multiple subscribers. In the case where each WAN > segment contains a single subscriber, each segment should receive > a /64. In the case where multiple subscribers share a single segment, > a single /64 should be used for each shared segment. Each > subscriber should receive a /48 (or longer) prefix. The sum of the > expected number of prefixes (30 thousand in this case) should be > calculated as a number of bits (30,000 would round up to 32768 > or 15 bits) and rounded up to a multiple of four (16 bits in this > case). This number should then be subtracted from the largest > prefix size to be issued (/48 for example would yield a /32). > The number of WAN segments should be similarly calculated > as a number of /64s (for example, let's say we put 200 subscribers > on a given WAN segment), this would be 30,000/200=3D150 /64s > or 8 bits. Since 8 is already a multiple of 4, no additional rounding=20= > is required. 64-8 is 56, so a /56 is required for WAN segments. > Thus, the example broadband server would receive a /32 for > subscriber addressing and a /56 for WAN segment numbering. >=20 > Section 5, it should be made clear that this is just one example of = one > way to carve up addresses and may not be applicable to all networks. > In fact, I would argue that placing "type" at the highest level of = aggregation > may be very undesirable in most deployments. >=20 > The assumption that all persons reading this document will receive > their global prefix from an LIR is also incorrect. Many will be = receiving > directly from an RIR or (in AP region, NIR). >=20 > I have never seen a network where setting aside 1/2 of the address > space for network infrastructure and leaving only 1/2 of the address > space for customer assignments makes any sense at all. Thus, I > do not think that your P0 type flag description is supportable. >=20 > Further, it may not be desirable to use uniform sizes for all = divisions > at this first level. Often, for example, it may be desirable to set = aside > a chunk of address space for all oeprational infrastructure separate > from the address space used to meet client needs. For example, > let us consider a small ISP which has received 2001:db8::/32 > from its RIR. It is common practice for such an ISP to take the > first /48 (2001:db8:0::/48 (or 2001:db8::/48)) for use in numbering > its infrastructure. It may take an additional /48 per manned site > for its own internal IT usage. =46rom within the first /48, networks > would be created for DNS servers, network device loopback > addressing, web servers, DHCP servers, etc. >=20 > Your explanation of the P2 field is vague. A better description > might be that P2 is used to number separate instantiations > of the types of networks numbered in P1. In some cases, this > may indicate a subtype (extending the proposed metaphor). >=20 > P3 and P4 descriptions imply that geographical aggregation > is preferable to topological aggregation. I believe this is > entirely false and I would suggest that the terms Province > and City be replaced with the terms "Topological Region > and "Serving Site", respectively. >=20 > In P5, the term city should similarly be replaced with "Serving > Site". >=20 > Section 7, I believe there are no security conisderations > applicable to address assignment beyond those described > above. >=20 > Section 8, I don't see any IANA implications to this set of > recommended addressing practices. >=20 >=20 >=20 > Owen --Apple-Mail=_B2F6059F-5026-4CD0-B70C-437E968E0142 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 maqiongfang@chinamobile.com> wrote:

Owen,
 
Thank&n= bsp;you very much for your serious and = long comments. There are some imprecise desc= riptions and wordings in the draft, and = ;your comments help me to 
make it=  clear. 
 
=
Section 2 the needs of management :&nbs= p;address palnning should be easy to manage.=  for example, the lacation informantion or&n= bsp;network type (wireless network, 
wlan,)&= nbsp;can be embodied in the address.
The Qos of certain service have spe= cial requirements to the number of bits = ;of address aggregation, so the address assi= gnment should take the special 
require= mnts into account. (this requirement is deri= ved from IPv4, if IPv6 should also cons= ider it? )
 

These sound like you're = overlapping the draft regarding semantic addressing.  I think that = topic is better addressed in that draft.

Section 3=A3=AC we think that&n= bsp;the number of users under mobile hotspot=  is fewer than in the home broadband=A3= =AC so we assign a shorter prefix witho= ut actual 
user surveys. Maybe you = ;are right that a /60 is a little = less.

There is, = IMHO, no reason to assign anything longer than a /48 to any end-site = ever.
Whether it's a dorm room, a cell phone, an apartment, a = single family detached home, a warehouse or a small business, there's no = need to assign a long prefix.

A /60 is = certainly too restrictive. A /56 might be OK for a few years, but = probably won't last all that long. However, if we do standardize on = these longer prefixes, we are likely to stifle innovation and creativity = in the applications space for many years to = come.

<= div> 
You said that =A1=B0put&n= bsp;200 subscribers on a given WAN segment=A1= =B1. Do you mean that subscribers of en= terprise?
My DSL at my = residence, for example, has a WAN segment that includes me and several = other customers. It's addressed with an IPv4 /24. I presume if it were = to have IPv6 capability, it would get a /64 to work along side the /24. = My router has a single node address within that /24.
Other = customers also have single node addresses within that /24. That is what = I mean by 200 subscribers on a given WAN = segment.

Obviously other topologies are = possible, including 1 subscriber per WAN segment, in which case, a /64 = for the WAN segment is still equally viable.

 
<= /div>
section5,         &= nbsp;    = Maybe the figure caused some misunderstanding&nbs= p;in this example. I do not mean to&nbs= p;use uniform sizes for all divisions. The&n= bsp;size of P0 is fixed and sizes of&nb= sp;
other divisions are depended on the=  requirements of specific network and are&nb= sp;not the same generally. 
 = ;
I do not mean that The&nbs= p;number of network address and the user's&n= bsp;address is equal. The network address is=  generally far less than the user's add= ress,
 we may assign 4 bit for&nbs= p;the type flag, wherein 1/16 for network&nb= sp;infrastructure and other for customers or = ;reserved.
 
<= /div>

Yes, this is very unclear as = written. I'm still not sure I am in complete agreement even with the = concept presented, = however.

Owen

 
many thanks and bes= t regards.
 
 
Qiongfang
 
 
2013-02-28
 
=
=B7=A2=BC=FE=C8=CB=A3=BA Owen = DeLong
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2013-02-21  = 01:01:19
=CA=D5=BC=FE=C8=CB=A3=BA joel = jaeggli
=B3=AD=CB=CD=A3=BA maqiongfang; fred@cisco.com; = draft-ma-v6ops-ipv6-address-assignment; IPv6 Ops WG; = v6ops-chairs
=D6=F7=CC=E2=A3=BA Re: [v6ops] Some questions = on draft-ma-v6ops-ipv6-address-assignment
Summary:

As written, I = cannot support this draft. It is divergent from what I have = come
to believe are the best practices for numbering IPv6 = networks. This document
seems to incorporate a significant = amount of IPv4-think and over-conservative
granularity in the = initial sections, while providing contradictory and = confusing
advice in section 5.

A more = detailed description of my concerns:

Section 2 = (3) I am unclear what you mean by the second bullet = point.

Section 2(4) is similarly unclear to = me.

Section 3 makes no allowance for the = benefits of providing a uniform assignment size to = all
subscribers. There is nothing wrong with assigning a /48 = to each end-site and no reason
to discourage this = practice.

Section 3(2) should be rewritten = replacing MiFi with "Mobile Hotspot or other = portable
on-demand router technology". I do not agree that = such a device should receive only
a /60. I would support = rewording to "at least a /60 and no more than a = /48."

Section 3(3) I do not agree with limiting = broadband CPE to /56. There is no reason
not to assign these = devices a /48. I could accept tis draft if it were reworded = to
"at least a /56 and no more than a = /48."

Section 3(4) should be reworded to "a /48 = per end-site where an end-site is
a single structure, = building, or tenant in a multi-tenant structure or = building".
There is no reason to count hosts in IPv6 and these = words should be removed.
In IPv6, we should be counting = subnets, not hosts.

Section 3(5) should be = rewritten as "Loopback interfaces requiring public = addresses
should, generally be assigned a /128. In certain = applications, a shorter prefix may
be necessary or = desirable."

Section 3(6) is very poorly = constructed and implies that a datacenter should assign
a /127 = to each server and connect each server separately to its upstream = router.
While assigning /127s to point to point links can be = an expediency to work around
certain security issues today, I = do not support codifying it as a = permanent 
recommendation. Rather I would prefer to see = "Point to point links should be
assigned /64s, though it may = be desirable to configure them as /127s to work
around certain = security concerns." or words to that = effect.

Section 4 paragraph 3 you have reversed = LAN and WAN. The WAN requires
a /64 (or a /127) and the LAN = requires a /48 (or less). Further, computing
the address pool = as a combined total may not always yield optimal = results.
There are good reasons to aggregate the LAN and WAN = segments separately
in many cases as the WAN segments may be = better aggregated across
multiple BRAS in a serving center, = while each BRAS should have its own
aggregate pool of LAN = addresses to allocate to subscribers. Further, I
believe it is = good practice to round such pool assignments up to the = next
nibble boundary which is neglected in this paragraph. A = suggested rewrite:

The calculation = of address pool in a broadband access server such
as a BRAS or = CMTS is slightly more complicated. In the broadband
network, = assume that user capacity configured in a BRAS is
roughly 30 = thousand end-sites. Each end site needs a prefix from
which = LAN segments can be assigned and a WAN interface address.
The = WAN interface numbering must be deployed on both the CPE = and
the provider's access gear and a single WAN interface = prefix may be
shared among multiple subscribers. In the case = where each WAN
segment contains a single subscriber, each = segment should receive
a /64. In the case where multiple = subscribers share a single segment,
a single /64 should be = used for each shared segment. Each
subscriber should receive a = /48 (or longer) prefix. The sum of the
expected number of = prefixes (30 thousand in this case) should be
calculated as a = number of bits (30,000 would round up to 32768
or 15 bits) and = rounded up to a multiple of four (16 bits in this
case). This = number should then be subtracted from the largest
prefix size = to be issued (/48 for example would yield a /32).
The = number of WAN segments should be similarly calculated
as a = number of /64s (for example, let's say we put 200 = subscribers
on a given WAN segment), this would be = 30,000/200=3D150 /64s
or 8 bits. Since 8 is already a multiple = of 4, no additional rounding 
is required. 64-8 is 56, so = a /56 is required for WAN segments.
Thus, the example = broadband server would receive a /32 for
subscriber addressing = and a /56 for WAN segment = numbering.

Section 5, it should be = made clear that this is just one example of one
way to carve = up addresses and may not be applicable to all networks.
In = fact, I would argue that placing "type" at the highest level of = aggregation
may be very undesirable in most = deployments.

The assumption that all persons = reading this document will receive
their global prefix from an = LIR is also incorrect. Many will be receiving
directly from an = RIR or (in AP region, NIR).

I have never seen a = network where setting aside 1/2 of the address
space for = network infrastructure and leaving only 1/2 of the = address
space for customer assignments makes any sense at all. = Thus, I
do not think that your P0 type flag description is = supportable.

Further, it may not be desirable = to use uniform sizes for all divisions
at this first level. = Often, for example, it may be desirable to set aside
a chunk = of address space for all oeprational infrastructure = separate
from the address space used to meet client needs. For = example,
let us consider a small ISP which has received = 2001:db8::/32
from its RIR. It is common practice for such an = ISP to take the
first /48 (2001:db8:0::/48 (or 2001:db8::/48)) = for use in numbering
its infrastructure. It may take an = additional /48 per manned site
for its own internal IT = usage. =46rom within the first /48, networks
would be created = for DNS servers, network device loopback
addressing, web = servers, DHCP servers, etc.

Your explanation of = the P2 field is vague. A better description
might be that P2 = is used to number separate instantiations
of the types of = networks numbered in P1. In some cases, this
may indicate a = subtype (extending the proposed metaphor).

P3 = and P4 descriptions imply that geographical aggregation
is = preferable to topological aggregation. I believe this = is
entirely false and I would suggest that the terms = Province
and City be replaced with the terms "Topological = Region
and "Serving Site", = respectively.

In P5, the term city should = similarly be replaced with = "Serving
Site".

Section 7, I believe = there are no security conisderations
applicable to address = assignment beyond those = described
above.

Section 8, I don't = see any IANA implications to this set of
recommended = addressing = practices.



Owen

= --Apple-Mail=_B2F6059F-5026-4CD0-B70C-437E968E0142-- From brian.e.carpenter@gmail.com Thu Feb 28 03:29: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 03C3F21F8B6D for ; Thu, 28 Feb 2013 03:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.948 X-Spam-Level: X-Spam-Status: No, score=-100.948 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUcFN8YE+jx6 for ; Thu, 28 Feb 2013 03:29:40 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71D21F8B4C for ; Thu, 28 Feb 2013 03:29:40 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so1317384wgb.0 for ; Thu, 28 Feb 2013 03:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WGHgCQwh1GKq0OxzWBdWfUgA6/S+dtqQUX9ahqItE+E=; b=Y2iUS3b6otJZLlQD567fZRUO03UiXM5o+qkZogzZy7fk+jb6+n4Erf5exL+B2FW3RC MipBXI4V3rqYO3KBlDLv3BgNv1egZCAdTZfTJ01lgx09NPAswghPbNi793A6J7tk5MJ6 J8ws9BeGItA5XIiCadUYuqBJc9gke9JQzaue9cC1uy2xBwKJbRf9Mn1bSQEV3rW9mTjJ +86R72gHqrWAgEiEmqSVcl+BnOeyJG61XBlHrJDtOJhaV4pnAjMOdturO4QgZ3KopdXb k/pScgWxDbiD4fVb6BkRMd5xfiRIz5uHsiZEJnsacv+shwvCmLHpWdHacGjq1eF2lvUK 8HeQ== X-Received: by 10.180.91.106 with SMTP id cd10mr9920004wib.6.1362050979479; Thu, 28 Feb 2013 03:29:39 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-166.as13285.net. [2.101.188.166]) by mx.google.com with ESMTPS id eo1sm32749485wib.8.2013.02.28.03.29.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 03:29:38 -0800 (PST) Message-ID: <512F3FAC.7060905@gmail.com> Date: Thu, 28 Feb 2013 11:29:48 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 11:29:41 -0000 On 28/02/2013 09:23, Owen DeLong wrote: > On Feb 28, 2013, at 00:50 , Brian E Carpenter wrote: ... > What is the significant benefit to "without PI"? Saving BGP4. Using a PI prefix is selfish as far as the Internet is concerned, so we need to encourage alternatives. > > PI seems to be very nice as near as I can tell. It is working very > well here. > >>> Section 3.1 >>> >>> The last sentence should be deleted. GUA is an equally viable >>> option for these networks. >> Only if you have an ISP, which by definition you don't. > > ?? I know of a number of networks that are using GUA for those > purposes without involving an ISP. Could you explain why you > think that's not possible? You need to get your prefix either from an ISP or from an LIR. You don't need to talk to anyone, or pay anyone, to get your ULA prefix. In fact, it can be generated automatically in a SOHO scenario, so that the user doesn't have to know anything. Brian From victor.kuarsingh@gmail.com Thu Feb 28 04:51: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 A595E21F8621 for ; Thu, 28 Feb 2013 04:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg18YomgQxEm for ; Thu, 28 Feb 2013 04:51:36 -0800 (PST) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 88B1A21F8484 for ; Thu, 28 Feb 2013 04:51:36 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id f27so1453429iae.39 for ; Thu, 28 Feb 2013 04:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=lxwThDOA6uXDxaBhCKPtbvk7WdPJnSXAQ/et9UcvbXA=; b=dXiGquL2Tv5vaOP34OnlwZYafHtnQt15ky3xwcNhIWRs15Qtw0xzcN8Pi35b2MS5jj IJ7TjTgI37YMnrG/T7MeZ67vvDUTkZ6geAdjzBa4nretb7hSSUhYCWX68c+LZZmZnTio emf8iDZCGRDCnclXhDhjtnto5YWZ5zYBRwGnbPgHyfNtKnnR3pCZTBMFmbMBaAw7idfW SWkkpBq40YjD90h37ImKszjHG2doTO0HgP7m2mRDPtC8NdhTLj84ipjSOKY/Xv+T9n8R A90J8pRl+tH4YKW2Krp2g1b1kEArRvAULf0vTnsBlLiIFXdUEeMFz4HP+ojaaE2cWNMm 6Log== X-Received: by 10.50.53.143 with SMTP id b15mr10024855igp.69.1362055892518; Thu, 28 Feb 2013 04:51:32 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id a3sm5474194igq.5.2013.02.28.04.51.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Feb 2013 04:51:31 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Feb 2013 07:51:27 -0500 From: Victor Kuarsingh To: Owen DeLong , Brian E Carpenter Message-ID: Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 12:51:41 -0000 On 2013-02-28 4:23 AM, "Owen DeLong" wrote: > >On Feb 28, 2013, at 00:50 , Brian E Carpenter > wrote: > >> > >>> >>> Section 2.1.3 >>> >>> Paragraph 2 >>> >>> "On the other hand, many organizations have security policies >>> and architectures based around the local-only routing of >>> [RFC1918] addresses and those policies may directly map to >>> ULA." >>> >>> Any security policy which depends on the semantics of >>> [RFC1918] is flawed. >> >> That whole question is explored in RFC 4864, as well as >> the extent to which ULAs fit in. But the objective fact is >> as stated here: many organizations base their security >> on RFC 1918. I don't like it, you don't like it, but it's >> the real world. >> > >No, they don't. They base their security on stateful inspection. > >They don't realize that the mutilation of the packet header doesn't >actually help their security beyond its default stateful inspection >behavior, but, the reality is that the stateful inspection behavior >is what provides security. Without that behavior, (for example, >an NPT that doesn't maintain a state table), there is no security. > >However, there are still additional tall weeds for the bad guys >to hide in provided by the obfuscation layer. > >>> Where I agree that blind/basic policy around RFC1918 is poor, I think there is some validity in having well known ranges and applying certain types of perimeter and routing protection around it. Speaking from an SP view, there are many functions which are served well by RFC1918 and with some loose association to ULAs (can be used for equivalent function). If a network admin uses ULAs for certain functions, it's a lot easier to filter/protect agains a well known contiguous range. However, other security mechanisms need to be in place - basic filtering is a poor single form of security. One of the comments I had before on this draft was that the notion of ULA != RFC1918 is an important distinction (hopefully that would get network administrators to re-think any loose security they may have around RFC1918 before applying it to ULAs if used). Regards, Victor K From victor.kuarsingh@gmail.com Thu Feb 28 05:01: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 E85BF21F8836 for ; Thu, 28 Feb 2013 05:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6ID-qsIHCRA for ; Thu, 28 Feb 2013 05:01:40 -0800 (PST) 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 D0A6721F882A for ; Thu, 28 Feb 2013 05:01:40 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id 13so2029426iea.28 for ; Thu, 28 Feb 2013 05:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=2ORiDsIiphxqdMIIi+2s63rtedsu7GtgCxCqTAGKjw8=; b=kZ9lLlLnIOg6XIuC+4u4SVswp/24fIBuqSrFEMKuGDikwaOyRf8DXHh0hHy3L5Wjua XU5xMrUUacgZe289RgMgbm7POJ6GL5J1hm75X+2/SvhOEMHeoZiiioa4u5ZPnmxfsvsf aWdvo5qGodOJNbgg3rvJRRF6vf33mGTX2c1VOKJbTD288ckKe/CLYWm096EMAnuPwQUF hk1OLWNrJNMsTEnoWAoCDgZdENStc8XQJf/sY5OOX182+5lAo+jl/Mjz/VMykyucADKC XeD13r6EeoozwKL7hWHHwKa7IuI4Dlmdv/5zImoenhqbH7OklMbwWiMZiL3s9ju5lX/j dGhg== X-Received: by 10.50.170.69 with SMTP id ak5mr3625994igc.56.1362056500380; Thu, 28 Feb 2013 05:01:40 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id s8sm5505546igs.0.2013.02.28.05.01.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Feb 2013 05:01:39 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Feb 2013 08:01:34 -0500 From: Victor Kuarsingh To: Brian E Carpenter , Owen DeLong Message-ID: Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review In-Reply-To: <512F3FAC.7060905@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 13:01:42 -0000 On 2013-02-28 6:29 AM, "Brian E Carpenter" wrote: >On 28/02/2013 09:23, Owen DeLong wrote: >> On Feb 28, 2013, at 00:50 , Brian E Carpenter >> wrote: > >... >> What is the significant benefit to "without PI"? > >Saving BGP4. Using a PI prefix is selfish as far as the >Internet is concerned, so we need to encourage alternatives. PA space can be applied to a network, distributed, routed and provided to customers in a very efficient manner. It's actually quite easy to apply and route IPv6 PA space very efficiently in a large network. PI space diverges from this and lives on it's own along side all the PA optimizations. This is a bit outside the context of the ULA draft, but just throwing my opinion out there on this topic. Regards, Victor K > >> >> >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From bill.jouris@insidethestack.com Thu Feb 28 07:01: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 5F99021F85A0 for ; Thu, 28 Feb 2013 07:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaEjcl5A9Zqe for ; Thu, 28 Feb 2013 07:01:34 -0800 (PST) Received: from nm5-vm0.access.bullet.mail.mud.yahoo.com (nm5-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.155]) by ietfa.amsl.com (Postfix) with ESMTP id D95D021F8556 for ; Thu, 28 Feb 2013 07:01:30 -0800 (PST) Received: from [66.94.237.199] by nm5.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 15:01:30 -0000 Received: from [66.94.237.106] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 15:01:30 -0000 Received: from [127.0.0.1] by omp1011.access.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 15:01:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 448801.90882.bm@omp1011.access.mail.mud.yahoo.com Received: (qmail 27973 invoked by uid 60001); 28 Feb 2013 15:01:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362063690; bh=mnHLkCh1DBOVpcVsk7r0xlwJAbXUVoFFCltSlWymHqk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VJ0PvFKQvIj/fpoIaexrOymL4naRntqvVvQ6D5ZjKZwYiy/lx2UCfld5RZX9icgc3Z3vSeEioHOGG/90J+gdfw7Tyth+UShiHaMkjqmJ+YbNI+oOUlB0WL0H4aA3gqMjeGNJC6uccQ8Qn70X+PxImLGtiNC+Q9dY+fcx4Vvh+YI= X-YMail-OSG: rmsHEn8VM1n4cCDVKT8UOxWewNMk_FjF_QYKDz2DXEHYfzE ekFQ95znOmjaf0zi6i44crziLxspcU6PnfZH5h.E1VWBzOybFwPbrG1Xe7vm rsbW6CohpOxktzai1S5x6G2pnB4Hwxnhr86bK0SmYGpBCuTp1nR9LQBZE.D3 o81bb2lQ1lxg6ypxwkN83xmNFT_vZtqL_K9I1NgAjjHA0pfw2daKjvf7723F Ofejwc9x7OEo0rPoC5F4tWKssOY7qECKdml756uES.DTjJ0NaKE50oDa_I0j EI0pbINGV77ZXSf_BB5JqkbOi3OqpeYt8uMZfSJ.wXyazHat9T7Aifj.OhqJ inN7406cxDksYpNXrnp72RLwnthydPlgBE8PGBFr48JC3e4GNLsZMDSirAE2 K.joG.dlA9WHRKugJ7g6lbvojPft1WUraMkIQlWMj7ot6Px7o_pbe2LV4bn5 zBvlhlFK4LE649mYwtndzh4qbt2Igh1jSnkaiMAHeMX1EFE_eqllpNEby9HL X2hrVYj5.H0fgW46eIRFGzRmOyDzn5LvM.9q3Qp7L2wro7K96OTKfYzyTnC2 TtDeCMRQ6LAv4SXnDCZXBnkIhQvGhUZCO8VggXg7psC_xVWTCSk9mq5J_dp2 Vawroy6ZyMp_e2Wjs3brwYpSgsoo_Pijur75o7A3gCqha0b9EtuxIlg5NE2s 5o0LLEo8getFUaepb_tk1SbIKWaZnhcE- Received: from [50.148.178.232] by web2802.biz.mail.ne1.yahoo.com via HTTP; Thu, 28 Feb 2013 07:01:29 PST X-Rocket-MIMEInfo: 001.001, SXQgbWF5IGJlIHRoYXQsIGZvciBzb21lIGluZGl2aWR1YWxzLCAyNTYgc3VibmV0cyByZWFsbHkgaXMgInZlcnkgc21hbGwiLsKgIEJ1dCBpcyB0aGF0IHJlYWxseSBhbnl0aGluZyBsaWtlIHRoZSBub3JtP8KgIE9yIGxpa2VseSB0byBiZWNvbWUgdGhlIG5vcm0_DQoNCkFuZCBmb3IgdGhhdCBtaW5vcml0eSB3aG8sIGxpa2UgeW91LCBtaWdodCBiZSBjb25zdHJhaW5lZCwgd2h5IGNvdWxkbid0IHRoZXkgc2ltcGx5IGdldCBhIHNlY29uZCAyNTY_wqAgSXQncyBub3QgbGlrZSB3ZSBhcmUgbG9va2luZyBhdCABMAEBAQE- X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514 Message-ID: <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> Date: Thu, 28 Feb 2013 07:01:29 -0800 (PST) From: Bill Jouris To: Mark Andrews In-Reply-To: <20130227223926.05832302B138@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-2087554934-1362063689=:27342" Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 15:01:35 -0000 ---153701192-2087554934-1362063689=:27342 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It may be that, for some individuals, 256 subnets really is "very small".= =A0 But is that really anything like the norm?=A0 Or likely to become the n= orm? And for that minority who, like you, might be constrained, why couldn't the= y simply get a second 256?=A0 It's not like we are looking at mandating a r= estriction on giving anyone more than a single allocation. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Wed, 2/27/13, Mark Andrews wrote: From: Mark Andrews Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt To: "Gert Doering" Cc: v6ops@ietf.org Date: Wednesday, February 27, 2013, 2:39 PM In message <20130227181908.GE51699@Space.Net>, Gert Doering writes: > Hi, >=20 > On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: > > For example, at APNIC, based around 2^24 customers > > a /32 costs AUD 1,994 =3D=3D > > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&action= =3DCalculat > e > > and a /24 costs AUD 16,267 =3D=3D > > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F24&action= =3DCalculat > e >=20 > Ouch... 3c/annum and 0.1c/annum per /48 respectively =20 > This is exactly the sort of incentive the RIRs should *not* give (and > we don't do that in RIPE land). or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer allocations.=A0=A0=A0Both of those are less than the cost of getting the ethernet address that the CPE vendor paid to the IEEE. > OTOH, I don't have an issue with "/56s to residential customers", as I'm= =20 > still waiting for someone to explain to me why 256 subnets in the home=20 > is "too small".=A0 /60 feels a bit too small, though. Because it stiffles development.=A0=A0=A0When you have a people wearing a couple of subnets each it doesn't take long to use up 256 subnets. Today I have family and friends come over and grab a address wirelessly.=A0 It is not a long stretch to also have a prefix delegation or two occur in the future at the same time.=A0 256 is suddenly very small. Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0INTERNET: marka@= isc.org _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ---153701192-2087554934-1362063689=:27342 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It may be that, for some individuals, 256 sub= nets really is "very small".  But is that really anything like the nor= m?  Or likely to become the norm?

And for that minority who, li= ke you, might be constrained, why couldn't they simply get a second 256?&nb= sp; It's not like we are looking at mandating a restriction on giving anyon= e more than a single allocation.

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



--- On Wed, 2/2= 7/13, Mark Andrews <marka@isc.org> wrote:

From: Mark Andrews <marka@isc.org>
Subject: Re: [v= 6ops] new draft: draft-shishio-v6ops-dpvt
To: "Gert Doering" <gert@space.net>
Cc: v6ops@ietf.org
Date: Wednesday, February = 27, 2013, 2:39 PM


In message <20130227181908.GE51699@Space.Net>, = Gert Doering writes:
> Hi,
>
> On Wed, Feb 27, 2013 at 1= 0:42:03AM +1100, John Mann wrote:
> > For example, at APNIC, based= around 2^24 customers
> > a /32 costs AUD 1,994 =3D=3D
> &g= t; http://submit.apnic.net/c= gi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&action=3DCalculat
>= ; e
> > and a /24 costs AUD 16,267 =3D=3D
> > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&i= pv6=3D%2F24&action=3DCalculat
> e
>
> Ouch...
3c/annum and 0.1c/annum per /48 respectively

> This is exac= tly the sort of incentive the RIRs should *not* give (and
> we don't = do that in RIPE land).

or .01c/annum/56 and 0.1c/annum/48 assumuming= you need 16M customer
allocations.   Both of those are l= ess than the cost of getting the
ethernet address that the CPE vendor pa= id to the IEEE.

> OTOH, I don't have an issue with "/56s to resid= ential customers", as I'm
> still waiting for someone to explain to = me why 256 subnets in the home
> is "too small".  /60 feels a b= it too small, though.

Because it stiffles development.  &n= bsp;When you have a people wearing
a couple of subnets each it doesn't t= ake long to use up 256 subnets.
Today I have family and friends come ove= r and grab a address
wirelessly.  It is not a long stretch to also h= ave a prefix delegation
or two occur in the future at the same time.&nbs= p; 256 is suddenly very
small.

Mark
--
Mark Andrews, ISC1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 47= 42                 INTERN= ET: marka@isc.org
_______________________________________________v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailma= n/listinfo/v6ops
---153701192-2087554934-1362063689=:27342-- From mackermann@bcbsm.com Thu Feb 28 08:42: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 F119421F8B8F for ; Thu, 28 Feb 2013 08:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Mf++ls7oemV for ; Thu, 28 Feb 2013 08:42:44 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23A21F8B0A for ; Thu, 28 Feb 2013 08:42:43 -0800 (PST) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id C36AB136D88 for ; Thu, 28 Feb 2013 10:42:41 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 2EE1E136B77; Thu, 28 Feb 2013 10:42:40 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 11CCE4F8059; Thu, 28 Feb 2013 11:42:11 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 022D24F8055; Thu, 28 Feb 2013 11:42:11 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Thu, 28 Feb 2013 11:42:39 -0500 From: "Ackermann, Michael" To: Bill Jouris , Mark Andrews Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOFTtLbXD86QK2vUyzAUxw618/bZiPslSA//+/yaA= Date: Thu, 28 Feb 2013 16:42:38 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> In-Reply-To: <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A5FCB16PWN401EA160entc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 16:42:47 -0000 --_000_4FC37E442D05A748896589E468752CAA0A5FCB16PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And not to mention 18 quintillion hosts, in each of those 256 subnets. I hate to not be thinking =22Long term=22 or =22Out of the box=22, but = that is certainly not small by today's standards=21 From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Bill Jouris Sent: Thursday, February 28, 2013 10:01 AM To: Mark Andrews Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: draft-shishio-v6ops-dpvt It may be that, for some individuals, 256 subnets really is =22very = small=22. But is that really anything like the norm? Or likely to become = the norm? And for that minority who, like you, might be constrained, why couldn't = they simply get a second 256? It's not like we are looking at mandating a = restriction on giving anyone more than a single allocation. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Wed, 2/27/13, Mark Andrews = > wrote: From: Mark Andrews > Subject: Re: =5Bv6ops=5D new draft: draft-shishio-v6ops-dpvt To: =22Gert Doering=22 > Cc: v6ops=40ietf.org Date: Wednesday, February 27, 2013, 2:39 PM In message = <20130227181908.GE51699=40Space.Net>, Gert Doering writes: > Hi, > > On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: > > For example, at APNIC, based around 2=5E24 customers > > a /32 costs AUD 1,994 =3D=3D > > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&action=3DCa= lculat > e > > and a /24 costs AUD 16,267 =3D=3D > > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F24&action=3DCa= lculat > e > > Ouch... 3c/annum and 0.1c/annum per /48 respectively > This is exactly the sort of incentive the RIRs should *not* give (and > we don't do that in RIPE land). or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer allocations. Both of those are less than the cost of getting the ethernet address that the CPE vendor paid to the IEEE. > OTOH, I don't have an issue with =22/56s to residential customers=22, as = I'm > still waiting for someone to explain to me why 256 subnets in the home > is =22too small=22. /60 feels a bit too small, though. Because it stiffles development. When you have a people wearing a couple of subnets each it doesn't take long to use up 256 subnets. Today I have family and friends come over and grab a address wirelessly. It is not a long stretch to also have a prefix delegation or two occur in the future at the same time. 256 is suddenly very small. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: = marka=40isc.org _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A5FCB16PWN401EA160entc_ 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-->

And not to mention 18 quintillion hosts, in = each of those 256 subnets.    

 

I hate to not be thinking &=238220;Long = term&=238221; or &=238220;Out of the box&=238221;, but that is certainly = not small by today&=238217;s standards=21  

 

From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Bill Jouris
Sent: Thursday, February 28, 2013 10:01 AM
To: Mark Andrews
Cc: v6ops=40ietf.org
Subject: Re: =5Bv6ops=5D new draft: = draft-shishio-v6ops-dpvt

 

It may be that, for some individuals, 256 = subnets really is "very small".  But is that really = anything like the norm?  Or likely to become the norm?

And for that minority who, like you, might be constrained, why couldn't = they simply get a second 256?  It's not like we are looking at = mandating a restriction on giving anyone more than a single allocation.

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



--- On Wed, 2/27/13, Mark Andrews <marka=40isc.org> = wrote:


From: Mark Andrews <marka=40isc.org>
Subject: Re: =5Bv6ops=5D new draft: draft-shishio-v6ops-dpvt
To: "Gert Doering" <gert=40space.net>
Cc: v6ops=40ietf.org
Date: Wednesday, February 27, 2013, 2:39 PM


In message <2013022718= 1908.GE51699=40Space.Net>, Gert Doering writes:
> Hi,
>
> On Wed, Feb 27, 2013 at 10:42:03AM &=2343;1100, John Mann wrote:
> > For example, at APNIC, based around 2=5E24 customers
> > a /32 costs AUD 1,994 =3D=3D
> > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&act= ion=3DCalculat
> e
> > and a /24 costs AUD 16,267 =3D=3D
> > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F24&act= ion=3DCalculat
> e
>
> Ouch...

3c/annum and 0.1c/annum per /48 respectively

> This is exactly the sort of incentive the RIRs should *not* give = (and
> we don't do that in RIPE land).

or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer
allocations.   Both of those are less than the cost of = getting the
ethernet address that the CPE vendor paid to the IEEE.

> OTOH, I don't have an issue with "/56s to residential = customers", as I'm
> still waiting for someone to explain to me why 256 subnets in the = home
> is "too small".  /60 feels a bit too small, though.

Because it stiffles development.   When you have a people = wearing
a couple of subnets each it doesn't take long to use up 256 subnets.
Today I have family and friends come over and grab a address
wirelessly.  It is not a long stretch to also have a prefix = delegation
or two occur in the future at the same time.  256 is suddenly very
small.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: &=2343;61 2 9871 4742            =      INTERNET: marka=40isc.org
_______________________________________________
v6ops mailing list
v6ops=40ietf.org
https://www.ietf.org/mailman/listinfo/v6ops<= /o:p>

 


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_4FC37E442D05A748896589E468752CAA0A5FCB16PWN401EA160entc_-- From swmike@swm.pp.se Thu Feb 28 08:57: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 5C83521F8B9B for ; Thu, 28 Feb 2013 08:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQQVmKGmhUxH for ; Thu, 28 Feb 2013 08:57:30 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 09AC421F8A09 for ; Thu, 28 Feb 2013 08:57:28 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C05C59C; Thu, 28 Feb 2013 17:57:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BB7719A; Thu, 28 Feb 2013 17:57:25 +0100 (CET) Date: Thu, 28 Feb 2013 17:57:25 +0100 (CET) From: Mikael Abrahamsson To: "Ackermann, Michael" In-Reply-To: <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> Message-ID: References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 16:57:32 -0000 On Thu, 28 Feb 2013, Ackermann, Michael wrote: > And not to mention 18 quintillion hosts, in each of those 256 subnets. When I introduce people to IPv6 I tell them to stop thinking in terms of number of addresses and instead think of /64 per subnet. It's my opinion that the 2^64 addresses per subnet is irrelevant. -- Mikael Abrahamsson email: swmike@swm.pp.se From joelja@bogus.com Thu Feb 28 09:07: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 09CD321F8C3C for ; Thu, 28 Feb 2013 09:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H81Dnrsrjs7y for ; Thu, 28 Feb 2013 09:07:19 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 99A8621F8C14 for ; Thu, 28 Feb 2013 09:07:19 -0800 (PST) Received: from 01058a-bgressett.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 r1SH7H1l054308 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 28 Feb 2013 17:07:18 GMT (envelope-from joelja@bogus.com) Message-ID: <512F8EC5.6050200@bogus.com> Date: Thu, 28 Feb 2013 09:07:17 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Mikael Abrahamsson , "Ackermann, Michael" References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 28 Feb 2013 17:07:18 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 17:07:20 -0000 On 2/28/13 8:57 AM, Mikael Abrahamsson wrote: > On Thu, 28 Feb 2013, Ackermann, Michael wrote: > >> And not to mention 18 quintillion hosts, in each of those 256 subnets. > > When I introduce people to IPv6 I tell them to stop thinking in terms > of number of addresses and instead think of /64 per subnet. It's my > opinion that the 2^64 addresses per subnet is irrelevant. The upper bound number of L2 adjacencies/nexthops that most of these devices are capable of handling on a subnet are on the order of 10^3 to 10^5 so there are distinct scaling limits to subnet size that are consistent across v4/v6 and fact dual stack deployment dramatically reduces your capacity relative to one or the other. From brian.e.carpenter@gmail.com Thu Feb 28 09:10: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 28AAA21F85D8 for ; Thu, 28 Feb 2013 09:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.521 X-Spam-Level: X-Spam-Status: No, score=-99.521 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg8xx2G0EdIc for ; Thu, 28 Feb 2013 09:09:50 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 80AB121F856F for ; Thu, 28 Feb 2013 09:09:50 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so1743768wey.34 for ; Thu, 28 Feb 2013 09:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=srdc7v6ZF168yPsoiiPPxH+aMUHEOTtbJAuVyqVb4ME=; b=L/ME3L9WH4caTPH2ml0zVDNkVlw3JzD3ppDXQ7xg2hox/nkUsR8u891wHXlE61VMNX /EP8buDOKP2ooOP5ZhMhdY4K2A1Ths6t9P/uGfjx+n9Kz+ZipSgkfX7y2/DYv3ojcbwO EPvD66Nw3Rg/qaPlhDseQR5lovTy3kfRwvbOyCPXOiI+hkX+pdgCQZn8MKORLu929/ZW L03s7zm84I0zHwtYBPawk3Y9979quNNFgnWrmQYMH/prw8fRWtRucbn/pNTCRmF5yT8D nHbT8ZbQxeSkxVfYOUREKDSsicpI3meyrJxLTL83od4x8txA2ql+lTdtgFkscrE3La1H TrWA== X-Received: by 10.180.77.9 with SMTP id o9mr34722925wiw.16.1362071389727; Thu, 28 Feb 2013 09:09:49 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-166.as13285.net. [2.101.188.166]) by mx.google.com with ESMTPS id n2sm34585822wiy.6.2013.02.28.09.09.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:09:48 -0800 (PST) Message-ID: <512F8F66.7010409@gmail.com> Date: Thu, 28 Feb 2013 17:09:58 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 17:10:02 -0000 On 28/02/2013 16:57, Mikael Abrahamsson wrote: > On Thu, 28 Feb 2013, Ackermann, Michael wrote: > >> And not to mention 18 quintillion hosts, in each of those 256 subnets. > > When I introduce people to IPv6 I tell them to stop thinking in terms of > number of addresses and instead think of /64 per subnet. It's my opinion > that the 2^64 addresses per subnet is irrelevant. It's liberating. You can imagine things that were impossible before. Brian From mackermann@bcbsm.com Thu Feb 28 09:21: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 5224921F8628 for ; Thu, 28 Feb 2013 09:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMQlulImTZKA for ; Thu, 28 Feb 2013 09:21:46 -0800 (PST) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id AF71221F89C0 for ; Thu, 28 Feb 2013 09:21:46 -0800 (PST) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 9A09C17E567 for ; Thu, 28 Feb 2013 11:21:45 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id B956217E519; Thu, 28 Feb 2013 11:21:44 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 9CF924F8055; Thu, 28 Feb 2013 12:21:15 -0500 (EST) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 8EB764F804F; Thu, 28 Feb 2013 12:21:15 -0500 (EST) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Thu, 28 Feb 2013 12:21:43 -0500 From: "Ackermann, Michael" To: Mikael Abrahamsson Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOFTtLbXD86QK2vUyzAUxw618/bZiPslSA//+/yaCAAGCbgP//rWIQ Date: Thu, 28 Feb 2013 17:21:43 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A5FCBC5@PWN401EA160.ent.corp.bcbsm.com> References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 17:21:47 -0000 Thanks Mikael. Interesting=21 We are new and just now preparing to deploy IPv6. We are approaching the = subnet and host address relationship in a similar fashion to what we have = in V4. That is, that a subnet might be a floor, quadrant, or small = office, etc., and then some number of hosts within that subnet. V6 = just would give us much, much more of each and hence some more flexibility = if/where needed. =20 As such, the host addresses end up being the important and useable entity = to us. We can just have many more per interface, device, etc. and many = more devices (mobile, lowpan, etc.). Again, if needed. =20 Of course the architectural capability is there to have many more hosts = per subnet in v6, but I don't see that being exploited at all. (at least = by us). =20 So ultimately our focus is on the actual host addresses more so than the = associated subnets. Is that the wrong approach for IPv6 in your view? = Should it be more of each device having it's own subnet? =20 Thanks, Mike -----Original Message----- From: Mikael Abrahamsson =5Bmailto:swmike=40swm.pp.se=5D=20 Sent: Thursday, February 28, 2013 11:57 AM To: Ackermann, Michael Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D new draft: draft-shishio-v6ops-dpvt On Thu, 28 Feb 2013, Ackermann, Michael wrote: > And not to mention 18 quintillion hosts, in each of those 256 subnets. When I introduce people to IPv6 I tell them to stop thinking in terms of = number of addresses and instead think of /64 per subnet. It's my opinion = that the 2=5E64 addresses per subnet is irrelevant. --=20 Mikael Abrahamsson email: swmike=40swm.pp.se The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From swmike@swm.pp.se Thu Feb 28 09:44: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 CB97B21F867A for ; Thu, 28 Feb 2013 09:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElpLo0zRPhJD for ; Thu, 28 Feb 2013 09:44:49 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0116221F8C06 for ; Thu, 28 Feb 2013 09:44:45 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 252D89C; Thu, 28 Feb 2013 18:44:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 126799A; Thu, 28 Feb 2013 18:44:44 +0100 (CET) Date: Thu, 28 Feb 2013 18:44:44 +0100 (CET) From: Mikael Abrahamsson To: "Ackermann, Michael" In-Reply-To: <4FC37E442D05A748896589E468752CAA0A5FCBC5@PWN401EA160.ent.corp.bcbsm.com> Message-ID: References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0A5FCBC5@PWN401EA160.ent.corp.bcbsm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 17:44:49 -0000 On Thu, 28 Feb 2013, Ackermann, Michael wrote: > So ultimately our focus is on the actual host addresses more so than the > associated subnets. Is that the wrong approach for IPv6 in your view? > Should it be more of each device having it's own subnet? Keeping strict "one host per subnet" might be needed in some situations, but I'd say this is not the norm. It might make sense to have one subnet per customer or per service, or per cluster of servers or alike. The important thing is to not think that there can be 2^64 hosts per subnet, as explained Joel Jaeggli this just doesn't work. -- Mikael Abrahamsson email: swmike@swm.pp.se From jhw@apple.com Thu Feb 28 12:00: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 0662821F86BE for ; Thu, 28 Feb 2013 12:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.351 X-Spam-Level: X-Spam-Status: No, score=-105.351 tagged_above=-999 required=5 tests=[AWL=5.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDKTyjoKX0lE for ; Thu, 28 Feb 2013 12:00:06 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2F08721F87B9 for ; Thu, 28 Feb 2013 12:00:05 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) 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 <0MIY00IMN4VYFKB0@mail-out.apple.com> for v6ops@ietf.org; Thu, 28 Feb 2013 12:00:02 -0800 (PST) X-AuditID: 11807136-b7efc6d0000001b3-d3-512fc5502431 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 1B.87.00435.055CF215; Thu, 28 Feb 2013 13:00:00 -0800 (PST) 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 <0MIY00DXH4W1FE00@aniseed.apple.com> for v6ops@ietf.org; Thu, 28 Feb 2013 12:00:02 -0800 (PST) From: james woodyatt In-reply-to: <512F8F66.7010409@gmail.com> Date: Thu, 28 Feb 2013 12:00:00 -0800 Message-id: References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> <512F8F66.7010409@gmail.com> To: Brian Carpenter , v6ops@ietf.org X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FAsrhtwVD/Q4M0OPYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/20b+wFz1krpjZOYGlgvMzSxcjJISFgIjF/6jUoW0ziwr31 bF2MXBxCAlOYJNqmfGeHcGYwSbz/OY0dpIpZQEti/c7jTCA2r4CexLa524A6ODiEBSwk7i/P AAmzCahIfLt8F6yEU0BT4tvhHkYQm0VAVeLzrcmMEGO0JZ68u8AKMcZGovcnyEEguxYzSazp mgCWEBFwlGha9YUN4jpZidfP37BMYOSfheSMWUjOmIVk7gJG5lWMgkWpOYmVhqZ6iQUFOal6 yfm5mxjBQVZotoNxx1+5Q4wCHIxKPLyJHfqBQqyJZcWVuYcYJTiYlUR4/aYChXhTEiurUovy 44tKc1KLDzFKc7AoifNO3AaUEkhPLEnNTk0tSC2CyTJxcEo1MCaXp5TLuX/yMWVtqoiROT4p smn1+cr1aZ+N/77hK9n2buXWM/F2D7/Ithl9dr8uvMx567zpiUVBc+s9qn8uzmHtdSk/e3nO 00dmX2c8FM9O5vP8PtH49H0h09J+0yOnVf7ey+x/ezuiSvu9b+YtoXc6rYnF0jyxjUUG5hOP xt3a2RdoGHDxtRJLcUaioRZzUXEiADnKTgsuAgAA Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 20:00:07 -0000 On Feb 28, 2013, at 09:09 , Brian E Carpenter wrote: > > It's liberating. You can imagine things that were impossible before. Now imagine how liberating it would be if we still had consensus that one-/48-per-subscriber is a good idea. Yes, most subscribers won't actually have more than one, or a handful of subnets, at any given point in time, but having a sufficiently large space from which to pull random subnet identifiers so that collisions are statistically unlikely would have been a valuable technical feature of IPv6, if only we had managed to retain the strategic foresight to keep it. Oh well. Bygones. -- james woodyatt core os networking From owen@delong.com Thu Feb 28 12:16: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 7F7CA21F880F for ; Thu, 28 Feb 2013 12:16:01 -0800 (PST) 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.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5-spU1ohqDQ for ; Thu, 28 Feb 2013 12:16:00 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AA7BE21F8806 for ; Thu, 28 Feb 2013 12:16:00 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1SKEWtL002710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 12:14:33 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1SKEWtL002710 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362082473; bh=sDt61z17mS6BNLdfRKVhbtXdI7Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=H2IlDrfjT5Ndnt5kokEjJWxOpt8/eCiF/vHpofl9L/5XpgCqrsedUaW1U/Q/w6FNf H2J//sKH3+heilTftkCnuAMnk5lJ24E+SkWfQ5xCdlkIuBqcqGk5jO310Goe1RCCOZ X3hsIFHqOk/COUQ5zIVx6oPFVgIUtLHK6uclSR54= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <512F3FAC.7060905@gmail.com> Date: Thu, 28 Feb 2013 12:14:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> <512F3FAC.7060905@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 28 Feb 2013 12:14:33 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 20:16:01 -0000 On Feb 28, 2013, at 3:29 AM, Brian E Carpenter = wrote: > On 28/02/2013 09:23, Owen DeLong wrote: >> On Feb 28, 2013, at 00:50 , Brian E Carpenter = wrote: >=20 > ... >> What is the significant benefit to "without PI"? >=20 > Saving BGP4. Using a PI prefix is selfish as far as the > Internet is concerned, so we need to encourage alternatives. We can agree to disagree. We eventually need to come up with a scaleable = routing solution. In the meantime, if we do IPv6 right, we'll have a much smaller routing = table even with many thousands of new multi-homers using PI. >=20 >>=20 >> PI seems to be very nice as near as I can tell. It is working very >> well here. >>=20 >>>> Section 3.1 >>>>=20 >>>> The last sentence should be deleted. GUA is an equally viable >>>> option for these networks. >>> Only if you have an ISP, which by definition you don't. >>=20 >> ?? I know of a number of networks that are using GUA for those >> purposes without involving an ISP. Could you explain why you >> think that's not possible? >=20 > You need to get your prefix either from an ISP or from an LIR. > You don't need to talk to anyone, or pay anyone, to get your ULA > prefix. In fact, it can be generated automatically in a SOHO > scenario, so that the user doesn't have to know anything. >=20 Sure, there are tradeoffs either way. It's really pretty easy to get IPv6 space from an RIR, so I really don't see circumventing the RIR process as being a particularly significant benefit. Owen From owen@delong.com Thu Feb 28 12:21: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 2429021F8749 for ; Thu, 28 Feb 2013 12:21:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGGDsD6e6+IQ for ; Thu, 28 Feb 2013 12:20:59 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 237C721F871D for ; Thu, 28 Feb 2013 12:20:58 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1SKJeVq002932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 12:19:41 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1SKJeVq002932 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362082781; bh=bKYtxmk7OO7OBGKEwpday0vfH9k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=4QfYlsLrrqkOmNbO5mBGKpPQJI16XXwUQMJ4mF2iakbeSQ/bFX9m/PyjIRXHU6wPz RLLvj7kBNZKoC25XSDc1lxjczw9NGrE5xwRqJ0iqUwdhDuFPvq8/qg185hx6CzdBpG c0TrDpF4WYzt+UoPUKPO/u6v+pawSwf43YB22jEM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Thu, 28 Feb 2013 12:19:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 28 Feb 2013 12:19:41 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 20:21:06 -0000 > Speaking from an SP view, there are many functions which are served = well > by RFC1918 and with some loose association to ULAs (can be used for > equivalent function). >=20 Speaking as someone who has had many different roles at many different = SPs over the years, I've never found a need for RFC-1918 in the SP environment. > If a network admin uses ULAs for certain functions, it's a lot easier = to > filter/protect agains a well known contiguous range. However, other > security mechanisms need to be in place - basic filtering is a poor = single > form of security. Actually, not so much. It' a lot easier to filter/protect against a contiguous range. This is further easier if the range is well known within the filtering domain. There is no benefit to the range being well known outside of the filtering domain. A /48 carved out of one's GUA = would serve equally well to a /48 from ULA. If you really were concerned about ease of identification, it wouldn't be hard to get a non-contiguous /48 for that purpose. > One of the comments I had before on this draft was that the notion of = ULA > !=3D RFC1918 is an important distinction (hopefully that would get = network > administrators to re-think any loose security they may have around = RFC1918 > before applying it to ULAs if used). My concern is that I do not want to see IETF putting out documents that encourage the use of NPT or other hacks that were made necessary by IPv4 address shortage and are particularly disruptive in the IPv6 world with little or no benefit. Owen From owen@delong.com Thu Feb 28 13:00: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 21B4121F871D for ; Thu, 28 Feb 2013 13:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmleST736B-B for ; Thu, 28 Feb 2013 13:00:53 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8CE21F87AD for ; Thu, 28 Feb 2013 13:00:51 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1SKwDPA004599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 12:58:14 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1SKwDPA004599 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362085094; bh=nKXOhZu+3vSSdAjKyM0hrDZDLoA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=fAhHdhaTIDuUdMgwoFh+pD2oZVRuliyB7MbzoIrj2gSrOq5Uqtk5UWaCogyXkXPS+ F0nIh0FKKvv9tzj0jgXsLBgyOpV414Mz00t+hA+ExATG5yM5kq31X9+2covHnIceMl WVZuBOJlglxOq/q3Zwe1gFhnbPbtByoDLeUUi+gI= Content-Type: multipart/alternative; boundary="Apple-Mail=_4EF8D2AF-39CA-4AD4-A9B6-12280929B7D8" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> Date: Thu, 28 Feb 2013 12:58:13 -0800 Message-Id: <833ACBEE-DCCD-4558-9F06-F8D69FAB6057@delong.com> References: <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> To: Bill Jouris X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 28 Feb 2013 12:58:14 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 21:00:55 -0000 --Apple-Mail=_4EF8D2AF-39CA-4AD4-A9B6-12280929B7D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think it is very likely to become the norm. Giving out two allocations is exactly what we would prefer to avoid in = IPv6 because that puts unnecessary growth into the routing table. It's = far better to give everyone a /48 than to give a few (or eventually a = lot) of people more than 1 /56. Think of it this way: 10,000,000 households with /48s =3D=3D 10,000,000 routes. 10,000,000 households with /56s and 10% need two /56s and 5% need 3 is = 10,000,000+1,000,000+2(500,000) =3D 12,000,000 routes. Owen On Feb 28, 2013, at 7:01 AM, Bill Jouris = wrote: >=20 > It may be that, for some individuals, 256 subnets really is "very = small". But is that really anything like the norm? Or likely to become = the norm? >=20 > And for that minority who, like you, might be constrained, why = couldn't they simply get a second 256? It's not like we are looking at = mandating a restriction on giving anyone more than a single allocation. >=20 > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) >=20 >=20 >=20 > --- On Wed, 2/27/13, Mark Andrews wrote: >=20 > From: Mark Andrews > Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt > To: "Gert Doering" > Cc: v6ops@ietf.org > Date: Wednesday, February 27, 2013, 2:39 PM >=20 >=20 > In message <20130227181908.GE51699@Space.Net>, Gert Doering writes: > > Hi, > >=20 > > On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: > > > For example, at APNIC, based around 2^24 customers > > > a /32 costs AUD 1,994 =3D=3D > > > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&action=3DC= alculat > > e > > > and a /24 costs AUD 16,267 =3D=3D > > > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F24&action=3DC= alculat > > e > >=20 > > Ouch... >=20 > 3c/annum and 0.1c/annum per /48 respectively >=20 > > This is exactly the sort of incentive the RIRs should *not* give = (and > > we don't do that in RIPE land). >=20 > or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer > allocations. Both of those are less than the cost of getting the > ethernet address that the CPE vendor paid to the IEEE. >=20 > > OTOH, I don't have an issue with "/56s to residential customers", as = I'm=20 > > still waiting for someone to explain to me why 256 subnets in the = home=20 > > is "too small". /60 feels a bit too small, though. >=20 > Because it stiffles development. When you have a people wearing > a couple of subnets each it doesn't take long to use up 256 subnets. > Today I have family and friends come over and grab a address > wirelessly. It is not a long stretch to also have a prefix delegation > or two occur in the future at the same time. 256 is suddenly very > small. >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_4EF8D2AF-39CA-4AD4-A9B6-12280929B7D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = think it is very likely to become the norm.

Giving = out two allocations is exactly what we would prefer to avoid in IPv6 = because that puts unnecessary growth into the routing table. It's far = better to give everyone a /48 than to give a few (or eventually a lot) = of people more than 1 /56.

Think of it this = way:

10,000,000 households with /48s =3D=3D = 10,000,000 routes.
10,000,000 households with /56s and 10% = need two /56s and 5% need 3 is 10,000,000+1,000,000+2(500,000) =3D = 12,000,000 = routes.

Owen

On Feb 28, = 2013, at 7:01 AM, Bill Jouris <bill.jouris@insidethestack.= com> wrote:

It may be that, for some individuals, 256 subnets really is = "very small".  But is that really anything like the norm?  Or = likely to become the norm?

And for that minority who, like you, = might be constrained, why couldn't they simply get a second 256?  = It's not like we are looking at mandating a restriction on giving anyone = more than a single allocation.

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



--- On Wed, = 2/27/13, Mark Andrews <marka@isc.org> = wrote:

From: Mark Andrews <marka@isc.org>
Subject: Re: = [v6ops] new draft: draft-shishio-v6ops-dpvt
To: "Gert Doering" <gert@space.net>
Cc: v6ops@ietf.org
Date: Wednesday, = February 27, 2013, 2:39 PM


In = message <20= 130227181908.GE51699@Space.Net>, Gert Doering writes:
> = Hi,
>
> On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann = wrote:
> > For example, at APNIC, based around 2^24 = customers
> > a /32 costs AUD 1,994 =3D=3D
> > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&i= pv6=3D%2F32&action=3DCalculat
> e
> > and a /24 = costs AUD 16,267 =3D=3D
> > http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&i= pv6=3D%2F24&action=3DCalculat
> e
>
> = Ouch...

3c/annum and 0.1c/annum per /48 respectively

> = This is exactly the sort of incentive the RIRs should *not* give = (and
> we don't do that in RIPE land).

or .01c/annum/56 and = 0.1c/annum/48 assumuming you need 16M = customer
allocations.   Both of those are less than = the cost of getting the
ethernet address that the CPE vendor paid to = the IEEE.

> OTOH, I don't have an issue with "/56s to = residential customers", as I'm
> still waiting for someone to = explain to me why 256 subnets in the home
> is "too small".  = /60 feels a bit too small, though.

Because it stiffles = development.   When you have a people wearing
a couple = of subnets each it doesn't take long to use up 256 subnets.
Today I = have family and friends come over and grab a address
wirelessly.  It is not a long stretch to = also have a prefix delegation
or two occur in the future at the same = time.  256 is suddenly very
small.

Mark
--
Mark = Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, = Australia
PHONE: +61 2 9871 4742          =        INTERNET: marka@isc.org
= _______________________________________________
v6ops mailing = list
v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops
__________________________________= _____________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_4EF8D2AF-39CA-4AD4-A9B6-12280929B7D8-- From owen@delong.com Thu Feb 28 13:01: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 26A5321F89CE for ; Thu, 28 Feb 2013 13:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z44ZYCkMRu9 for ; Thu, 28 Feb 2013 13:01:22 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 342A321F884F for ; Thu, 28 Feb 2013 13:01:22 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1SKwDPB004599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 12:58:56 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1SKwDPB004599 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362085136; bh=CwalLFTVkUY7ld0t711S5a/dxck=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Fg+deTuwtbEO85vxA2FCD+O273kaYqQqipn9Z+nLc0nauVXORYAFA+fx/r7TbK+wr Uds7Mq8SnncGgRSblRCihxphu+AZBYdsZTsLkmIQFZQ5DjQ7NopIwyMx+tyqfkxDYs z5i5HI0XF+DjYz/5Fduq4eXKXKTCDfYroub2k7tc= Content-Type: multipart/alternative; boundary="Apple-Mail=_72653C35-DD11-4EA8-9855-363D20BAA633" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> Date: Thu, 28 Feb 2013 12:58:56 -0800 Message-Id: References: <20130227223926.05832302B138@drugs.dv.isc.org> <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A5FCB16@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 28 Feb 2013 12:58:56 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 21:01:23 -0000 --Apple-Mail=_72653C35-DD11-4EA8-9855-363D20BAA633 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Counting hosts at all is IPv4-think. It's about how many subnets you need, not how many hosts are on a = subnet. Owen On Feb 28, 2013, at 8:42 AM, "Ackermann, Michael" = wrote: > And not to mention 18 quintillion hosts, in each of those 256 subnets. = =20 > =20 > I hate to not be thinking =93Long term=94 or =93Out of the box=94, but = that is certainly not small by today=92s standards! =20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Bill Jouris > Sent: Thursday, February 28, 2013 10:01 AM > To: Mark Andrews > Cc: v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt > =20 > It may be that, for some individuals, 256 subnets really is "very = small". But is that really anything like the norm? Or likely to become = the norm? >=20 > And for that minority who, like you, might be constrained, why = couldn't they simply get a second 256? It's not like we are looking at = mandating a restriction on giving anyone more than a single allocation. >=20 > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) >=20 >=20 >=20 > --- On Wed, 2/27/13, Mark Andrews wrote: >=20 > From: Mark Andrews > Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt > To: "Gert Doering" > Cc: v6ops@ietf.org > Date: Wednesday, February 27, 2013, 2:39 PM >=20 >=20 > In message <20130227181908.GE51699@Space.Net>, Gert Doering writes: > > Hi, > >=20 > > On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: > > > For example, at APNIC, based around 2^24 customers > > > a /32 costs AUD 1,994 =3D=3D > > > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&action=3DC= alculat > > e > > > and a /24 costs AUD 16,267 =3D=3D > > > = http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F24&action=3DC= alculat > > e > >=20 > > Ouch... >=20 > 3c/annum and 0.1c/annum per /48 respectively >=20 > > This is exactly the sort of incentive the RIRs should *not* give = (and > > we don't do that in RIPE land). >=20 > or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer > allocations. Both of those are less than the cost of getting the > ethernet address that the CPE vendor paid to the IEEE. >=20 > > OTOH, I don't have an issue with "/56s to residential customers", as = I'm=20 > > still waiting for someone to explain to me why 256 subnets in the = home=20 > > is "too small". /60 feels a bit too small, though. >=20 > Because it stiffles development. When you have a people wearing > a couple of subnets each it doesn't take long to use up 256 subnets. > Today I have family and friends come over and grab a address > wirelessly. It is not a long stretch to also have a prefix delegation > or two occur in the future at the same time. 256 is suddenly very > small. >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_72653C35-DD11-4EA8-9855-363D20BAA633 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 MAckermann@bcbsm.com> = wrote:

And not to mention 18 = quintillion hosts, in each of those 256 = subnets.    
 
I hate to not be = thinking =93Long term=94 or =93Out of the box=94, but that is certainly = not small by today=92s = standards!  
 
 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Bill = Jouris
Sent: Thursday, February 28, 2013 = 10:01 AM
To: Mark = Andrews
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: = draft-shishio-v6ops-dpvt
 
It may be that, for some individuals, 256 = subnets really is "very small".  But is that really anything like = the norm?  Or likely to become the norm?

And for that = minority who, like you, might be constrained, why couldn't they simply = get a second 256?  It's not like we are looking at mandating a = restriction on giving anyone more than a single allocation.

Bill Jouris
Inside Products, Inc.
 Wed, 2/27/13, Mark = Andrews <marka@isc.org> wrote:


From: Mark Andrews <marka@isc.org>
Subject: Re: [v6ops] new draft: = draft-shishio-v6ops-dpvt
To: "Gert Doering" <gert@space.net>
Cc: v6ops@ietf.org
Date: Wednesday, February 27, 2013, = 2:39 PM


In message = < 
> = On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote:
> > = For example, at APNIC, based around 2^24 customers
> > a /32 = costs AUD 1,994 =3D=3D
> >   
> = Ouch...

3c/annum and 0.1c/annum per /48 respectively

> = This is exactly the sort of incentive the RIRs should *not* give = (and
> we don't do that in RIPE land).

or .01c/annum/56 and = 0.1c/annum/48 assumuming you need 16M = customer
allocations.   Both of those are less than = the cost of getting the
ethernet address that the CPE vendor paid to = the IEEE.

> OTOH, I don't have an issue with "/56s to = residential customers", as I'm 
> still waiting for = someone to explain to me why 256 subnets in the home 
> is "too = small".  /60 feels a bit too small, though.

Because it = stiffles development.   When you have a people = wearing
a couple of subnets each it doesn't take long to use up 256 = subnets.
Today I have family and friends come over and grab a = address
wirelessly.  It is not a long stretch to also have a = prefix delegation
or two occur in the future at the same time.  = 256 is suddenly very
small.

Mark
-- 
Mark Andrews, ISC
1 = Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 = 4742              =    INTERNET: v6ops@ietf.org
v6ops@ietf.org
Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 21:14:30 -0000 On 2013-02-28 3:19 PM, "Owen DeLong" wrote: >>Speaking from an SP view, there are many functions which are served well >>by RFC1918 and with some loose association to ULAs (can be used for >>equivalent function). > >Speaking as someone who has had many different roles at many different >SPs over >the years, I've never found a need for RFC-1918 in the SP environment. DOCSIS Modem addressing is served well by RFC1918. They are IP managed, but have no need to have outside world communication (in fact you don't want people getting to them). RFC1918 fit well and did not require such operators to go to the trough for global addresses for a function that had not global connectivity requirements. ULAs can play a similar role in this case given the devices have no global connectivity requirement and fit into existing rules which are put on the perimeter anyway. There is also an operational simplicity associated with having a distinctive range which can be looked after (filtered, policed and managed) by various groups. I understand this may not apply to all SPs, but I would suggest valid use cases do exist. I agree, however, that I don't want valid use cases of ULA usage to turn into a world where you see massive deployment of ULAs with NPT as the glue to the Internet for endpoints that require global connectivity. Regards, Victor K From bs7652@att.com Thu Feb 28 13:29:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9C521F8922 for ; Thu, 28 Feb 2013 13:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ9uGHi4QvB8 for ; Thu, 28 Feb 2013 13:29:01 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 16A6321F8A96 for ; Thu, 28 Feb 2013 13:29:01 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id d1ccf215.2aaaee843940.7108380.00-546.19650131.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 28 Feb 2013 21:29:01 +0000 (UTC) X-MXL-Hash: 512fcc1d218f4620-0f5f93e93bddcc752ece9e25042e1a476242368c Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 71ccf215.0.7108327.00-092.19649971.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 28 Feb 2013 21:28:57 +0000 (UTC) X-MXL-Hash: 512fcc19035e8f01-e3777982c642e5a35cfb67cc3e60685607fb5923 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1SLSsc2031858; Thu, 28 Feb 2013 16:28:55 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1SLSHDQ030803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 16:28:48 -0500 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint03.pst.cso.att.com (RSA Interceptor); Thu, 28 Feb 2013 16:27:39 -0500 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0328.009; Thu, 28 Feb 2013 16:27:39 -0500 From: "STARK, BARBARA H" To: Victor Kuarsingh , Owen DeLong Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOFfDvz+v6QaQtFEC18dpJdnQjhZiQGRuA//+tNdA= Date: Thu, 28 Feb 2013 21:27:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130257BB7@GAALPA1MSGUSR9L.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.170.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Z9Rb6gtA c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=xL7knIR9iIAA:10 a=hc5_WeQOMCwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=U6jYIu4fXZ8A:10 a=LVpBf-TeHlG4MrgBqhgA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 21:29:01 -0000 =20 > >>Speaking from an SP view, there are many functions which are served > >>well by RFC1918 and with some loose association to ULAs (can be used > >>for equivalent function). > > > >Speaking as someone who has had many different roles at many different > >SPs over the years, I've never found a need for RFC-1918 in the SP > >environment. >=20 > DOCSIS Modem addressing is served well by RFC1918. They are IP managed, > but have no need to have outside world communication (in fact you don't > want people getting to them). RFC1918 fit well and did not require such > operators to go to the trough for global addresses for a function that ha= d not > global connectivity requirements. >=20 > ULAs can play a similar role in this case given the devices have no globa= l > connectivity requirement and fit into existing rules which are put on the > perimeter anyway. >=20 > There is also an operational simplicity associated with having a distinct= ive > range which can be looked after (filtered, policed and > managed) by various groups. >=20 > I understand this may not apply to all SPs, but I would suggest valid use= cases > do exist. >=20 > I agree, however, that I don't want valid use cases of ULA usage to turn = into a > world where you see massive deployment of ULAs with NPT as the glue to > the Internet for endpoints that require global connectivity. I agree with Victor. I'm aware of SPs who include support for RFC1918 numbe= rs for LAN addressing in "Residential Gateways" that they ship to consumers= , as well as using RFC1918 addresses in closed management system networks. = In the case of the LAN, consumers seem to like for their home network to op= erate properly in the complete absence of WAN/Internet connectivity. The cl= osed management system networks are not intended to be connected to the Int= ernet, ever. Barbara From john_brzozowski@cable.comcast.com Thu Feb 28 13:54: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 DF4CC21F8B1D for ; Thu, 28 Feb 2013 13:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.335 X-Spam-Level: X-Spam-Status: No, score=-104.335 tagged_above=-999 required=5 tests=[AWL=0.896, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRrSP06XvqSV for ; Thu, 28 Feb 2013 13:54:06 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35821F8AD8 for ; Thu, 28 Feb 2013 13:54:06 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.58618272; Thu, 28 Feb 2013 14:23:24 -0700 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 28 Feb 2013 16:54:02 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Thu, 28 Feb 2013 16:54:01 -0500 From: "Brzozowski, John" To: Owen DeLong , Doug Barton Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOFFS//dzS9cbAc0ie1KTMDHbgxZiM1s0AgAAHDwCAAvW1AA== Date: Thu, 28 Feb 2013 21:54:00 +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.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <73409504A290C848BCA6BC88448C0590@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 21:54:07 -0000 > Comcast: "Covers buggy hardware/software" > I've already agreed that I accept this. However, that's /128s and /64s. >Not /60s and /56s vs. /48s. We support all of the above on this list depending on the type of service you have with the exception of /56s. Stay tuned for some news on this front soon, Comcast will then have this entire list covered. From john_brzozowski@cable.comcast.com Thu Feb 28 14:21: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 5101E21F84CD for ; Thu, 28 Feb 2013 14:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=-1.291, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2XdAvLRmaUX for ; Thu, 28 Feb 2013 14:21:09 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5067F21F84AD for ; Thu, 28 Feb 2013 14:21:09 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44962743; Thu, 28 Feb 2013 17:08:26 -0500 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 28 Feb 2013 17:21:03 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Thu, 28 Feb 2013 17:21:03 -0500 From: "Brzozowski, John" To: Owen DeLong , Bill Jouris Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOFfZS/dzS9cbAc0ie1KTMDHbgxZiP19kA Date: Thu, 28 Feb 2013 22:21:02 +0000 Message-ID: In-Reply-To: <833ACBEE-DCCD-4558-9F06-F8D69FAB6057@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A60BBD0B3F0B146963F338C44A89DDF@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Feb 2013 22:21:11 -0000 In general I agree that is not desirable to delegate multiple prefixes for typical Internet access. However, operators may choose to delegated more than one prefix and if this were to be the case it does not necessarily mean that the routing table will grow for everyone, it may impact the specific provider. I never agreed with a /48 for everyone is better and I still do not. Different strokes for different folks, one size does not fit all here. 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) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =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 -----Original Message----- From: Owen DeLong Date: Thursday, February 28, 2013 12:58 PM To: Bill Jouris Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt > > > >I think it is very likely to become the norm. > > >Giving out two allocations is exactly what we would prefer to avoid in >IPv6 because that puts unnecessary growth into the routing table. It's >far better to give everyone a /48 than to give a few (or eventually a >lot) of people more than 1 /56. > > >Think of it this way: > > >10,000,000 households with /48s =3D=3D 10,000,000 routes. >10,000,000 households with /56s and 10% need two /56s and 5% need 3 is >10,000,000+1,000,000+2(500,000) =3D 12,000,000 routes. > > >Owen > >On Feb 28, 2013, at 7:01 AM, Bill Jouris >wrote: > > >It may be that, for some individuals, 256 subnets really is "very small". > But is that really anything like the norm? Or likely to become the norm? > >And for that minority who, like you, might be constrained, why couldn't >they simply get a second 256? It's not like we are looking at mandating >a restriction on giving anyone more than a single allocation. > >Bill Jouris >Inside Products, Inc. >www.insidethestack.com >831-659-8360 >925-855-9512 (direct) > > > >--- On Wed, 2/27/13, Mark Andrews wrote: > > >From: Mark Andrews >Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >To: "Gert Doering" >Cc: v6ops@ietf.org >Date: Wednesday, February 27, 2013, 2:39 PM > > >In message <20130227181908.GE51699@Space.Net >>, Gert >Doering writes: >> Hi, >>=20 >> On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: >> > For example, at APNIC, based around 2^24 customers >> > a /32 costs AUD 1,994 =3D=3D >> >=20 >http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F32&action=3DC= alcula >t=20 >at> >> e >> > and a /24 costs AUD 16,267 =3D=3D >> >=20 >http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=3D&ipv6=3D%2F24&action=3DC= alcula >t=20 >at> >> e >>=20 >> Ouch... > >3c/annum and 0.1c/annum per /48 respectively > >> This is exactly the sort of incentive the RIRs should *not* give (and >> we don't do that in RIPE land). > >or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer >allocations. Both of those are less than the cost of getting the >ethernet address that the CPE vendor paid to the IEEE. > >> OTOH, I don't have an issue with "/56s to residential customers", as >>I'm=20 >> still waiting for someone to explain to me why 256 subnets in the home >> is "too small". /60 feels a bit too small, though. > >Because it stiffles development. When you have a people wearing >a couple of subnets each it doesn't take long to use up 256 subnets. >Today I have family and friends come over and grab a address >wirelessly. It is not a long stretch to also have a prefix delegation >or two occur in the future at the same time. 256 is suddenly very >small. > >Mark >--=20 >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: >marka@isc.org >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > > > > > From joelja@bogus.com Thu Feb 28 16:21:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A50C21F89AF for ; Thu, 28 Feb 2013 16:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O7NHTi4UPGI for ; Thu, 28 Feb 2013 16:21:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7C21F8976 for ; Thu, 28 Feb 2013 16:21:39 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r210LbHa058672 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 1 Mar 2013 00:21:37 GMT (envelope-from joelja@bogus.com) Message-ID: <512FF49E.9080306@bogus.com> Date: Thu, 28 Feb 2013 16:21:50 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Owen DeLong , Bill Jouris References: <1362063689.27342.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <833ACBEE-DCCD-4558-9F06-F8D69FAB6057@delong.com> In-Reply-To: <833ACBEE-DCCD-4558-9F06-F8D69FAB6057@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 01 Mar 2013 00:21:37 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 00:21:40 -0000 On 2/28/13 12:58 PM, Owen DeLong wrote: > I think it is very likely to become the norm. > > Giving out two allocations is exactly what we would prefer to avoid in > IPv6 because that puts unnecessary growth into the routing table. It's > far better to give everyone a /48 than to give a few (or eventually a > lot) of people more than 1 /56. > > Think of it this way: > > 10,000,000 households with /48s == 10,000,000 routes. > 10,000,000 households with /56s and 10% need two /56s and 5% need 3 is > 10,000,000+1,000,000+2(500,000) = 12,000,000 routes. sticking with the residential case, If for 10,000,000 customers I have pops (or aggregation devices) with 10,000 households aggregated behind them then, I have 1000 pop routes in the backbone and 10-12,000 customer routes in a pop or aggregation device. being generous to allow for growth it could be double that and it's still not really a big deal on the sort of hardware that can do dhcp-pd for 10,000 cutomers today. > > Owen > > On Feb 28, 2013, at 7:01 AM, Bill Jouris > > wrote: > >> It may be that, for some individuals, 256 subnets really is "very >> small". But is that really anything like the norm? Or likely to >> become the norm? >> >> And for that minority who, like you, might be constrained, why >> couldn't they simply get a second 256? It's not like we are looking >> at mandating a restriction on giving anyone more than a single >> allocation. >> >> Bill Jouris >> Inside Products, Inc. >> www.insidethestack.com >> 831-659-8360 >> 925-855-9512 (direct) >> >> >> >> --- On *Wed, 2/27/13, Mark Andrews /> >/* wrote: >> >> >> From: Mark Andrews > >> Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt >> To: "Gert Doering" > >> Cc: v6ops@ietf.org >> Date: Wednesday, February 27, 2013, 2:39 PM >> >> >> In message <20130227181908.GE51699@Space.Net >> >, >> Gert Doering writes: >> > Hi, >> > >> > On Wed, Feb 27, 2013 at 10:42:03AM +1100, John Mann wrote: >> > > For example, at APNIC, based around 2^24 customers >> > > a /32 costs AUD 1,994 == >> > > >> http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F32&action=Calculat >> > e >> > > and a /24 costs AUD 16,267 == >> > > >> http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F24&action=Calculat >> > e >> > >> > Ouch... >> >> 3c/annum and 0.1c/annum per /48 respectively >> >> > This is exactly the sort of incentive the RIRs should *not* >> give (and >> > we don't do that in RIPE land). >> >> or .01c/annum/56 and 0.1c/annum/48 assumuming you need 16M customer >> allocations. Both of those are less than the cost of getting the >> ethernet address that the CPE vendor paid to the IEEE. >> >> > OTOH, I don't have an issue with "/56s to residential >> customers", as I'm >> > still waiting for someone to explain to me why 256 subnets in >> the home >> > is "too small". /60 feels a bit too small, though. >> >> Because it stiffles development. When you have a people wearing >> a couple of subnets each it doesn't take long to use up 256 subnets. >> Today I have family and friends come over and grab a address >> wirelessly. It is not a long stretch to also have a prefix >> delegation >> or two occur in the future at the same time. 256 is suddenly very >> small. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> 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 owen@delong.com Thu Feb 28 16:31: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 9844121F871D for ; Thu, 28 Feb 2013 16:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=2.084, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QNGokPWOr1P for ; Thu, 28 Feb 2013 16:31:30 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D0AC821F857C for ; Thu, 28 Feb 2013 16:31:29 -0800 (PST) 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 r210Sp0A011552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 16:28:52 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r210Sp0A011552 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362097732; bh=H4WG7M4jhaKCj4+MhoL94pPbXL0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vBbhdpHm0u1TcrgjX5kTWSCPDKOZxIJ6JKdqmais+UJfEijqThDZ2T6RBCcruxTUH t3dmlHc/8Tyv4BSSUKq3DMtn+c2xPUQBC7RBEGK0Y9FmU9aXH03C8+Gd/IYSpY/dw1 V1/8OTiYSpr/lBs3VePKJGcsKlrsDvcY/pAIGQoI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Thu, 28 Feb 2013 16:28:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4DEDB0D5-E17B-49F3-A1FA-43F2A2ECB537@delong.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 28 Feb 2013 16:28:52 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 00:31:31 -0000 On Feb 28, 2013, at 13:14 , Victor Kuarsingh = wrote: >=20 >=20 > On 2013-02-28 3:19 PM, "Owen DeLong" wrote: >=20 >>> Speaking from an SP view, there are many functions which are served = well >>> by RFC1918 and with some loose association to ULAs (can be used for >>> equivalent function). >>=20 >> Speaking as someone who has had many different roles at many = different >> SPs over >> the years, I've never found a need for RFC-1918 in the SP = environment. >=20 > DOCSIS Modem addressing is served well by RFC1918. They are IP = managed, > but have no need to have outside world communication (in fact you = don't > want people getting to them). RFC1918 fit well and did not require = such > operators to go to the trough for global addresses for a function that = had > not global connectivity requirements. >=20 Comcast disagrees with you... RFC-1918 was far too small. Admittedly, ULA doesn't have that problem, but, neither would a /48 or = /32 or whatever set aside from GUA for that purpose. > ULAs can play a similar role in this case given the devices have no = global > connectivity requirement and fit into existing rules which are put on = the > perimeter anyway. They don't fit into existing rules, they need new rules. ULA does not = match 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an = additional rule for fc00::/7. > There is also an operational simplicity associated with having a > distinctive range which can be looked after (filtered, policed and > managed) by various groups. Yes. I've already agreed with this. My point is that it is irrelevant = whether that distinctive range is fc00::/7 or some fraction of GUA space assigned = uniquely to the organization. > I understand this may not apply to all SPs, but I would suggest valid = use > cases do exist.=20 I would suggest use cases exist. Validity is a loaded term on which we = are unlikely to agree. I did not, however, say that the use cases were = invalid. I merely said they could be served equally well (or better) by GUA. > I agree, however, that I don't want valid use cases of ULA usage to = turn > into a world where you see massive deployment of ULAs with NPT as the = glue > to the Internet for endpoints that require global connectivity. Right. Any draft advocating ULA usage MUST, IMHO, include something to this = effect. If it's in the current draft, I missed it. Owen From joelja@bogus.com Thu Feb 28 16:40: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 E077B21F84F0 for ; Thu, 28 Feb 2013 16:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-5GvirlOnEy for ; Thu, 28 Feb 2013 16:40:12 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC5421F84D5 for ; Thu, 28 Feb 2013 16:40:12 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r210e8Ml058860 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 1 Mar 2013 00:40:09 GMT (envelope-from joelja@bogus.com) Message-ID: <512FF8F6.1080204@bogus.com> Date: Thu, 28 Feb 2013 16:40:22 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Owen DeLong , Brian E Carpenter References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> <512F3FAC.7060905@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 01 Mar 2013 00:40:09 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 00:40:13 -0000 On 2/28/13 12:14 PM, Owen DeLong wrote: > On Feb 28, 2013, at 3:29 AM, Brian E Carpenter wrote: > >> On 28/02/2013 09:23, Owen DeLong wrote: >>> On Feb 28, 2013, at 00:50 , Brian E Carpenter wrote: >> ... >>> What is the significant benefit to "without PI"? >> Saving BGP4. Using a PI prefix is selfish as far as the >> Internet is concerned, so we need to encourage alternatives. Strictly speaking PI holders are not the obnoxious polluters in the routing system to today. there are ~43K AS in my internet today. somewhat less then half of them announce only one route yet there are 445K routes in my ipv4 table. Is is plausble to assert that there a potentially a lot more multihomers out there then there are ISPs. but when you have something like AS FOO that announces ~3k routes that could be maximally aggregated as 9 routes well there you are, why is bgp4 being destroyed again? >> We can agree to disagree. We eventually need to come up with a scaleable routing solution. >> >> In the meantime, if we do IPv6 right, we'll have a much smaller routing table even with >> many thousands of new multi-homers using PI. >> >>> PI seems to be very nice as near as I can tell. It is working very >>> well here. >>> >>>>> Section 3.1 >>>>> >>>>> The last sentence should be deleted. GUA is an equally viable >>>>> option for these networks. >>>> Only if you have an ISP, which by definition you don't. >>> ?? I know of a number of networks that are using GUA for those >>> purposes without involving an ISP. Could you explain why you >>> think that's not possible? >> You need to get your prefix either from an ISP or from an LIR. >> You don't need to talk to anyone, or pay anyone, to get your ULA >> prefix. In fact, it can be generated automatically in a SOHO >> scenario, so that the user doesn't have to know anything. >> > Sure, there are tradeoffs either way. It's really pretty easy to get > IPv6 space from an RIR, so I really don't see circumventing the RIR > process as being a particularly significant benefit. > > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From victor.kuarsingh@gmail.com Thu Feb 28 18:33: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 5AD7321F880F for ; Thu, 28 Feb 2013 18:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U0bQFM5GzK2 for ; Thu, 28 Feb 2013 18:33:51 -0800 (PST) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2921F8809 for ; Thu, 28 Feb 2013 18:33:51 -0800 (PST) Received: by mail-ia0-f179.google.com with SMTP id x24so2216611iak.10 for ; Thu, 28 Feb 2013 18:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=7Znpl8tQmW6XPrWerhDoMkQSZ1IDf09tNayyzBjTe14=; b=HofOkpKSl+cHUS+yJH/BrN8VP4Q60tvUJey4+HBP+Yx/N7KhUMMe+dlcsaCiSWHrOM QvZY4kTMup5RjiiaDbALkkTYYxMZDnRbE5X7yBJtwuQ148KONdnlExoZ6haaOCjgos46 DEinuFAVrUHSjvtmRm9aX6Qbf32uMgBCeInyO/rCfcz6Opg64DiCTPi47Q9aLfPwBYHk DevP6ji4U2ZQkNgx3D8gdqvaAWg6IBHQblWfbqblX7terkpubQw0+5UDn7TaK7AaLgKP DPQ8zgo8kfVKanftTk0elzZitQ3nNMFaE4lLKZTtDw+kZM9lWWqtrgg34a2MrWqP2dnQ UIYw== X-Received: by 10.50.187.225 with SMTP id fv1mr5533205igc.74.1362105231366; Thu, 28 Feb 2013 18:33:51 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id ih1sm12023295igc.3.2013.02.28.18.33.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Feb 2013 18:33:50 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 28 Feb 2013 21:33:46 -0500 From: Victor Kuarsingh To: Owen DeLong Message-ID: Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review In-Reply-To: <4DEDB0D5-E17B-49F3-A1FA-43F2A2ECB537@delong.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 02:33:52 -0000 On 2013-02-28 7:28 PM, "Owen DeLong" wrote: > >On Feb 28, 2013, at 13:14 , Victor Kuarsingh >wrote: > >> >> >> On 2013-02-28 3:19 PM, "Owen DeLong" wrote: >> >>>> Speaking from an SP view, there are many functions which are served >>>>well >>>> by RFC1918 and with some loose association to ULAs (can be used for >>>> equivalent function). >>> >>> Speaking as someone who has had many different roles at many different >>> SPs over >>> the years, I've never found a need for RFC-1918 in the SP environment. >> >> DOCSIS Modem addressing is served well by RFC1918. They are IP managed, >> but have no need to have outside world communication (in fact you don't >> want people getting to them). RFC1918 fit well and did not require such >> operators to go to the trough for global addresses for a function that >>had >> not global connectivity requirements. >> > >Comcast disagrees with you... RFC-1918 was far too small. I don't think they disagree, they just ran out of RFC1918 due to number of modems. I don't think that invalidates the use of it for this purpose. Even if some very large operators ran out of RFC1918 and had to supplement with globals, the majority of DOCSIS operators were good with RFC1918 and did not stress the global pools needlessly (in IPv4 land). > >Admittedly, ULA doesn't have that problem, but, neither would a /48 or >/32 or >whatever set aside from GUA for that purpose. > >> ULAs can play a similar role in this case given the devices have no >>global >> connectivity requirement and fit into existing rules which are put on >>the >> perimeter anyway. > >They don't fit into existing rules, they need new rules. ULA does not >match >10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an additional >rule for fc00::/7. I think (opinion alert) most operators will put in rules for ULAs on the perimeter similar to RFC1918. So if those rules are in place anyway, then it works quite well. I suspect I have no need to accept ULA routes or traffic from outside the AS, so those rules will be in. Exceptions (if any) can be managed as exceptions. > My point is that it is irrelevant whether that >distinctive range is fc00::/7 or some fraction of GUA space assigned >uniquely >to the organization. True. But if you are putting in rules for ULAs anyway, then it's simpler then adding more space and rules (I guess this will be an operator by operator evaluation). Also fc00::/7 is massive, so one can carve out many ::/48 as needed over time and still fit into a clean rule. Carving out ::/48s from GUA space may get messy if it's not contiguous. Not that it's impossible to manage dis-contiguous block ranges, but the cleaner the rules, the easier it is to maintain. I am not suggesting one architect based on simplicity, but if there is no good reason not to use it.. then I default to simple. But I do agree with the notion that text needs to be present to make sure the end reader understands the potential issues with using ULA space (if we are going to give people rope, let's help them not tie a noose). Victor K > From owen@delong.com Thu Feb 28 19: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 03FB621F884F for ; Thu, 28 Feb 2013 19:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTT4VvAS83e8 for ; Thu, 28 Feb 2013 19:31:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 39D6D21F8802 for ; Thu, 28 Feb 2013 19:31:05 -0800 (PST) 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 r213RZqZ015849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 19:27:35 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r213RZqZ015849 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362108455; bh=nUXesCKtO/aKMM9niLEeK9EREHw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vsRTTw24ZHFjinvdAlx+woWHS9ygujLpTnLD/H5Fg/MR19a71HbAHL7Dzxnt+UBvH JWmLSKUwFCccxu3VAfa1aVe/nHlfRVDPtZr5EGLyLtHrL61aQj1Injsq1P9U1mGVdV d01eV/txgzUSZUFNI5pd5W4yzpPK7E1/nw16lDL8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Thu, 28 Feb 2013 19:27:24 -0800 Content-Transfer-Encoding: 7bit Message-Id: <4FCC0BC3-9B99-482B-AED2-F358B7A07338@delong.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 28 Feb 2013 19:27:35 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 03:31:07 -0000 >> Admittedly, ULA doesn't have that problem, but, neither would a /48 or >> /32 or >> whatever set aside from GUA for that purpose. >> >>> ULAs can play a similar role in this case given the devices have no >>> global >>> connectivity requirement and fit into existing rules which are put on >>> the >>> perimeter anyway. >> >> They don't fit into existing rules, they need new rules. ULA does not >> match >> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an additional >> rule for fc00::/7. > > I think (opinion alert) most operators will put in rules for ULAs on the > perimeter similar to RFC1918. So if those rules are in place anyway, then > it works quite well. I suspect I have no need to accept ULA routes or > traffic from outside the AS, so those rules will be in. Exceptions (if > any) can be managed as exceptions. I think that will be true until customer A and customer B want to talk to each other's ULAs over provider C and then those rules will get an exception added. And then E and F will come along. Pretty soon, the ULA rules end up looking like swiss cheese. >> My point is that it is irrelevant whether that >> distinctive range is fc00::/7 or some fraction of GUA space assigned >> uniquely >> to the organization. > > True. But if you are putting in rules for ULAs anyway, then it's simpler > then adding more space and rules (I guess this will be an operator by > operator evaluation). Also fc00::/7 is massive, so one can carve out many > ::/48 as needed over time and still fit into a clean rule. Carving out > ::/48s from GUA space may get messy if it's not contiguous. Not that it's > impossible to manage dis-contiguous block ranges, but the cleaner the > rules, the easier it is to maintain. I am not suggesting one architect > based on simplicity, but if there is no good reason not to use it.. then I > default to simple. Big if. See above. ULA rules are going to become complicated and error prone in the future, IMHO. Integrating your internal security into that customer quagmire seems ill advised at best to me. > But I do agree with the notion that text needs to be present to make sure > the end reader understands the potential issues with using ULA space (if > we are going to give people rope, let's help them not tie a noose). At least we agree on this. Owen From marka@isc.org Thu Feb 28 19:59: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 EE28221F8952 for ; Thu, 28 Feb 2013 19:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3za-k-+DvKgf for ; Thu, 28 Feb 2013 19:59:22 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id F3D3021F891C for ; Thu, 28 Feb 2013 19:59:21 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 686D85F9863; Fri, 1 Mar 2013 03:59:11 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362110361; bh=RIaZPsRFef3N7TdiaHyOivOQJWFdeYpJ9IeDuC0pVgc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Kw6ROAom/tnAM/54iropiShtv8DmYPAhJeopvFp30iWzhCiT6eBvXYPlJw9/0KTZs 5LsmWEcAVMQguEk7PAQ+vrEOOBSAeB4VCB0Cp4mT6qmjpUYLbOop2oun5UVQTevkoI PqbVjrgL5z0Hl8ezK7lWJxPh1EHft/Xpu/0B/IRg= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 69D92216C43; Fri, 1 Mar 2013 03:59:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 84CCA3041E5D; Fri, 1 Mar 2013 14:59:01 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <4FCC0BC3-9B99-482B-AED2-F358B7A07338@delong.com> In-reply-to: Your message of "Thu, 28 Feb 2013 19:27:24 -0800." <4FCC0BC3-9B99-482B-AED2-F358B7A07338@delong.com> Date: Fri, 01 Mar 2013 14:59:01 +1100 Message-Id: <20130301035901.84CCA3041E5D@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 03:59:23 -0000 In message <4FCC0BC3-9B99-482B-AED2-F358B7A07338@delong.com>, Owen DeLong write s: > >> Admittedly, ULA doesn't have that problem, but, neither would a /48 or > >> /32 or > >> whatever set aside from GUA for that purpose. > >> > >>> ULAs can play a similar role in this case given the devices have no > >>> global > >>> connectivity requirement and fit into existing rules which are put on > >>> the > >>> perimeter anyway. > >> > >> They don't fit into existing rules, they need new rules. ULA does not > >> match > >> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an additional > >> rule for fc00::/7. > > > > I think (opinion alert) most operators will put in rules for ULAs on the > > perimeter similar to RFC1918. So if those rules are in place anyway, then > > it works quite well. I suspect I have no need to accept ULA routes or > > traffic from outside the AS, so those rules will be in. Exceptions (if > > any) can be managed as exceptions. > > I think that will be true until customer A and customer B want to talk to > each other's ULAs over provider C and then those rules will get an > exception added. And then E and F will come along. Pretty soon, the > ULA rules end up looking like swiss cheese. In which case customer A and customer B create a VPN using PA/PI addresses. The ISP doesn't need to be, nor should it be, involved. Or better still they use PA/PI addresses to talk to each other. ULA are a adjuct to PA/PI not a alternative. > >> My point is that it is irrelevant whether that > >> distinctive range is fc00::/7 or some fraction of GUA space assigned > >> uniquely > >> to the organization. > > > > True. But if you are putting in rules for ULAs anyway, then it's simpler > > then adding more space and rules (I guess this will be an operator by > > operator evaluation). Also fc00::/7 is massive, so one can carve out many > > ::/48 as needed over time and still fit into a clean rule. Carving out > > ::/48s from GUA space may get messy if it's not contiguous. Not that it's > > impossible to manage dis-contiguous block ranges, but the cleaner the > > rules, the easier it is to maintain. I am not suggesting one architect > > based on simplicity, but if there is no good reason not to use it.. then I > > default to simple. > > Big if. See above. ULA rules are going to become complicated and > error prone in the future, IMHO. > > Integrating your internal security into that customer quagmire seems > ill advised at best to me. > > > But I do agree with the notion that text needs to be present to make sure > > the end reader understands the potential issues with using ULA space (if > > we are going to give people rope, let's help them not tie a noose). > > At least we agree on this. > > 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 owen@delong.com Thu Feb 28 21:55: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 4A65721F8A09 for ; Thu, 28 Feb 2013 21:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3XpUTs+33Bd for ; Thu, 28 Feb 2013 21:55:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B167B21F89E1 for ; Thu, 28 Feb 2013 21:55:55 -0800 (PST) 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 r215peT6019171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 21:51:40 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r215peT6019171 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362117101; bh=Sx6LpkJoW2iMEgiDjwOTtHQNapI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hHsHxk8eAKMCb9IMORSWPf21myAXK5DqLMSU7MEWbYZtoHd1c0DwWOpMjgYDJ07AY Sm8Q63Os0jLU74aQB82nhHeLn2B2hRJEDY0vmnv82peY3E21igt7anffO+vpgGsoor J+KmdGRwawjzYePRfRr/UDDYVLyeN6pHE6/lkPZw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130301035901.84CCA3041E5D@drugs.dv.isc.org> Date: Thu, 28 Feb 2013 21:51:25 -0800 Content-Transfer-Encoding: 7bit Message-Id: <48CE82D9-32E4-44E0-BC72-8CC91F71F6AF@delong.com> References: <4FCC0BC3-9B99-482B-AED2-F358B7A07338@delong.com> <20130301035901.84CCA3041E5D@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 28 Feb 2013 21:51:41 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 05:55:57 -0000 >> >> I think that will be true until customer A and customer B want to talk to >> each other's ULAs over provider C and then those rules will get an >> exception added. And then E and F will come along. Pretty soon, the >> ULA rules end up looking like swiss cheese. > > In which case customer A and customer B create a VPN using PA/PI > addresses. The ISP doesn't need to be, nor should it be, involved. > Or better still they use PA/PI addresses to talk to each other. > ULA are a adjuct to PA/PI not a alternative. > I certainly hope so. Let's see how it plays out in the real world. Owen From arturo.servin@gmail.com Thu Feb 28 23:02: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 5D26721F88B0 for ; Thu, 28 Feb 2013 23:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfRjHhPLFmjY for ; Thu, 28 Feb 2013 23:02:27 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id C031D21F8771 for ; Thu, 28 Feb 2013 23:02:27 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so1635424pad.27 for ; Thu, 28 Feb 2013 23:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=alN9nThuHVYBKN4sQVMfQXVHp1g6j5U9dzeqvsl2/qA=; b=uDeJHJ+ZtkZ992PsS7wNyvs+kL6TLOx956+wjO7TnzLGWuyRRHxSHE7DPab4N02tLK R5oHqLuCL/rMAKWH2klzYyjH8he5tCIX1lFoO4iTppY/1tPrQ2NfpNV8Yb5D+qAfZGQQ 7NzxVv/5XnGSvoKDXWruRBmfex3vbmkMS56rH6rZShr0BjV3G3XCobT51ytItUJB6YLQ Dm5cuClh5Y0jWvXavehzToJrk5G6sdbqBSmdHNKR9hT30jk5npZWFRNpStseIqwoXIHg ONWWVYN1ptklMJeFRMOsYa8s05ADLHCHQmxhrv+atpiOK/SlUQVBG5Vqg9VYceINvvx1 W+LA== X-Received: by 10.66.157.100 with SMTP id wl4mr17713041pab.84.1362121347575; Thu, 28 Feb 2013 23:02:27 -0800 (PST) Received: from 189.150.dhcp.conference.apricot.net ([220.247.150.189]) by mx.google.com with ESMTPS id a10sm11066034pbq.29.2013.02.28.23.02.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 23:02:26 -0800 (PST) Message-ID: <5130527D.6030009@gmail.com> Date: Fri, 01 Mar 2013 15:02:21 +0800 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <201302191345.r1JDj1k06943@ftpeng-update.cisco.com> In-Reply-To: <201302191345.r1JDj1k06943@ftpeng-update.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 01 Mar 2013 07:02:28 -0000 Dear authors, I read your draft and I think that the content is covered by the combination of RFC6177, RFC5375, RFC6164 and draft-ietf-v6ops-design-choices. So I am not sure what is the new thing in this draft. Cheers, as On 19/02/2013 21:45, 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 and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From leo.liubing@huawei.com Thu Feb 28 23:57: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 3FE0321F8618 for ; Thu, 28 Feb 2013 23:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZXI+nH0I4lV for ; Thu, 28 Feb 2013 23:57:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3987D21F8611 for ; Thu, 28 Feb 2013 23:57:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQF12317; Fri, 01 Mar 2013 07:57:04 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Mar 2013 07:57:01 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Mar 2013 07:57:00 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 1 Mar 2013 15:56:54 +0800 From: "Liubing (Leo)" To: Owen DeLong , Brian E Carpenter Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiKC3OAgAPxl4CAAl7zoA== Date: Fri, 1 Mar 2013 07:56:53 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> In-Reply-To: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Mar 2013 07:57:07 -0000 Hi, Owen Thanks for your detailed review, it would help to improve the draft a lot. Please see replies inline. > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Thursday, February 28, 2013 9:43 AM > To: Victor Kuarsingh > Cc: Liubing (Leo); v6ops@ietf.org > Subject: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 > Sorry for the delay... Just now getting to this. >=20 > Section 1. >=20 > Paragraph 1 >=20 > "...normally they are not used on the publicly routable..." >=20 > Suggest should be changed to "...they should not be used on the publicly > routable..." [Bing] Ok, will do. >=20 > Paragraph 3 >=20 > "...networks has been confused for network operators." >=20 > Suggest should be changed to "...networks has been confusing to network > operators." [Bing] Ok >=20 > Paragraph 3 >=20 > "...while network operators run their entire networks on ULA.." > Can you cite some examples of this? I can't imagine a functional network > running entirely on ULA unless it is a completely disconnected network. [Bing] In some environments (e.g. information security sensitive enterprise= or government), the endpoints are default disconnected to the Internet, an= d need the proxies to connect. In IPv4, RFC1918+proxies is an effective pra= ctice for this purpose, and it is natural to pick ULA in IPv6. In last tim= e discussion someone just feedback they were using ULA-only+Proxy in their = lab networks. However, this was not an official production operating. I can= delete the sentence here or add some description in the scenarios section.= =20 > Section 2.1.2 >=20 > Paragraph 1 >=20 > "ULA is intended to be globally unique to avoid collision" >=20 > Suggest should be changed to "ULA is intended to have a low probability o= f > collision, but uniqueness is not guaranteed." [Bing] I'll refer RFC4193 for more accurate description. > Also paragraph 1 >=20 > "...Overlapping is cited as a deficiency with how [RFC1918] addresses wer= e > deployed, and ULA was designed to overcome this deficiency." >=20 > This is somewhat revisionist history IMHO. The whole point of RFC-1918 wa= s > to provide overlapping addresses for non-connected and NAT-based > networks to allow IPv4 address conservation. Prior to the need for addres= s > conservation and re-use in IPv4, no one saw any need for anything like > RFC-1918 or ULA. Indeed, I still, even after reading this draft don't see= a use > case for ULA that would not be served equally well (if not better) by GUA= . >=20 [Bing] I also agree Brian's comment: "I think that the disconnected-network= and homenet scenarios need to be further explored in this draft." Will do = in the next version. Thanks. > Section 2.1.3 >=20 > Paragraph 2 >=20 > "On the other hand, many organizations have security policies and > architectures based around the local-only routing of [RFC1918] addresses > and those policies may directly map to ULA." >=20 > Any security policy which depends on the semantics of [RFC1918] is flawed= . > Routing leaks of [RFC1918] space are commonplace and there are many > "crafted packet" attacks perfectly capable of delivering datagrams to > [RFC1918] based networks. Any pretense that [RFC1918] is a security > mechanism is fictional and should not be codified in an RFC, IMHO. [Bing] I'll reply this after reviewing RFC4864. > Section 2.2.2.1 >=20 > IMHO, this section should be deleted in its entirety or at least come wit= h a > strong cautionary note that such designs are ill-conceived and detrimenta= l in > nature. Pretending that NAT or NPT improve security at all is dubious at = best. > In fact, NPT and especially NAT provide more tall weeds for attackers to = hide > in, if anything. [Bing] Such designs come from special requirements such as the abovemention= ed information security sensitive enterprises or governments. If you want t= he endpoints disconnected as default and only connected via central control= , it is quite reasonable to pick ULA+Proxy.=20 However, normally we won't recommend to use ULA in this model. But I think = it might not be proper to justify such scenarios as ill. My point is: if yo= u really have special requirements, just use it in this model; but please d= on't misunderstanding ULA was just designed for this kind of use. > AL Proxies can be implemented equally effectively using GUA and there is = no > significant advantage to ULA in such a case. [Bing] If require endpoints default disconnected, egress filtering would be= easier and more stable for ULA than GUA. And can save some operation to ap= ply PA/PI. >=20 > Section 3.1 >=20 > The last sentence should be deleted. GUA is an equally viable option for > these networks. >=20 > Section 3.3.2 >=20 > I'm unable to decipher Paragraph 2, so I cannot make a suggestion on > rewording it. However, since I can't tell what you're trying to say, I'm = pretty > sure it needs to be rewritten. [Bing] It is only a corner case, that is, if the NAT64 prefix is shorter th= an 48/, it would divide the 40bit of ULA into two parts. But in most of the= practices NAT64 just use 96/. I'll rewritten it for ease of reading.=20 >=20 > Section 5 >=20 > IANA considerations should be updated to point to RFC4193 in a similar > manner to section 4. [Bing] Ok, thanks. > [End of comments] >=20 > Owen >=20